Unintentional in-place irfftn transform

Hi!
Thanks for pyvkfft and your effort on this awesome opensource project!
When applying vkfft.fft.irfftn to cupy array, the input array seems to be unintentionally changed despite of not using the in-place command.
Sample code
import pyvkfft
import pyvkfft.fft
import cupy as cp

x = cp.arange(4,dtype='float32').reshape(2,2)

x_fft = pyvkfft.fft.rfftn(x)
x_fft_copy = x_fft.copy()

x2 = pyvkfft.fft.irfftn(x_fft)

print("original array x:\n",x,"\n double-transformed array x2:\n",x2)

print("fft array x_fft:\n",x_fft, "\n fft array copied x_fft_copy:\n", x_fft_copy)
# these arrays are not identical in spite of not using inplace transform.

Output
original array x:
 [[0. 1.]
 [2. 3.]]
 double-transformed array x2:
 [[0. 1.]
 [2. 3.]]
fft array x_fft:
 [[ 1.+0.j -1.+0.j]
 [ 5.+0.j -1.+0.j]]
 fft array copied x_fft_copy:
 [[ 6.+0.j -2.+0.j]
 [-4.+0.j  0.+0.j]]

Environment
OS:Windows 10
cuda: 11.3
pyvkfft version: 2022.1.1

This is known and documented (see https://github.com/vincefn/pyvkfft/blob/master/pyvkfft/cuda.py#L101), it is due to the way intermediate calculations must be made. The same is true in cufft.
The same info should probably also be given in pyvkfft.fft.irfftn though

I'm sorry for skipping over the details of the document. I understand that it is the present specification. Thank you for your quick response.

No problem, it's counter-intuitive that an out-of-place transform destroys the original array. It took me a little while to understand that with cufft...


Add harvester cloud provider chart

issue: https://github.com/harvester/harvester/issues/1019

@yaocw2020 can u rebase those charts so it will run against the new setup CI, thanks

Done

It should be merged after the version 0.1.1 release.

Will need to fix the CI

Fix!!


ttsfrd apple metal cpu(arm64) support

Is your feature request related to a problem? Please describe.
Wanna run cosyvoice on macbook metal cpu
Describe the solution you'd like
provide ttsfrd-0.3.6-cp38-cp38-linux_arm64.whl
Describe alternatives you've considered
Additional context

we will add wetextprocessing to replace ttsfrd when ttsfrd is unavaliable

please update the repo, ttsfrd is now optional during inference


Speed up CI

The Github actions for testing and code coverage take 13 and 15 minutes, respectively.
The following are quite slow:
# These libraries are needed for tauri, and can be quite big.
sudo apt-get install -y webkit2gtk-4.0 libappindicator3-dev # 1 to 10 minutes
# Code coverage is slow because it uses `--nightly` builds, which isn't cached
cargo llvm-cov --all-features --workspace --lcov --output-path lcov.info

Switching to earthly and decrecating atomic-desktop fixed this some time ago


css: User profile modal overflows on long username

Fixes: #23781

Screenshots and screen captures:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

@timabbott Please review the changes.

Thanks for the PR, @soustab10 ! Please clean up your commit history, fix the failing check, and post again to request a review. See here for guidelines.

@soustab10 - Thanks for working on this issue, but I believe this pull request can be closed as the issue (#23781) has been fixed by #24194.


Error in method get_updates if getUpdates returns null

Hello, yesterday I started using your gem to create a simple bot based on the example you provided in the README. The gem is working great so far but at some point the bot crashed with this error
/home/cippaciong/telegrambot/.bundle/ruby/2.2.0/bundler/gems/telegram_bot-2f7dc9739fa0/lib/telegram_bot/bot.rb:24:in `block in get_updates': undefined method `each' for nil:NilClass (NoMethodError)
        from /home/cippaciong/telegrambot/.bundle/ruby/2.2.0/bundler/gems/telegram_bot-2f7dc9739fa0/lib/telegram_bot/bot.rb:22:in `loop'
        from /home/cippaciong/telegrambot/.bundle/ruby/2.2.0/bundler/gems/telegram_bot-2f7dc9739fa0/lib/telegram_bot/bot.rb:22:in `get_updates'
        from tbot.rb:10:in `<main>'

hi! thanks for using the gem!
I guess there's been a network error, most likely.
The gem is currently not handling any errors, and not even checking whether everything's ok.
I still have to figure out whether implement some sort of retry option or simply raise an exception.
Do you have any ideas?

Take my ideas with a pinch of salt since I'm just a beginner programmer but I think that a retry option would be very useful for network errors.

sorry for the long delay.
I just added a fail_silently option, you can check out the commit here: https://github.com/eljojo/telegram_bot/commit/91d1d26f2119f3bf32b134800dcb2972105a0c76
Basically, you can run the following command now:
bot = TelegramBot.new(token: 'ABCDEF')
bot.get_updates(fail_silently: true) do |message|
  puts message.text
end

This should solve your problem.
I'm currently collecting feedback on the gem:
Have you found any other use case that the gem is not handling?
How has your experience been using the gem and making bots?

PS: I added better examples in how to use the gem here: https://github.com/eljojo/telegram_bot#what-else-can-it-do

Hello,
the fail_silently option seems great, i'm going to test it soon! The experience with the gem has been really good and this issue was the only problem I encountered so far.
About the use cases, I'd like to be able to send not only text messages but also images or documents. :smiley:

The bot has been running for a whole day without any problem, I'd say the issue is fixed.


Event can still be changed during optimistic render

Where did this happen?
Local code with an up-to-date main branch
Expected Behavior
An event shouldn't be allowed to be edited or deleted while it is being rendered optimistically
Current Behavior
During the timespan where the optimistically generated event is created and the HTTP request returns a response from the server:
The event cannot be drag and dropped
The event cannot be deleted (would delete a local version but the API would re-generate a new one after the HTTP request returns a response)
Steps to Reproduce

Create Event
Change event
While event change is being processed on backend, change the event again

Possible Solution
Prevent the changes while an event is optimistically rendered
Context
#197 introduced optimistic rendering.

Assign me this please


text.replaced works wrong with $ symbol

@EugeneDar @Graur
Please take a look at this test:
[] > replace-groups-2
  stdout > @
    QQ.txt.sprintf
      "\nreplace2 = %s\n"
      replaced.
        text "q$0werty"
        "$0"
        "GROUP0"

It must print "qGROUP0werty" but prints "q$0werty". Note the code works correctly without $.
You can say we need to write \$ instead of $ in this case but this returns
[ERROR] Failed to execute goal org.eolang:eo-maven-plugin:0.28.2:assemble (test-compile) on project eo-strings: Execution test-compile of goal org.eolang:eo-maven-plugin:0.28.2:assemble failed: Failed to parse /home/tardis3/eo-strings/src/test/eo/org/eolang/txt/regex-tests.eo: [248:13] token recognition error at: '"q\$': "        text "q\$0werty"": LexerNoViableAltException -> [Help 1]
[ERROR]

@levBagryansky looks like bug, please show your test with \$

@EugeneDar please, check it

@Graur sure

@levBagryansky in the future, please simplify your error messages as much as possible (I mean the length of the strings in the tests).

@levBagryansky @Graur I've found new bug.
[] > replace-groups-2
  QQ.io.stdout > @
    QQ.txt.sprintf
      "%s\n"
      replaced.
        text "$A"
        "$"
        "G"

This code prints $AG.

@EugeneDar Thanks!


⚠ Cioos National CKAN has degraded performance

In 4fd31c4, Cioos National CKAN (https://catalogue.cioos.ca/) experienced degraded performance:

HTTP code: 200
Response time: 19734 ms

Resolved: Cioos National CKAN performance has improved in 6a8c2ae after 16 minutes.


[Central_v2] - Top Level Organization/Container Setup

This PR organizes the app code generally to support the development of central_v2. This includes:

Integrates react-router-dom to add routes for each of the different tabs
Adds AppContainer as a wrapper that always includes the header
Adds AppSwitch that works as the switch based on the route match
Starts to integrate styled-components organization, moving a lot of styled components that are located at their components into the lib folder

Hey @maniramezan, I'm tagging you in a couple PRs for central_v2 for review. Kelly was working on some initial central_v2 stuff last month but these two PRs represent the initial set up for the app as a whole. They include some reorganization around containers/switches etc, and then the integration of Context as well as the creation of a CentralDataManagerAPIClient (similiar to what we did for  host and play).
Muhammad is joining the team this week so I'm going to be merging these PRs into dev so we can all work off a consistent base. That being said, I will tag you in the PRs as they come up so you can see what we are doing and if you have any comments, I can address them in subsequent PRs.
Thanks a ton and let me know if this works for you!


Add additional builders for the s390x workers

@edelsohn

Note that for the clang builds, the clang and compiler-rt packages need to be installed at the fedora workers.

Clang and compiler-rt has been installed on RHEL8, Fedora 31, and Rawhide systems.
Clang-3.9 has been installed on the Debian system.

Note here that I haven't added the clang builds on the RHEL systems, as at least personally I haven't tested compiling python with clang on a rhel based distro, not sure how common that is.
Also I didn't add the clang builds on the Debian systems, but I could definitely add some more configs there if you would like. Note that the compiler-rt package is required for the address sanitizer builds of clang which I have enabled for rawhide and fedora stable.

compiler-rt is installed on RHEL8, Fedora, Rawhide.

So @edelsohn are you ok with adding those configs on the workers?
Summarizing here the additional builds that will be triggered on every commit:
On Fedora rawhide and Fedora stable:
Reference leaks
Clang with address sanitizer
Clang with installed python
Link time optimizations
Link time optimizations and Profile guided optimizations
On RHEL7 and RHEL8:
Reference leaks
Link time optimizations
Link time optimizations and Profile guided optimizations

Let's give it a try and see what happens.  We'll monitor it and scale back the builds or scale up the resources if necessary.

I deployed the updated configuration. New s390x workers should pop up at https://buildbot.python.org/all/#/builders


server: add options to dry run and debug for chat and generate

Doesn't actually load the model
No tokenization or context length clipping
Barebones implementation of the chatPrompt function

Precursor to enabling tokenization endpoints: https://github.com/ollama/ollama/pull/8106

Rather than shoot from the hip here and design-by-gut, I thought it might be helpful to draft some thoughts on a proposal, so we can ensure we're not hurting ourselves and users later. Here it is:
I'll help integrate the examples into your proposal while maintaining the clarity and pragmatic style of the content examples.

Proposal: Debug and Dry Run Modes for Ollama Prompt Generation
We propose adding debug and dry run capabilities to Ollama's prompt generation system. These features would help users understand, test, and verify how their inputs are transformed into final prompts for LLM inference.
Background
Ollama uses prompt templates to convert user messages into final prompts for LLM inference. Currently, users cannot inspect this transformation process or verify token counts without running a full generation.
Proposal
This proposal introduces two new optional request parameters:

A debug mode for exposing prompt generation details
A dry run mode for previewing prompts and/or token counts without generation

This is intentionally designed as an opt-in feature to maintain compatibility with existing clients while providing valuable debugging capabilities when needed.
Seperating the two concerns allows users to perform generation in these ways:

normal chat response (with token count)
normal chat response with final prompt generated for generation (with token count)
no chat response (with token count)
no chat response _with _final prompt (with token count)

The combinations above have many powerful use cases.
Rationale
The ability to inspect prompt generation serves several key needs:

Debug support for prompt engineering
Regression testing across runtime versions
Token count estimation without generation
Verification of template behavior

Compatibility
This proposal maintains compatibility by:

Making all new fields optional
Preserving existing behavior when fields are omitted
Minimizing performance impact on non-debug flows

Examples
Basic Usage
Standard chat request with debug mode enabled:
curl http://localhost:11434/api/chat -d '{
    "model": "llama3.2",
    "debug": { "mode": "prompt" },
    "dry": true,
    "messages": [
        {
            "role": "user",
            "content": "why is the sky blue?"
        }
    ]
}'

Response with debug information:
{
  "model": "llama3.2",
  "created_at": "2023-08-04T08:52:19.385406455-07:00",
  "message": {
    "role": "assistant",
    "content": "The sky is blue because ...",
    "images": null
  },
  "debug": {
    "prompt": "<|start_header_id|>user<|end_header_id|>Given the following functions, please respond with a JSON, ..."
  },
  "done": false
}

Dry Run Mode
Request with dry run enabled:
curl http://localhost:11434/api/chat -d '{
    "model": "llama3.2",
    "messages": [
        {
            "role": "user",
            "content": "why is the sky blue?",
            "dry": true
        }
    ]
}'

Response from dry run:
{
  "model": "llama3.2",
  "created_at": "2023-08-04T08:52:19.385406455-07:00",
  "message": {
    "role": "assistant",
    "content": "The sky is blue because",
    "images": null
  },
  "done": false
}

Debug Modes
The debug field accepts the following modes:

"default" (or omitted): Standard behavior with no debug output
"prompt": Includes the complete prompt template expansion in the response. In stream mode it is only included in the first json object of the stream, without messages.

Token Counts
Users will not need to change how or where they get token counts either of the
the above modes. The token counts will be included in the response as they are
now. The only difference is that the token counts will be included in the
response even if the prompt is not generated.
Additional considerations:
It may be useful to echo back the dry and debug parameters in the response so clients
can verify that the server received the request as intended. It would also be
helpful for SDKs to have a way to perform specific actions based on the debug
and dry parameters. For example, a Python SDK could automatically print the
prompt template when debug mode is enabled.

NOTE: While it was considered that "debug": { "mode": "prompt" }, could just be "debug", making it an object now keeps it open for future additions we may want to include, and in a way to prevents us from doing silly things in JSON like say that a field can be a string or an object, making writing clients a pain.

NOTE: While it was considered that "debug": { "mode": "prompt" }, could just be "debug": true,, making it an object now keeps it open for future additions we may want to include, and in a way to prevents us from doing silly things in JSON like say that a field can be a boolean or a string or an object, making writing clients a pain.
Providing a "mode" also makes it explicit what the user is debugging.

I'm now also considering:
"debug": { "prompt": true }

and later we could add { "prompt": true, "shields": true, ...

The design doc is nice, my feedback.

I'm not sure we debug is the right name for the field. The returned values may be used in normal operations, like a client with long chat that wants to manually manage the context length. I'd suggest meta:

curl http://localhost:11434/api/chat -d '{
    "model": "llama3.2",
    "meta": { "prompt": true },
    "dry": true,
    "messages": [
        {
            "role": "user",
            "content": "why is the sky blue?"
        }
    ]
}'

I also like the boolean fields that Blake suggested in a follow-up to allow for getting multiple debug/meta fields back.

Gotta balance not making things too complicated here for the actual use-cases, but this is feeling like a good direction.

I like the idea of having a meta field as @BruceMacD mentioned and I suppose it's also true that it might be used alongside a generation. This in conjunction with the split fields would be really useful for testing and debugging

I'm not sure debug is the right name for the field. The returned values may be used in normal operations, like a client with long chat that wants to manually manage the context length. I'd suggest meta:

I went back-and-fourth on "include": { ... } too. I'm not sure that is descriptive enough though. Are was saying "include a prompt in generation" or "include a prompt in response"...
Maybe we consider:
...
"response": {
    "include": ["prompt", ...]
}
```

which would eliminate the proposal for `{"prompt": true}`, which I like less after this came to mind.

I went back-and-fourth on "include": { ... } too. I'm not sure that is descriptive enough though. Are was saying "include a prompt in generation" or "include a prompt in response"...
Maybe we consider:
...
"response": {
    "include": ["prompt", ...]
}

which would eliminate the proposal for {"prompt": true}, which I like less after this came to mind.

I think in this pattern something like debug is more descriptive as it's all the fields the user could want round-tripped with everything we add to it

I like the idea of having a meta field as @BruceMacD mentioned and I suppose it's also true that it might be used alongside a generation. This in conjunction with the split fields would be really useful for testing and debugging

meta doesn't tell the user much IMO. Am I sending meta? Why would I send some meta like "prompt": true? It feels like it will require having to look it up in docs, often.

Did we consider using a single field in the API? (vs needing to set two?)

Consider using a single field in the API instead of two?

The design has two distinct concerns:

Retrieving the final prompt used for generation, with or without generation
Retrieving the tokenized prompt, with or without generation

This creates a 2x2 matrix. A single field could have values like "prompt-with-response", "prompt-no-response", "response", "no-response". These names are illustrative, not proposed. They demonstrate the complexity of this approach.
Two separate fields yield the same configurations more clearly and with better documentation.
The question is: Must we add two fields? Can we use fewer without complex schemes? Yes.
In our discussion, @jmorganca proposed num_ctx. This elegantly removes one control.
Example: Getting token count without completion:
# Request
curl http://localhost:11434/api/chat -d '{
    "model": "llama3.2",
    "num_ctx": 0,       # 0 means "no generation"
    "messages": [
        {
            "role": "user",
            "content": "why is the sky blue?",
        }
    ]
}'

# Response
{
  "model": "llama3.2",
  "created_at": "2023-08-04T19:22:45.499127Z",
  "done": true,
  "total_duration": 342546000,
  "load_duration": 0,
  "prompt_eval_count": 26,
  "prompt_eval_duration": 342546000, # equals total_duration; only tokenization done
  "eval_count": 0, # no generation performed
  "eval_duration": 0
}

Using num_ctx lets clients explicitly request zero generation overhead.
For returning the generated prompt, we need one new field. While debug saw little use, "response": { "include": [...] } remains viable.
num_ctx and SQL query planning
The approach parallels SQL's limit 0. Examples in PostgreSQL:
No limit:
EXPLAIN ANALYZE SELECT generate_series(0, 100);
                                         QUERY PLAN
--------------------------------------------------------------------------------------------
 ProjectSet  (cost=0.00..0.52 rows=101 width=4) (actual time=0.008..0.017 rows=101 loops=1)
   ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.002..0.002 rows=1 loops=1)
 Planning Time: 0.072 ms
 Execution Time: 0.066 ms

Limit 1:
EXPLAIN ANALYZE SELECT generate_series(0, 100) LIMIT 1;
                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..0.01 rows=1 width=4) (actual time=0.008..0.009 rows=1 loops=1)
   ->  ProjectSet  (cost=0.00..0.52 rows=101 width=4) (actual time=0.006..0.007 rows=1 loops=1)
         ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 0.056 ms
 Execution Time: 0.042 ms

With limit 0:
EXPLAIN ANALYZE SELECT generate_series(0, 100) LIMIT 0;
                                    QUERY PLAN
-----------------------------------------------------------------------------------
 Limit  (cost=0.00..0.01 rows=1 width=4) (actual time=0.002..0.003 rows=0 loops=1)
   ->  ProjectSet  (cost=0.00..0.52 rows=101 width=4) (never executed)
         ->  Result  (cost=0.00..0.01 rows=1 width=0) (never executed)

"Never executed" matches expected behavior with num_ctx: 0. It parses and plans but never executes.
Model loading and num_ctx: 0
Setting num_ctx: 0 should not affect model loading or eviction. An unloaded model stays unloaded. The eviction timer continues; only non-zero num_ctx requests prevent eviction.
To warm up a model, request one token (use num_ctx: 1). This is analogous to SQL's SELECT 1 ping.


Examples

Sarama has a series of Examples in godocs (https://godoc.org/gopkg.in/Shopify/sarama.v1#pkg-examples)
Would it be possible to have something similar demonstrating Sarama-Cluster usage? The README mentions examples, but I can't seem to find any.

How about https://github.com/bsm/sarama-cluster/commit/309783eefad2cf76d730a4cb42906e201e7ad12d

Looks good to me! Even learned something new from that!


Sometimes defaults to French language

After "hexo generate" sometimes Hexo Landscape is in French. Creating a "en.yml" language file may have fixed it.

I remenber It depends on your site setting, strange.

Don't know if this should be posted as a separate issue. This happened to me twice now. Created a new site with:
hexo init blog && cd blog
hexo serve

This results in french site. in _config.yml the language setting is empty. I would expect it to generate English by default. Setting the language explicitly to 'en' generates an English site.
hexo: 3.2.2
hexo-cli: 1.0.2
os: Darwin 15.6.0 darwin x64
http_parser: 1.0
node: 0.10.37
v8: <IP_ADDRESS>
ares: 1.9.0-DEV
uv: 0.10.36
zlib: 1.2.8
modules: 11
openssl: 1.0.1l

I have checked this on node 6.9.1 also. Same results.

This happened to me, but it seems only for the "Recent Posts" section, which turned to "ARTICLES RÉCENTS".

set hexo/_config.yml's 'language' to 'default' instead of 'en'

There is a discussion about it: https://github.com/hexojs/hexo/issues/1125
I'm closing this issue. Please join the discussion there :)


spirv-fuzz: allow replacing a boolean constant argument to OpPhi with a binary by inserting a binary into the OpPhi's relevant parent block.

As a fix for #2897, spirv-fuzz simply does not replace a boolean constant used in an OpPhi with a binary operator instruction, to avoid erroneously adding an instruction before OpPhi.
This could be handled by adding an instruction to the parent block associated with the OpPhi argument.

@andreperezmaselco Can we add this one to your pile of things to work through?

Sure.
I'll work on it.


Write a GO program to convert kilometers to miles

Description
Write a GO program to convert kilometers to miles
1 mile = 1.609 kilometers
Input  : 8.04672
Output : 5

How to contribute

Save the solution in program/convert_kilometers_to_miles.go file
Add convert_kilometers_to_miles.go file in convert-kilometers-to-miles folder

!assign

Hey @marcleonschulz,
This issue has been assigned to you for more than 15 days.
We are unassigning you from this issue.
If you are still interested in contributing to this issue, please get auto-assigned on the issue by commenting !assign again.
Thanks for your contributions :)

!assign


SP5: Fix label text wrong position when offset is specified

This was opened by @ValeraTychov then closed and I don't have permission to open it, but the solution may be worth creating a new PR for https://github.com/ScottPlot/ScottPlot/pull/3865 (fixes #3836)
Thanks @bclehmann for pointing this out in the Discord #1966

I created a new PR for it: #3898
I didn't change a thing, I just downloaded the patch (you can go to <pr_url>.patch to download it) and then I applied it


Add ability to generate pdbs with llvm-mingw.

[ ] Resolve https://github.com/godotengine/godot-proposals/issues/11103#issuecomment-2459502708
[ ] Resolve splitting use debug symbol and use external debug symbol

@Calinou thoughts. Should these have the same effect?

debug_symbols is yes and separate_debug_symbols is yes
debug_symbols is yes and separate_debug_symbols is no


perf event reordering: improve API

Before this patch, the perf events reordering code was assuming that
there was a timestamp in the first field of the perf event struct. That
convention was not explicit.
This patch removes this assumption: by default, perf events are not
ordered unless SetGetTimestamp() is called to register a callback
getting the timestamp.

This patch was tested with the branch https://github.com/kinvolk/scope/tree/alban/reordering-api
@iaguis @schu @alepuccetti PTAL

@iaguis renamed. I also updated the Scope branch I used for testing.

I was wondering if we should add error to the return of timestamp() but I guess it's not worth it?

I was wondering if we should add error to the return of timestamp() but I guess it's not worth it?

I am not sure about this. To me, it would look like a programmatic error and the user of the gobpf lib could either panic or print an error message. But I don't think there is any action that gobpf should do whenever such an error happens.

I am not sure about this. To me, it would look like a programmatic error and the user of the gobpf lib could either panic or print an error message. But I don't think there is any action that gobpf should do whenever such an error happens.

Yes, let's leave it like it is.
lgtm


Phase 2 support for MBDTLS_PSA_CRYPTO_CONFIG

This phase adds in support for the following features being
added to the list of features that can be configured in the
include/psa/crypto_config.h header file using the PSA_WANT_ALG_xxx
macros: ECDH, HMAC, HKDF, and RSA. These changes include changes to
the PSA crypto library to use the appropriate new guards that
will allow the feature to be compiled in or out either using
new PSA_WANT_ALG_xxx or the previous MBEDTLS_xxx macros.
For HKDF and HMAC, most of the PSA library code did not have a
specific matching MBEDTLS_xxx macro for that feature, but was instead
using the generic dependent MBEDTLS_MD_C macro. The ECDH and RSA
features more closely aligned with a direct replacement with a similar
macro. For ECDH and HKDF additional library code had to be updated to
support the new unit tests that confirm the library still builds when
the feature is enabled through PSA_CRYPTO_CONFIG, but disabled by
unsetting the MBEDTLS_xxx equivalent macro.
The new tests for RSA, HMAC, and HKDF would normally unset additional
dependent macros, but when attempting to implement that level of
testing it required removal of too many core features like MD_C, PK_C,
ECP_C and other low level features. This may point to additional phases of
work to complete the transition of these features to the new model.
Fix #3671, #3672, #3673, #3674
Status
READY
Requires Backporting
NO

@gilles-peskine-arm Here is phase 2, overall I think it is a good start to completing the features ECDH, HMAC, HKDF, and RSA to use the PSA crypto config setup. I did have one question. For #3671 it mentions performing work for KEY_TYPE_ECC_KEY_PAIR and KEY_TYPE_ECC_PUBLIC_KEY, but I did not see a clear line in the code to guard around these specifically. Should they be grouped in with ECDH or have individual PSA_WANT_ALG_xxx macros and find their use in the crypto library and place guards there?

The Ci is failing with:
Key import smoke test: AES-CTR .................................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: AES-CBC .................................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: AES-CMAC ................................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: AES-CCM .................................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: AES-GCM .................................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: CAMELLIA-CTR ............................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: CAMELLIA-CBC ............................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: CAMELLIA-CMAC .............................. FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: CAMELLIA-CCM ............................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: CAMELLIA-GCM ............................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: HMAC-SHA-256 ............................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: HKDF-SHA-256 ............................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: RSA PKCS#1v1.5 signature ................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: RSA PKCS#1v1.5 encryption .................. FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: RSA OAEP encryption ........................ FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: ECDSA secp256r1 ............................ FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: ECDH secp256r1 ............................. FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key import smoke test: ECDH secp256r1 with HKDF ................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Generate key: not supported ....................................... PASS

Key generation smoke test: AES-128-CTR ............................ FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key generation smoke test: AES-256-CTR ............................ FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

Key generation smoke test: HMAC-SHA-256 ........................... FAILED

  ( ( psa_key_derivation_setup( &derivation_operation, (((psa_algorithm_t)0x20000100) | ((((psa_algorithm_t)0x01000009)) & ((psa_algorithm_t)0x000000ff))) ) ) ) == ( ((psa_status_t)0) )

  at line 721, /var/lib/build/tests/suites/test_suite_psa_crypto_se_driver_hal.function

@gabor-mezei-arm I will look into the failures and address them today. @gilles-peskine-arm Can you look at my previous question?

For #3671 it mentions performing work for KEY_TYPE_ECC_KEY_PAIR and KEY_TYPE_ECC_PUBLIC_KEY, but I did not see a clear line in the code to guard around these specifically. Should they be grouped in with ECDH or have individual PSA_WANT_ALG_xxx macros and find their use in the crypto library and place guards there?

I'm not sure I understand the question. Generally, code that is specific to ECC keys (whether key pairs or public keys) is currently guarded by MBEDTLS_ECP_C, for example psa_import_ecp_key in psa_crypto.c. These guards should change to PSA_WANT_ECC_KEY_PAIR || PSA_WANT_ECC_PUBLIC_KEY for code that applies to both public keys and key pairs and is invoked regardless of the presence of an accelerator, to one of
PSA_WANT_ECC_KEY_PAIR or PSA_WANT_ECC_PUBLIC_KEY for code that only applies to private/public keys, or to a PSA_HAVE_BUILTIN_xxx for code that isn't invoked if an accelerator is present.
ECDH-specific code is currently guarded by MBEDTLS_ECDH_C and should change to PSA_WANT_ALG_ECDH or PSA_HAVE_BUILTIN_ALG_ECDH.

@gilles-peskine-arm That explanation is what I was looking for. Thanks for the help. I'll update the code for that area and fix the current CI failures.

@gilles-peskine-arm So when MBEDTLS_CRYPTO_CONFIG is disabled, in config_psa.h does the code need to setup the PSA_WANT_xxx for various MBEDTLS_xxx features in addition to the MBEDTLS_PSA_BUILTIN_xxx ones? Currently if MBEDTLS_CRYPTO_CONFIG is disabled there is nothing setting up any of the PSA_WANT_xxx definitions.

So when MBEDTLS_CRYPTO_CONFIG is disabled, in config_psa.h does the code need to setup the PSA_WANT_xxx for various MBEDTLS_xxx features in addition to the MBEDTLS_PSA_BUILTIN_xxx ones?

Er, no, sorry, I mixed the prefixs up in my previous comment. Just MBEDTLS_PSA_BUILTIN_KEY_TYPE_xxx and MBEDTLS_PSA_BUILTIN_ALG_xxx.

@gilles-peskine-arm No worries on the prefix mix up. I pushed those additional changes so they can be looked at.

@ronald-cron-arm @gilles-peskine-arm Any idea what the CI failures are for?

In test_psa_crypto_config_no_driver, the build passes but several unit tests are failing.
In test_psa_crypto_config_basic and most build_psa_want_*, the linking of sample programs and unit tests fails:
16:35:26 src/drivers/key_management.o: In function `test_transparent_validate_key':
16:35:26 key_management.c:(.text+0x242): undefined reference to `mbedtls_ecc_group_of_psa'
16:35:26 key_management.c:(.text+0x2c3): undefined reference to `mbedtls_ecc_group_of_psa'
16:35:26 collect2: error: ld returned 1 exit status
16:35:26 Makefile:125: recipe for target 'test_suite_md' failed

CI failures on d5b7660b9aff2ab2ae183a6cff22729318eeeae2: the four build_psa_want_rsa_<ALG> are failing, but the build_psa_want_rsa_<KEY_TYPE> are passing.
psa_crypto.c: In function 'psa_import_key_into_slot':
psa_crypto.c:1094:21: error: implicit declaration of function 'psa_import_rsa_key' [-Werror=implicit-function-declaration]
             return( psa_import_rsa_key( slot, data, data_length ) );
                     ^
psa_crypto.c: In function 'psa_get_key_attributes':
psa_crypto.c:1527:26: error: implicit declaration of function 'psa_load_rsa_representation' [-Werror=implicit-function-declaration]
                 status = psa_load_rsa_representation( slot->attr.type,
                          ^
psa_crypto.c: In function 'psa_internal_export_key':
psa_crypto.c:1652:22: error: implicit declaration of function 'psa_export_rsa_key' [-Werror=implicit-function-declaration]
             status = psa_export_rsa_key( PSA_KEY_TYPE_RSA_PUBLIC_KEY,
                      ^
psa_crypto.c: In function 'psa_sign_hash':
psa_crypto.c:3773:18: error: implicit declaration of function 'psa_rsa_sign' [-Werror=implicit-function-declaration]
         status = psa_rsa_sign( rsa,
                  ^
psa_crypto.c: In function 'psa_verify_hash':
psa_crypto.c:3880:18: error: implicit declaration of function 'psa_rsa_verify' [-Werror=implicit-function-declaration]
         status = psa_rsa_verify( rsa,
                  ^
  AR    libmbedx509.a
cc1: all warnings being treated as errors
Makefile:265: recipe for target 'psa_crypto.o' failed
make[1]: *** [psa_crypto.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:17: recipe for target 'lib' failed
make: *** [lib] Error 2
^^^^build_psa_want_rsa_oaep: build: full + MBEDTLS_PSA_CRYPTO_CONFIG + PSA_WANT_ALG_RSA_OAEP + PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY: command make CC=gcc CFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -DPSA_CRYPTO_DRIVER_TEST -DMBEDTLS_PSA_ACCEL_ALG_RSA_OAEP -I../tests/include -O2 LDFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -> 2^^^

sa_crypto.c: In function 'psa_import_key_into_slot':
psa_crypto.c:1094:21: error: implicit declaration of function 'psa_import_rsa_key' [-Werror=implicit-function-declaration]
             return( psa_import_rsa_key( slot, data, data_length ) );
                     ^
psa_crypto.c: In function 'psa_get_key_attributes':
psa_crypto.c:1527:26: error: implicit declaration of function 'psa_load_rsa_representation' [-Werror=implicit-function-declaration]
                 status = psa_load_rsa_representation( slot->attr.type,
                          ^
psa_crypto.c: In function 'psa_internal_export_key':
psa_crypto.c:1652:22: error: implicit declaration of function 'psa_export_rsa_key' [-Werror=implicit-function-declaration]
             status = psa_export_rsa_key( PSA_KEY_TYPE_RSA_PUBLIC_KEY,
                      ^
psa_crypto.c: In function 'psa_sign_hash':
psa_crypto.c:3773:18: error: implicit declaration of function 'psa_rsa_sign' [-Werror=implicit-function-declaration]
         status = psa_rsa_sign( rsa,
                  ^
psa_crypto.c: In function 'psa_verify_hash':
psa_crypto.c:3880:18: error: implicit declaration of function 'psa_rsa_verify' [-Werror=implicit-function-declaration]
         status = psa_rsa_verify( rsa,
                  ^
  AR    libmbedx509.a
cc1: all warnings being treated as errors
make[1]: *** [psa_crypto.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:265: recipe for target 'psa_crypto.o' failed
Makefile:17: recipe for target 'lib' failed
make: *** [lib] Error 2
^^^^build_psa_want_rsa_pkcs1v15_crypt: build: full + MBEDTLS_PSA_CRYPTO_CONFIG + PSA_WANT_ALG_RSA_PKCS1V15_CRYPT + PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY: command make CC=gcc CFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -DPSA_CRYPTO_DRIVER_TEST -DMBEDTLS_PSA_ACCEL_ALG_RSA_PKCS1V15_CRYPT -I../tests/include -O2 LDFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -> 2^^^^

psa_crypto.c: In function 'psa_import_key_into_slot':
psa_crypto.c:1094:21: error: implicit declaration of function 'psa_import_rsa_key' [-Werror=implicit-function-declaration]
             return( psa_import_rsa_key( slot, data, data_length ) );
                     ^
psa_crypto.c: In function 'psa_get_key_attributes':
psa_crypto.c:1527:26: error: implicit declaration of function 'psa_load_rsa_representation' [-Werror=implicit-function-declaration]
                 status = psa_load_rsa_representation( slot->attr.type,
                          ^
psa_crypto.c: In function 'psa_internal_export_key':
psa_crypto.c:1652:22: error: implicit declaration of function 'psa_export_rsa_key' [-Werror=implicit-function-declaration]
             status = psa_export_rsa_key( PSA_KEY_TYPE_RSA_PUBLIC_KEY,
                      ^
psa_crypto.c: In function 'psa_sign_hash':
psa_crypto.c:3773:18: error: implicit declaration of function 'psa_rsa_sign' [-Werror=implicit-function-declaration]
         status = psa_rsa_sign( rsa,
                  ^
psa_crypto.c: In function 'psa_verify_hash':
psa_crypto.c:3880:18: error: implicit declaration of function 'psa_rsa_verify' [-Werror=implicit-function-declaration]
         status = psa_rsa_verify( rsa,
                  ^
  AR    libmbedx509.a
cc1: all warnings being treated as errors
Makefile:265: recipe for target 'psa_crypto.o' failed
make[1]: *** [psa_crypto.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:17: recipe for target 'lib' failed
make: *** [lib] Error 2
^^^^build_psa_want_rsa_pkcs1v15_sign: build: full + MBEDTLS_PSA_CRYPTO_CONFIG + PSA_WANT_ALG_RSA_PKCS1V15_SIGN + PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY: command make CC=gcc CFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -DPSA_CRYPTO_DRIVER_TEST -DMBEDTLS_PSA_ACCEL_ALG_RSA_PKCS1V15_SIGN -I../tests/include -O2 LDFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -> 2^^^^

psa_crypto.c: In function 'psa_import_key_into_slot':
psa_crypto.c:1094:21: error: implicit declaration of function 'psa_import_rsa_key' [-Werror=implicit-function-declaration]
             return( psa_import_rsa_key( slot, data, data_length ) );
                     ^
psa_crypto.c: In function 'psa_get_key_attributes':
psa_crypto.c:1527:26: error: implicit declaration of function 'psa_load_rsa_representation' [-Werror=implicit-function-declaration]
                 status = psa_load_rsa_representation( slot->attr.type,
                          ^
psa_crypto.c: In function 'psa_internal_export_key':
psa_crypto.c:1652:22: error: implicit declaration of function 'psa_export_rsa_key' [-Werror=implicit-function-declaration]
             status = psa_export_rsa_key( PSA_KEY_TYPE_RSA_PUBLIC_KEY,
                      ^
psa_crypto.c: In function 'psa_sign_hash':
psa_crypto.c:3773:18: error: implicit declaration of function 'psa_rsa_sign' [-Werror=implicit-function-declaration]
         status = psa_rsa_sign( rsa,
                  ^
psa_crypto.c: In function 'psa_verify_hash':
psa_crypto.c:3880:18: error: implicit declaration of function 'psa_rsa_verify' [-Werror=implicit-function-declaration]
         status = psa_rsa_verify( rsa,
                  ^
  AR    libmbedx509.a
cc1: all warnings being treated as errors
Makefile:265: recipe for target 'psa_crypto.o' failed
make[1]: *** [psa_crypto.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [lib] Error 2
Makefile:17: recipe for target 'lib' failed
^^^^build_psa_want_rsa_pss: build: full + MBEDTLS_PSA_CRYPTO_CONFIG + PSA_WANT_ALG_RSA_PSS + PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY: command make CC=gcc CFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -DPSA_CRYPTO_DRIVER_TEST -DMBEDTLS_PSA_ACCEL_ALG_RSA_PSS -I../tests/include -O2 LDFLAGS=-Werror -Wall -Wextra -fsanitize=address,undefined -fno-sanitize-recover=all -> 2^^^^

@gilles-peskine-arm Can you double check the CI failures for d5b7660? All 6 RSA tests are passing on my local build setup. Those errors look like they are from a previous iteration that I then fixed and squashed back into the last commit to keep the commit history clean. Thanks for helping to post the CI failures.

Ah, yes, my bad, the run I looked at was on a464938. d5b7660 passed.

@ronald-cron-arm @gilles-peskine-arm Any info on the CI build failures?

Looks like a network problem between GitHub and the Jenkins instance. There are no reported failures, but I'm not completely sure that all the jobs ran so I've triggered a replay of the pr-merge job.

@gilles-peskine-arm Thanks for the help.

@ronald-cron-arm @gilles-peskine-arm Is there still CI build failures? What are the next steps for this PR?

The rerun of pr-merge passed so now it's up to Ronald and me to review.

@gilles-peskine-arm and @ronald-cron-arm, we would appreciate your review on this happening swiftly. Our SDK is currently being blocked due to size issues, which this patch can help resolve.

I am on it. Yesterday was a bank holiday in France thus no much news from @gilles-peskine-arm and me yesterday.

@ronald-cron-arm Thanks for the review. I have addressed the comments and squashed that commit with the previous one to reduce commit count.

@gilles-peskine-arm @ronald-cron-arm Looks like the CI failed due to a timeout in the MacOS build. Is that a common issue, or should I look into a certain area for potential issues?

This is not a common issue to me but I don't think the failure is related to this PR thus nothing to do on your side.

CI Fixed

@paul-elliott-arm @ronald-cron-arm Thanks for helping with the CI build failures. I fixed the last MD_C guard as well.

@gilles-peskine-arm Anything else for this PR?

The next step is for me to finish reviewing. I expect to finish on Monday. So far I haven't found any problem in the latest version.

@gilles-peskine-arm I'm wondering whether the psa/crypto_config.h file should pull in another (autogenerated) header file (from the same process that generates psa_crypto_driver_wrappers.c/.h) which would contain all of the available accelerator flags from the driver inclusion process?

@stevew817 That's in the plans.

@ronald-cron-arm @gilles-peskine-arm Thanks for all the review comments. I agree there will likely need to be adjustments and the testing enhancements will definitely highlight where those are. Is there any help I can provide for the latest CI failures?


better reflect modified URI

small addition to make sure copies are reflected to their root.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@abdb69b). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master      #97   +/-   ##
=========================================
  Coverage          ?   71.96%
=========================================
  Files             ?      105
  Lines             ?     4419
  Branches          ?        0
=========================================
  Hits              ?     3180
  Misses            ?     1239
  Partials          ?        0

Impacted Files
Coverage Δ

Sources/URI/Model/URI+Modification.swift
100% <100%> (ø)

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 abdb69b...3d96fac. Read the comment docs.


cppcheck: fix broken hash

Description of changes
Without this change:
$ nix build nixpkgs#cppcheck
error: hash mismatch in fixed-output derivation '/nix/store/lip9vi88nd3fvi8z5cq9nn1y9dvwkk17-source.drv':
         specified: sha256-8vwuNK7qQg+pkUnWpEe8272BuHJUaidm8MoGsXVt1X8=
            got:    sha256-bKZOAGInks26NmzlKo1T8NREO9xoF8ZsssNDzyTJwlU=
error: 1 dependencies of derivation '/nix/store/qbvn252cpwkkxx408bj43abh6vcyg087-cppcheck-2.9.1.drv' failed to build

Introduced in https://github.com/NixOS/nixpkgs/pull/197521, FYI @r-ryantm
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Note that r-ryantm is a bot account and cannot really respond :-)
I got the old hash on https://github.com/danmar/cppcheck/commit/4a17dcbd36e73d1af0b284c916f4eeea6fe383b6, and currently upstream tag 2.9.1 on https://github.com/danmar/cppcheck/commit/ef1c70f723b5d49fd4e98aaf1e76ba1becdced25. It can be possible that upstream re-tagged the version. If re-tag & hash mismatch happen again, we may probably ask upstream for clarification :thinking:

Perfect, thanks for the quick merge!

If re-tag & hash mismatch happen again, we may probably ask upstream for clarification 🤔

and to stop doing that.

When it would be available on unstable? I updated channels and used --upgrade flag, but I can't get it worked and keep on showing same issue, any hint?

It should already be there https://nixpk.gs/pr-tracker.html?pr=198938

sudo nix-channel --list
home-manager https://github.com/nix-community/home-manager/archive/master.tar.gz
nixos https://nixos.org/channels/nixos-unstable
nixpkgs https://nixos.org/channels/nixpkgs-unstable
sudo nixos-rebuild switch --keep-going --show-trace --upgrade
trying https://github.com/danmar/cppcheck/archive/2.9.1.tar.gz
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 5340k    0 5340k    0     0  1994k      0 --:--:--  0:00:02 --:--:-- 3307k
unpacking source archive /build/2.9.1.tar.gz
error: hash mismatch in fixed-output derivation '/nix/store/lip9vi88nd3fvi8z5cq9nn1y9dvwkk17-source.drv':
specified: sha256-8vwuNK7qQg+pkUnWpEe8272BuHJUaidm8MoGsXVt1X8=
got:    sha256-bKZOAGInks26NmzlKo1T8NREO9xoF8ZsssNDzyTJwlU=
Should I run anything else? Before last build, I ran nix-collect-garbage once as well

Works for me with flakes. Try doing:
nix-channel --update
sudo nix-channel --update

I do not have flakes enabled, may it be the reason?

It shouldn't make a difference. The channels and branch should be identical if nothing is broken.


[Backport 2.x] Per request phase latency (#10351)

Signed-off-by: David Zane<EMAIL_ADDRESS>(cherry picked from commit daf1350888f878868748172f576a0cdb3dc64b33)

Description
2.x Backport for https://github.com/opensearch-project/OpenSearch/pull/10351
Documentation: https://github.com/opensearch-project/documentation-website/pull/5154
Also must backport UT fix: https://github.com/opensearch-project/OpenSearch/pull/10649
Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)
[x] Public documentation issue/PR created

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Link to version update on main: https://github.com/opensearch-project/OpenSearch/pull/10865


Addition of Oracles section to the documentation.

Describe the content contribution you'd suggest
Hey everyone, I'd like to add a content-contribution request for the addition of an oracle section in: Klaytn docs > dApp Developers > Oracles
Klaytn is currently integrated with SupraOracles. This issue aims to add developer guides to demonstrate how developers on Klaytn can use:

SupraOracles price feed data for Klaytn network.
VRF

products in smart contracts on Klaytn ( testnet right now).
Elaborate the suggested content contribution with samples
Here's a sample of what the Oracles section would look like:

Additional context
Oracles are a core part of building powerful smart contracts since they bring off-chain data/computations onchain. SupraOracles is integrated has Klaytn and it would be beneficial to Klaytn ecosystem projects if the guides are tailored specifically for Klaytn developments are made available. Thank you :)

Closing this issue as it is added to Klaytn docs https://docs.klaytn.foundation/docs/build/tools/oracles/supraoracles/.


node_labels's labelvalue must be formatted to handle non string values

Current behaviour expects values from node_labels dict to be strings, otherwise the rendering fails with "coercing to Unicode: need string or buffer, int found" (e.g. when a label in node_labels has a integer value)
The proposed formatting prevents the error from happening.

@Atoms Thx for the approval. Could you trigger a ci pipeline too ?

ci  check this

Closing this PR and creating a new one to pass the ci


Change page title for "Publishing actors"

I'd like to add a more descriptive page title for Google, but keep the simpler one in the menu. For example, I’d like to have page title “Publishing actors” on google, but keep just “Publishing” in the menu.
@m-murasovs is this the right way?

Great cheers Misha, you're the docs hero :)


Clicking on the space name in Timelineproposal should take user to space

When clicking on the space name in TimelineProposal and TimelineProposalPreview it should take the user to the space and not to the proposal.

Will work on it


App closes when connecting remotely

Me and my team mmates noticed app closes when Im starting remote session (Windows / RDP)
It might be related with resolution change

@maciey thank you for the bug report. Similar issues are described in #5872 and #6407

Closing as duplicate. Further discussion on: https://github.com/dbeaver/dbeaver/issues/5872


Hide Feedback banner on Bookmarks if feedback is completed for bookmarked services

If a user has already provided feedback on their bookmarked services, the button for "Was this service helpful" disappears so that they can't provide feedback anymore. However, the Banner prompting them to give feedback still shows. This should disappear since the user can't actually act on the Banner's CTA which makes the experience confusing.

Acceptance Criteria

[ ]  The Feedback banner on Bookmarks is hidden if user has already given feedback on all their Bookmarked services

Steps for QA:

This is too much of an edge case, it will be confusing to the user and also complex to implement for little value

This is very much an edge case, low priority


TS: 3D FlatGeobuf parsed to GeoJSON as 2D

Here only the XY array portion of geometries are parsed to GeoJSON:
https://github.com/bjornharrtell/flatgeobuf/blob/7d9d5d59ee1da99d44da1dddebf2d57c38433e3c/src/ts/geojson/geometry.ts#L63-L76
I'd argue that GeoJSON should include the Z dimension if it exists. From the spec:

An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid.

Agreed, this is an oversight and bug.

Began work on this and realize why I didn't make it in the first place. It's non trivial to implement properly as the WKTParser implementation in JSTS also lacks support for more than 2 dimensions, and I need that for the test suite at least.

Required work in JSTS now tracked with https://github.com/bjornharrtell/jsts/issues/408.

As of https://github.com/bjornharrtell/flatgeobuf/commit/d34c237602066545413cc93ee30751193e739882 this should now be resolved.

This is now in 3.5.0 release at npm. @kylebarron if you get the chance to verify this I'd love to get feedback.


add rust toolchain file

Adding a rust toolchain file to make it possible (easier) to build the thir-export.
Unfortunately it looks like the crate itself doesn't work yet. So I'll refrain from digging deeper until we had a chat about what works and what needs to happen to make it work.

Hi Franziskus,
About the Cargo.lock file, we actually need to commit it, Nix uses the lock information so that the thing is always built the same way with the exact same dependencies.
Oh, what is not working? It's not compiling?

About the Cargo.lock file, we actually need to commit it, Nix uses the lock information so that the thing is always built the same way with the exact same dependencies.

As long as the libraries are only used in the local binary that's fine. Otherwise it's dangerous because you won't know whether it's actually building for other versions of the dependencies.

Oh, what is not working? It's not compiling?

It's compiling but it's only throwing errors.
Can you start by adding documentation here on how you expect this to be used?


Villagers with no trades.

What is the output link of /viaversion dump?
http://hastebin.com/efubirogak.json
Are you using any additional software like BungeeCord? If so, what software and version? (Please list your plugins as well)
No.
How does this error happen? login? Using an item?
Villagers have no trades.
Is there an error in the console? Use pastebin.com. Is there a kick message?
No.

Was just about to report this ^^

Every villager or just a bunch?

Fixed in latest dev build


[WFCORE-5272] Setting jacc provider to Elytron throws exceptions

Issue: https://issues.redhat.com/browse/WFCORE-5272

Core - Full Integration Build 10263 outcome was UNKNOWN using a merge of d00ed41bb81680b1983e2a055136fa291c73e464
Summary: Canceled (Error while applying patch; cannot find commit a04e278a76211b0a8b48b112bd5edb23bd37e50f in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/4475/merge branch was updated and the commit selected for the ... Build time: 00:00:13

Core - Full Integration Build 10316 outcome was UNKNOWN using a merge of d00ed41bb81680b1983e2a055136fa291c73e464
Summary: Canceled (Error while applying patch; cannot find commit a04e278a76211b0a8b48b112bd5edb23bd37e50f in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/4475/merge branch was updated and the commit selected for the ... Build time: 00:00:13

@bstansberry @darranl updated the PR using a tombstone capability introduced by https://github.com/wildfly/wildfly/pull/13962

rebased to resolve conflict in ElytronSubsystemMessages

@darranl could you review the changes when you have a chance?

I think there is still an outstanding review comment from Brian that needs to be followed up but other than that I think we are Ok.  Although is there a reciprocal issue where legacy security could be enabled after Elytron?

Thanks @darranl. The corresponding legacy security change is in https://github.com/wildfly/wildfly/pull/13962
As for the outstanding review - do you mean https://github.com/wildfly/wildfly-core/pull/4475#discussion_r571350290 ? I think that should be addressed now - I changed the handler and added recoverServices implementation.

@bstansberry I have flagged as ready to merge so speak up if your request is still outstanding ;-)


Taxonomies ignoring uglyurl=true

Not sure if this is intended but when uglyurls is set to true the generated taxonomy pages do not have uglyurls, they still use just folders instead of making all the links pointed directly to files.

To be specific, the links to posts are in the uglyURL form - i.e. the link does end in  .html.
However the links to categories and tags are still in the form as if uglyurl=false - i.e. they point to directories, not to HTML files.
Unfortunately, the folder being pointed at  (e.g. http://localhost:1313/categories/general/) contains an index.xml and a page subdirectory, but no HTML file so doesn't render anything.
It turns out that at individual category and tag pages are being generated correctly, but the links are wrong.
e.g. the link to the general category is
       http://localhost:1313/categories/general/           But it should be
       http://localhost:1313/categories/general.html

Likewise the tags link (e.g. for tag 'linux')
      http://localhost:1313/tags/linux/                    And this should be
      http://localhost:1313/tags/linux.html

I need the uglyurls=true option as I need to keep the rendered HTML files in their original directories (i.e. in same relative location next to images etc).
If uglyurls=false, then the rendered HTML file is moved into its own directory breaking all the relative links that it contains.
The files in /content are generated by Emacs Orgmode's "Export to HTML" and look fine when rendered by Hugo, and the orgmode files are in the own directories with related images and other files i really don't want to shift, so it'd be great if the links to categories and tags when uglyurls=false option was fixed.
Then I get the power of orgmode with the benefits of Hugo :-)
Many thanks - Giovanni

I've just written a little Python 3 program to patch the files in /public so the generated tag and category pages work correctly:
https://gist.github.com/GiovanniMoretti/8c874652689960c9c11d81952c0ecbd6

I just tested this, and uglyurls=true works fine for taxonomies.
Not sure what you mean by "making all the links pointed directly to files".
Can you provide a concrete example?

Thanks for checking. I've attached a file that has the examples/blog subdirectory from the Github source for Hugo, and I've added some more posts to the /content/post directory, so there are a reasonable number of categories and tags.
What you see in the public directory is the output of "hugo" - I'm using Hugo v0.15 via Homebrew on a Macbook.
If you run 'hugo server' and have a look at the first post - it's in the General category (and so are lots of other pages) but the link is to  the general directory which doesn't contain a HTML file so the displayed page is empty.
Another example, from the home page, scroll down to the post starting with VP2E offcentre. It's in the "Radio" category and has the tag "Antennas" (as do several other pages). Neither of the links on the right hand side of the page show the entries for the category or tag respectively.
Hopefully this concrete example helps. The only change to blog example was add the additional posts, and to add  uglyurls = true to the config file.
uglyURLtest.zip

@GiovanniMoretti I looked at your site. The links are created by the template:

{{ . }}

And the template is created by you or the theme author. I fail to see how Hugo could have fixed this one.
If noone is able to provide an example where Hugo is "doing the wrong thing", I'm gonna close this.

It's not my template. It's the closest to a "canonical example" we can get, (the blog example from Hugo's source), given that Hugo doesn't supply a known correct sample theme/template.
Following your lead above, I've modified the template in layouts/post/single so it now gives the correct URL (by adding .html to the end of the link):
            {{ range .Params.categories }}

{{ . }}

            {{ end }}

And both tags and categories now work. Thank you - I now understand what's going on.
I think this points to out an underlying problem, as most if not all of the themes I tried from the Hugo Theme gallery behaved in the same way, so either

there needs to be a way for Hugo to generate the URL that includes the .html (or not) for the taxonomies, OR
theme authors should be encouraged to specify which setting of uglyurl their theme is designed for.

My modification of adding .html explicitly to the layout means it won't work for uglyurls=false.
Is my modification to the layout what you were expecting or is there a more elegant way to make the category and tags links in a layout work correctly when uglyurls=true and and when uglyurls=false?
Apologies if this blindingly obvious to you but I'm completely new to both Hugo and the templating language.

Is my modification to the layout what you were expecting or is there a more elegant way to make the category and tags links in a layout work correctly when uglyurls=true and and when uglyurls=false?

Currently no. I'll keep this open. This will be much easier once ...
https://discuss.gohugo.io/t/node-improvements/1593
... is done.
But currently I guess uglyURLs are for people that is in full control of their templates.

Can templates even check whether uglyURLs is set to true?
Alternatively, what do you think about exposing the URLizeAndPrep function to the templates?

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.
If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.


CSS overriding, className vs StyledComponent

Passing a className prop to a StyledComponent works fine, but if a specific CSS property (e.g. background-color) is passed in via a className prop and also defined in the StyledComponent, the StyledComponent will win.
In the example below <div> will have a green background. Should the CSS properties sent via the className prop override any matching CSS properties in the StyledComponent? Either way, it would be great to have this documented, happy to submit a PR.
// StyledUpYo.js
const StyledUpYo = styled.div`background-color: green;`;

// styles.css
.styledUpYo {
  background-color: red;
}

import StyledUpYo from './StyledUpYo';
import styles from './styles.css';

const Contrived = (props) => (
  <StyledUpYo className={styles.styledUpYo}>
    {props.children}
  </StyledUpYo>
);

Both of them simply inject CSS into the head, so if you have conflicting rules you have the same CSS cascade rules that always apply — for the same specificity, the rules that are defined latest will win.
I haven't looked into webpack's style-loader (which I'm assuming you're using) as to where it injects the styles, but it wouldn't surprise me if will always inject CSS ahead of Styled Components (since one is build time and one is run time). If that's the case, there's not much you can do beyond escalating specificity. Or, you know, try to avoid clashes where possible!
But if you want to bump specificity the easiest way is to do this:
// styles.css
.styledUpYo.styledUpYo {
  background-color: red;
}

Or, if for some reason the order switches and you need to boost specificity in SC, you can do this:
// StyledUpYo.js
const StyledUpYo = styled.div`
  && {
    background-color: green;
  }
`;

Hope that helps explain it. Maybe you could try out the specificity increase and just confirm it works for your problem, and we could document that?

Oh man, great response, thank you for taking the time to explain, it makes a lot of sense now.

Yes, I am using the style-loader.
You are 100% right, bumping the specificity fixes the issue in both examples (both directions).

As for documenting this, do you think it should live under the Tip and Tricks section? That is kind of where I would expect an edge case like this to belong.

Happy to help!
I think it could be its own doc. "Using Styled Components with Existing CSS". There may well be a few more edge cases we come across. If you're happy to have a go at writing that that would be great!

Just discovered that Overriding a non Styled Component (your own or 3rd party react component) only works if the react component adds the className prop. This seems to be a caveat more than anything but I am guessing this should be listed in the main README, what do you think?

Yeah true, that's just inherent to how styled-components and react works. We should definitely note that!

I'm working on a component library that includes a styled component , like this:
const MyDiv =styled.div`
  background-color:green;
`;

I want the flexibility for users of my component library to easily override the styles through css and css, particularly the background-color, when they use my components in their projects.
import MyDiv from 'my-package';

....
<MyDiv className='background-color-red'>Text</MyDiv>
....

As classes with styled component will higher specificity (since styles with styled component will be appended in head)  there will no way to override those style at consumer end.
I'm using esbuild  for my component library.
What's the best way to ensure that my component styles can be customized by users without being overridden when they use my component library in their projects? Any advice or best practices would be greatly appreciated.


[V2] Fix issue with the wrong element selected when scrolling

Same fix as #1764, but for V2.

Merged, thanks!


Invalid reCAPTCHA response when trying to subscribe to CC newsletter

I am not able to subscribe to the CC newsletter:

Subscribe to CC newsletter
Type in e mail address
Select options
Select I am not a robot
Select Submit

Result is always Invalid reCAPTCHA response.
When using IE I was presented the usual picture box but same result.
Peter

This was already notified here: creativecommons/tech-support#635 (private repo)
the problem seems to be the url on the website, the correct URL should be this one
https://us.e-activist.com/page/6747/subscribe/1
this was already updated on the website
thank you for flagging this!


binary-local and default trust policy

When using a binary built via binary-local I get:
 $GOPATH/src/github.com/projectatomic/skopeo/skopeo copy docker://fedora:24 oci:fedora-24-oci
FATA[0000] Error loading trust policy: open /etc/containers/policy.json: no such file or directory

I can see why:
install: install-binary install-docs install-completions
    install -D -m 644 default-policy.json ${CONTAINERSSYSCONFIGDIR}/policy.json

I think this is a valid bug?
Workaround:
$ sudo mkdir -p /etc/containers
$ sudo cp default-policy.json /etc/containers/policy.json

This is a duplicate of https://github.com/projectatomic/skopeo/issues/181 - pls continue the discussion over there

Thanks.
On 12 Sep 2016 4:05 pm, "Antonio Murdaca"<EMAIL_ADDRESS>wrote:

This is a duplicate of #181
https://github.com/projectatomic/skopeo/issues/181 - pls continue the
discussion over there
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/projectatomic/skopeo/issues/200#issuecomment-246257075,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAfSVhiBwwTf-vHA1w6TCHiaHtOFEVCGks5qpOuZgaJpZM4J6QT0
.


ParkingActivity not showing list of reports

Either taking a really long time to load or its getting nothing,

Google Firebase disabled anonymous database read/write.


Empty error message from OCH GraphQL client

Description
Sometimes on our long-running cluster we get an empty error message from GraphQL client we use:
while deleting TypeInstance with ID f6ca4548-ef05-4a0f-87c0-ac294b9b4dec: while executing mutation to delete TypeInstance: All attempts fail:
#1: graphql:

We need to investigate whether there is a bug in our code (OCH client) or in our dependency (retry-go, machinebox graphql client, etc.).

This may not be related just to local OCH client. Investigate all GraphQL clients (Public OCH, Local OCH, Engine) for potential causes.

Expected behavior
We get the error message for the root cause of GraphQL request failure.
Actual behavior
Example run: https://github.com/capactio/capact/runs/2762064610?check_suite_focus=true
Action Action execution
  should pick proper Implementation and inject TypeInstance based on cluster policy
  /capact.io/capact/test/e2e/action_test.go:58
STEP: Preparing input Type Instances
STEP: 1. Expecting Implementation A is picked based on test policy and requirements met...
Jun  7 08:37:28.515: while deleting TypeInstance with ID f6ca4548-ef05-4a0f-87c0-ac294b9b4dec: while executing mutation to delete TypeInstance: All attempts fail:
#1: graphql:
Jun  7 08:37:29.539: while deleting TypeInstance with ID a0ecd4c3-c55a-497a-8c68-05b5e6242cb8: while executing mutation to delete TypeInstance: All attempts fail:
#1: graphql:
• Failure [305.075 seconds]
Action
/capact.io/capact/test/e2e/action_test.go:37
  Action execution
  /capact.io/capact/test/e2e/action_test.go:57
    should pick proper Implementation and inject TypeInstance based on cluster policy [It]
    /capact.io/capact/test/e2e/action_test.go:58
    Timed out after 300.000s.
    Expected
        <graphql.ActionStatusPhase>: FAILED
    to be an element of
        <[]interface *** | len:1, cap:1>: [["SUCCEEDED"]]
    /capact.io/capact/test/e2e/action_test.go:343

We need to bump prio for this task. It's problematic when it comes to debugging. We had such problem in our engine:
2021-06-29T08:40:59.930Z	DEBUG	controller-runtime.manager.events	zapr@v0.1.0/zapr.go:69	Warning	{"object": {"kind":"Action","namespace":"capact-system","name":"capact-upgrade-fdhwl","uid":"089ef74c-cb7f-46b6-b1a3-b028c87041f7","apiVersion":"core.capact.io/v1alpha1","resourceVersion":"19263936"}, "reason": "Delete runner action", "message": "while unlocking TypeInstances: while executing mutation to unlock TypeInstances: All attempts fail:\n#1: graphql: "}

The strange thing is that I was able to unlock a given TypeInstance using GraphQL console exposed on Gateway.


Use loadFixture in Hardhat tests

This PR adds @nomicfoundation/hardhat-network-helpers and uses its loadFixture functionality in all beforeEachs.
On my machine, this makes test:ref go from ~106s to ~86s.

This is great! I adjusted the target branch to 1.2 as that's the main branch we're working off of now; think you could resolve the conflicts there?

Codecov Report
Base: 67.44% // Head: 100.00% // Increases project coverage by +32.55% :tada:

Coverage data is based on head (2229f63) compared to base (358cd2e).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff              @@
##              1.2      #791       +/-   ##
============================================
+ Coverage   67.44%   100.00%   +32.55%
============================================
  Files         100        27       -73
  Lines        4187      1233     -2954
  Branches      544       143      -401
============================================
- Hits         2824      1233     -1591
+ Misses       1344         0     -1344
+ Partials       19         0       -19

Flag
Coverage Δ

foundry
?

production
100.00% <ø> (ø)

reference
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

contracts/lib/OrderCombiner.sol
100.00% <0.00%> (ø)

contracts/lib/CounterManager.sol
100.00% <0.00%> (ø)

contracts/lib/OrderFulfiller.sol
100.00% <0.00%> (ø)

contracts/lib/ZoneInteraction.sol
100.00% <0.00%> (ø)

contracts/helpers/TransferHelper.sol
100.00% <0.00%> (ø)

contracts/lib/CriteriaResolution.sol
100.00% <0.00%> (ø)

contracts/lib/GettersAndDerivers.sol
100.00% <0.00%> (ø)

contracts/lib/BasicOrderFulfiller.sol
100.00% <0.00%> (ø)

contracts/lib/ConsiderationDecoder.sol
100.00% <0.00%> (ø)

contracts/lib/ConsiderationEncoder.sol
100.00% <0.00%> (ø)

... and 83 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


data: Stephanie Chester

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Hey @Stephanie-Chester, thank you for contributing 🎉 Please rename your file to data/Stephanie-Chester.json 👍

Thanks @khushalarora I have renamed the file, please let me know if it looks good now


Content Suggestion: BTCsessions

Link to Content: https://www.youtube.com/c/BTCSessions
Briefly Describe Content: bitcoin news and tutorials
Suggested Section: videos

Not reviewed

Removed from #307 and not added.


test_vim.py fails with Python 3.12

test_vim.py fails with Python 3.12 (Fedora 39). It works fine on Fedora 38 with Python 3.11.  Run ":checkhealth provider"'], None)
err = [0, 'Vim(python3):E319: No "python3" provider found. Run ":checkhealth provider"']
rv = None
    def request(self, method: AnyStr, *args: Any, **kwargs: Any) -> Any:
        """Send a msgpack-rpc request and block until as response is received.

        If the event loop is running, this method must have been called by a
        request or notification handler running on a greenlet. In that case,
        send the quest and yield to the parent greenlet until a response is
        available.

        When the event loop is not running, it will perform a blocking request
        like this:
        - Send the request
        - Run the loop until the response is available
        - Put requests/notifications received while waiting into a queue

        If the `async_` flag is present and True, a asynchronous notification
        is sent instead. This will never block, and the return value or error
        is ignored.
        """
        async_ = check_async(kwargs.pop('async_', None), kwargs, False)
        if async_:
            self._async_session.notify(method, args)
            return

        if kwargs:
            raise ValueError("request got unsupported keyword argument(s): {}"
                             .format(', '.join(kwargs.keys())))

        if self._is_running:
            v = self._yielding_request(method, args)
        else:
            v = self._blocking_request(method, args)
        if not v:
            # EOF
            raise OSError('EOF')
        err, rv = v
        if err:
            info("'Received error: %s", err)
>           raise self.error_wrapper(err)
E           pynvim.api.common.NvimError: Vim(python3):E319: No "python3" provider found. Run ":checkhealth provider"
pynvim/msgpack_rpc/session.py:137: NvimError
------------------------------ Captured log call -------------------------------
INFO     pynvim.msgpack_rpc.session:session.py:136 'Received error: [0, 'Vim(python3):E319: No "python3" provider found. Run ":checkhealth provider"']
=============================== warnings summary ===============================
test/test_buffer.py: 17 warnings
test/test_client_rpc.py: 4 warnings
test/test_concurrency.py: 2 warnings
test/test_events.py: 4 warnings
test/test_host.py: 4 warnings
test/test_tabpage.py: 5 warnings
test/test_vim.py: 20 warnings
test/test_window.py: 12 warnings
  /usr/lib64/python3.12/asyncio/events.py:824: DeprecationWarning: 'get_child_watcher' is deprecated as of Python 3.12 and will be removed in Python 3.14.
    return get_event_loop_policy().get_child_watcher()
test/test_buffer.py: 2 warnings
test/test_client_rpc.py: 1 warning
test/test_events.py: 1 warning
test/test_host.py: 1 warning
test/test_tabpage.py: 1 warning
test/test_vim.py: 3 warnings
test/test_window.py: 2 warnings
  /usr/lib/python3.12/site-packages/_pytest/unraisableexception.py:78: PytestUnraisableExceptionWarning: Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>

  Traceback (most recent call last):
    File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
      self.close()
    File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
      proto.pipe.close()
    File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
      self.write_eof()
    File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
      self._loop.call_soon(self._call_connection_lost, None)
    File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
      self._check_closed()
    File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
      raise RuntimeError('Event loop is closed')
  RuntimeError: Event loop is closed

    warnings.warn(pytest.PytestUnraisableExceptionWarning(msg))
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=========================== short test summary info ============================
FAILED test/test_vim.py::test_cwd - pynvim.api.common.NvimError: Vim(python3)...
================== 1 failed, 69 passed, 79 warnings in 3.04s ===================
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
    self.write_eof()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
    self._loop.call_soon(self._call_connection_lost, None)
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
    self._check_closed()
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
    self.write_eof()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
    self._loop.call_soon(self._call_connection_lost, None)
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
    self._check_closed()
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
    self.write_eof()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
    self._loop.call_soon(self._call_connection_lost, None)
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
    self._check_closed()
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
    self.write_eof()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
    self._loop.call_soon(self._call_connection_lost, None)
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
    self._check_closed()
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
    self.write_eof()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
    self._loop.call_soon(self._call_connection_lost, None)
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
    self._check_closed()
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
    self.write_eof()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
    self._loop.call_soon(self._call_connection_lost, None)
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
    self._check_closed()
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
    proto.pipe.close()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
    self.write_eof()
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
    self._loop.call_soon(self._call_connection_lost, None)
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
    self._check_closed()
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
RuntimeError: Event loop is closed
Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x7f92c10b1b20>
Traceback (most recent call last):
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 126, in __del__
  File "/usr/lib64/python3.12/asyncio/base_subprocess.py", line 104, in close
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 768, in close
  File "/usr/lib64/python3.12/asyncio/unix_events.py", line 754, in write_eof
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 772, in call_soon
  File "/usr/lib64/python3.12/asyncio/base_events.py", line 519, in _check_closed
RuntimeError: Event loop is closed
py312: exit 1 (3.54 seconds) /builddir/build/BUILD/pynvim-0.4.3> python -m pytest pid=458
  py312: FAIL code 1 (3.56=setup[0.01]+cmd[3.54] seconds)
  evaluation failed :( (3.63 seconds)

Duplicate of #528


Fix pinToSuperview ignoring relation parameter

This pull request fixes #9.

Thank you, must have broke that when upgrading. 😄


fix: CircleCI publish operates in ~/project

Seems like the default for CircleCI is to look into
/home/circleci/project so this restores the persisted files to that
location in order for the Docker Orb to work.
File under you-live-you-learn.

PR Storybook available here


Ask questions about extract_feature.py documents

see that you have commented out these two lines of code
"pd_csv=CyLSTM. merge_file_data (f" {toolConfiguration. ARDUPILOT-LOG-PATH}/logs/bin_ga/csv ")
CyLSTM. fit_trans (pd_csv) "
I need to run these two lines of code during the replication process to proceed with the subsequent work. What is the purpose of these two lines of code? And how do I allocate the number of CSV files in the bin_ga and bin_regular folders?

This code is used for data normalization


”Ciucurova”, ”Atmagea”, ”Fântâna Mare” are listed in the drop-down menu

Description:
When user writes ”Ciucurova”, ”Atmagea”, ”Fântâna Mare” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Ciucurova"

Expected results
The location appears in the drop-down menu as "Sat Ciucurova, TULCEA (Ciucurova)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Atmagea"

Expected results
The location appears in the drop-down menu as "Sat Atmagea, TULCEA (Ciucurova)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Fântâna Mare"

Expected results
The location appears in the drop-down menu as "Sat Fântâna Mare, TULCEA (Ciucurova)".


ncp-spinel: Add support for PROP_THREAD_ASSISTING_PORTS

This change adds support for the PROP_THREAD_ASSISTING_PORTS Spinel
property, using the the new otAddUnsecurePort(), otRemoveUnsecurePort(),
and otGetUnsecurePorts() APIs that were added in #196.
This commit closes #202.

LGTM :+1: