Exclude combinations from parametrized matrix builds

I'm using the @parametrize decorator to create a build matrix, but i've got certain combinations I wish to exclude.
right now i'm using a little escape hatch
if valid_combination(*deps):
    run_tests(session, *deps)
else:
    session.skip("unsupported combination")

would be nice if Nox could provide an API for adding or removing 'cells' from the matrix (similarly to what you can do with github actions)

Hmm. How would you like this to work from the command-line perspective?

Hmm. How would you like this to work from the command-line perspective?

I've not really thought about what the API would look like. Can you clarify what you mean by "from the command-line perspective"?
I would think if you try to run a particular session from the command line that is in the 'excluded' list it would behave the same way as if you specified a session that was entirely outside your parametrize range. Having said that, a slightly helpful warning/error would help the unwary figure out why the session doesn't exist.
maybe something like

PYTHON_VERSIONS = ["3.6", "3.7", "3.8"]
MY_DEP_VERSIONS = ["1.0", "2.0"]

@nox.session(python=PYTHON_VERSIONS)
@nox.parametrize("my_dep", MY_DEP_VERSIONS)
@nox.parametrize_exclude({"python": "3.6", "my_dep": "2.0"})
def tests(python, my_dep):
    session.install(f'my_dep=={my_dep}')
    session.run('pytest')

i write this with absolutely 0 knowledge of how these decorators are implemented, so I've no idea if this is sensible
probably the values in @nox.paramatrize_exclude could also be Iterables. as in-
@nox.parametrize_exclude({"python": ["3.5, "3.6"], "my_dep": "2.0"})

which would mean "any session where the python version is in ["3.5, "3.6"] and my_dep is in ["2.0"] is excluded".
Maybe keyword arguments would be more readable than a dict? i dunno.
the use case would be to exclude combinations that you don't care about (for whatever reason), or that you already know don't work and are excluded by your dependency requirements anyway
You could also invert the logic as well, and have an API for adding extra cases to the matrix. parametrise_include, if you will.
bonus points for

warning if patterns are excluded that aren't in the matrix anyway
warning if pattern excludes the entire matrix
warning/error if any parametrize_include statement overlaps with any parametrize_exclude statement (since there's no reason to ever have this)

just to add to that, one workaround would be to have multiple test functions, and manually exclude the cases you weren't interested in.
If i reuse the sketch above it would look something like this-

@nox.session(python="3.6")
@nox.parametrize("my_dep", ["1.0"])
def tests_py36(python, my_dep):
    session.install(f'my_dep=={my_dep}')
    session.run('pytest')

@nox.session(python=["3.7", "3.8"])
@nox.parametrize("my_dep", ["1.0", "2.0"])
def tests(python, my_dep):
    session.install(f'my_dep=={my_dep}')
    session.run('pytest')

but it's a little bit ugly, and it's not going to be as easy to stick in a github action. If you have a single 'tests' function, then you can do
run: nox --non-interactive --session "tests-${{ matrix.python-version }}(my_dep='${{matrix.my_dep-version}}')" -- --full-trace

now you can already exclude cases from a github action matrix, that's no problem. But the proposed API would allow you to align this with what you get when simply run nox on the command-line

I had a quick look at the decorators, I don't imagine it would be too difficult to implement these proposed decorators as essentially filters to the Params list.
Most of the warnings i listed above would be easy enough too, except for warning on overlap 'include' + 'exclude'. That would take some thought. I guess you'd have to thread some metadata through the decorators to track that information

I've got a working draft of these decorators. Would like to know if

this is of interest
2  what the desired API would look like

Before investing too much more time

I think that the most convenient way would be to provide a "build matrix" dictionary, where

the key is the session final id
the value is a dictionary containing at least a "python=xx" entry, and the rest of the dictionary should correspond to the parametrized arguments.

For example I have a current code working with :
ENVS = {
    # python 2.7
    "py27-pytest2.x": {"python": PY27, "pip": ">19", "pytest": "<3", "pytest-asyncio": DONT_INSTALL},  # "pytest-html": "1.9.0",
    "py27-pytest3.x": {"python": PY27, "pip": ">19", "pytest": "<4"},
    "py27-pytest4.x": {"python": PY27, "pip": ">19", "pytest": "<5"},
    # python 3.5
    "py35-pytest2.x": {"python": PY35, "pip": ">19", "pytest": "<3", "pytest-asyncio": DONT_INSTALL},  # "pytest-html": "1.9.0",
    "py35-pytest3.x": {"python": PY35, "pip": ">19", "pytest": "<4"},
    "py35-pytest4.x": {"python": PY35, "pip": ">19", "pytest": "<5"},
    "py35-pytest5.x": {"python": PY35, "pip": ">19", "pytest": "<6"},
    "py35-pytest-latest": {"python": PY35, "pip": ">19", "pytest": ""},
    # python 3.6
    "py36-pytest2.x": {"python": PY36, "pip": ">19", "pytest": "<3", "pytest-asyncio": DONT_INSTALL},  # "pytest-html": "1.9.0",
    "py36-pytest3.x": {"python": PY36, "pip": ">19", "pytest": "<4"},
    "py36-pytest4.x": {"python": PY36, "pip": ">19", "pytest": "<5"},
    "py36-pytest5.x": {"python": PY36, "pip": ">19", "pytest": "<6"},
    "py36-pytest-latest": {"python": PY36, "pip": ">19", "pytest": ""},
    # python 3.7
    "py37-pytest2.x": {"python": PY37, "pip": ">19", "pytest": "<3", "pytest-asyncio": DONT_INSTALL},  # "pytest-html": "1.9.0",
    "py37-pytest3.x": {"python": PY37, "pip": ">19", "pytest": "<4"},
    "py37-pytest4.x": {"python": PY37, "pip": ">19", "pytest": "<5"},
    "py37-pytest5.x": {"python": PY37, "pip": ">19", "pytest": "<6"},
    "py37-pytest-latest": {"python": PY37, "pip": ">19", "pytest": ""},
    # python 3.8
    "py38-pytest2.x": {"python": PY38, "pip": ">19", "pytest": "<3", "pytest-asyncio": DONT_INSTALL},  # "pytest-html": "1.9.0",
    "py38-pytest3.x": {"python": PY38, "pip": ">19", "pytest": "<4"},
    "py38-pytest4.x": {"python": PY38, "pip": ">19", "pytest": "<5"},
    "py38-pytest5.x": {"python": PY38, "pip": ">19", "pytest": "<6"},
    "py38-pytest-latest": {"python": PY38, "pip": ">19", "pytest": ""}
}

I'd just like to note that nox.parametrize is already expressive enough to handle a sparse build matrix:
import nox

@nox.session
@nox.parametrize(
    "python,my_dep",
    [
        (python, my_dep)
        for python in ("3.6", "3.7", "3.8")
        for my_dep in ("1.0", "2.0")
        if (python, my_dep) != ("3.6", "2.0")
    ],
)
def tests(session, python, my_dep):
    print(f"{python =} {my_dep = }")

So the issue is not expressivity. It's the fact that nox.parametrize cannot set session attributes such as the Python interpreter.
I'm not proposing to start treating parameters named "python" in a special way. To start with, that would not be backward compatible. Would it make sense though to add a keyword argument to @nox.parametrize that lists parameters that should be passed to the session decorator instead of the session function?

However we approach this, the API should match pytest as much as possible.
For example pytest.param is used to set meta attribute such as the test ID.
Nox has implicit parameterization on the Python version, so it might be useful to make that explicit somehow.

Would it make sense though to add a keyword argument to @nox.parametrize that lists parameters that should be passed to the session decorator instead of the session function?

I like this idea !

To make this a bit more concrete, these two would be equivalent:
@nox.session
@nox.parametrize("python", ["3.6", "3.7", "3.8"], sessionparams=["python"])
def tests(session):
    pass

@nox.session(python=["3.6", "3.7", "3.8"])
def tests(session):
    pass

Not sure if sessionparams is useful for anything but the Python version at the moment.

However we approach this, the API should match pytest as much as possible.

Agreed. Is there some primitive in the pytest API that assigns metadata to the params themselves? IIUC, pytest.param applies to the individual values passed through the params.

Is there some primitive in the pytest API that assigns metadata to the params themselves?

Not that I know. Not sure that you can do much better than your proposal here :)

Not sure if sessionparams is useful for anything but the Python version at the moment.

It would be great to support the following use cases related to the session documentation (currently from the function docstring):

modify the session documentation explicitly thanks to a doc arg in session (that would be propagated from the parametrize through sessionparams)

accept that the docstring is written with the newstyle formatting "foo {bar} foo" so as to generate the associated session documentation for each position in the grid by calling func.__doc__.format(**params).

By the way, the default value of sessionparams could be None and mean : "all known session kwargs that are present in this list" (python, and doc if the above is implemented) so that users do not need to specify it explicitly in most situations.

@theacodes Should we give this a go?
@danieleades How do you feel about the approach of allowing nox.parametrize to set the Python interpreter? Since you've already put work into this, would you like to take a stab at implementing it (if @theacodes is happy with it)? Give a shout if you'd like any pointers :)
@smarie

modify the session documentation explicitly thanks to a doc arg in session (that would be propagated from the parametrize through sessionparams)
accept that the docstring is written with the newstyle formatting "foo {bar} foo" so as to generate the associated session documentation for each position in the grid by calling func.doc.format(**params).

Currently, nox -l prints the session signature followed by the first line of the docstring. The latter is the same for every parametrization (and every Python). I also feel that this could be improved.
The problem I see with a str.format approach is that it's still quite rigid, and the output already includes parameters in the session names (they're needed for -k). So I'm worried that the session listing would get even more repetitive. Printing descriptions only once for each session group, possibly combined with using the ids keyword, seems to do more to improve readability. Or am I missing something here?

By the way, the default value of sessionparams could be None and mean : "all known session kwargs that are present in this list" (python, and doc if the above is implemented) so that users do not need to specify it explicitly in most situations.

The thing is that users might be using these names for ordinary parameters. We could go a path of deprecation here, of course. Personally, I kind of like the fact that all parameter names are created equal unless explicitly mentioned in sessionparams.
By the way, a different approach that does not have this problem would be to use something other than strings for special parameters, e.g. nox.params.python which could be some kind of enum. But that does not play well with the fact that parameter names are listed as a comma-separated string. So I think that kind of rules this approach out.

Give it a go, I'm cool with it as long as it doesn't break existing
noxfiles.
On Fri, Mar 5, 2021, 12:55 PM Claudio Jolowicz<EMAIL_ADDRESS>wrote:

@theacodes https://github.com/theacodes Should we give this a go?
@danieleades https://github.com/danieleades How do you feel about the
approach of allowing nox.parametrize to set the Python interpreter? Since
you've already put work into this, would you like to take a stab at
implementing it (if @theacodes https://github.com/theacodes is happy
with it)? Give a shout if you'd like any pointers :)
@smarie https://github.com/smarie
modify the session documentation explicitly thanks to a doc arg in session
(that would be propagated from the parametrize through sessionparams)
accept that the docstring is written with the newstyle formatting "foo
{bar} foo" so as to generate the associated session documentation for each
position in the grid by calling func.doc.format(**params).
Currently, nox -l prints the session signature followed by the first line
of the docstring. The latter is the same for every parametrization (and
every Python). I also feel that this could be improved.
The problem I see with a str.format approach is that it's still quite
rigid, and the output already includes parameters in the session names
(they're needed for -k). So I'm worried that the session listing would
get even more repetitive. Printing descriptions only once for each session
group, possibly combined with using the ids keyword, seems to do more to
improve readability. Or am I missing something here?
By the way, the default value of sessionparams could be None and mean :
"all known session kwargs that are present in this list" (python, and doc
if the above is implemented) so that users do not need to specify it
explicitly in most situations.
The thing is that users might be using these names for ordinary
parameters. We could go a path of deprecation here, of course. Personally,
I kind of like the fact that all parameter names are created equal unless
explicitly mentioned in sessionparams.
By the way, a different approach that does not have this problem would be
to use something other than strings for special parameters, e.g.
nox.params.python which could be some kind of enum. But that does not
play well with the fact that parameter names are listed as a
comma-separated string. So I think that kind of rules this approach out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/theacodes/nox/issues/392#issuecomment-791582913, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5I475WYUFFSB4NLZ3LBLTCELIHANCNFSM4YMSV6WA
.

I decided to have a go at this in #404

I like this. With the proper level of documentation about what you just mentioned ("if python is an argument of the session function it will be used as a parameter") then it is understandable.

I was going to omit this from the documentation, actually. While we shouldn't break anybody who is using "python" as a normal parameter, I also don't think we should encourage this usage. I have no idea how many people are doing this. If this is a thing, then yes, we should probably mention that it'll continue to work (but discourage it?).

What about other session parameters, would it make sense to have them follow the same principle ?
(reuse_venv, name, venv_backend, venv_params). At least for name this seems redundant with ids ..

Yes, I think that would work in principle. Do you see a use case for parametrizing any of these?

I was going to omit this from the documentation, actually.

I would recommend that all "features" are documented. Otherwise people end up thinking that the lib is not able to do this, because they just don't know what the "happy few" know :)

Do you see a use case for parametrizing any of these?

For the "name" yes, I would be able to give a custom name to each of my sessions when several argnames are parametrized, rather than trying to customize the "ids" function so that it works. This is a problem in pytest as well: you can not specify a unique id for a combination of parametrized argnames, as the ids param applies to each independetly rather than acts as a replacement for the whole group.
For the venv_backend and other venv related params, I guess that using it in parameters will allow people to test that something works both using conda, venv and virtualenv. Maybe edge users, but if this does not cost anything more than parametrizong the python then maybe worth it


NullException by git checkout with a multiproject workspace

Describe the bug
Get an error when using "git checkout" on a multiproject workspace right after opening VSCode.
[Error - 10:28:18] Please report this issue to https://github.com/microsoft/al/issues including information on how to reproduce it, if possible.
Processing of message 'workspace/didChangeWatchedFiles' failed with error: 'Der Wert darf nicht NULL sein.
Parametername: projectId'
Details:
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: projectId
   bei Microsoft.Dynamics.Nav.CodeAnalysis.Workspaces.DocumentId.CreateNewId(ProjectId projectId, String debugName) in F:\a\460\s\source\Prod\Microsoft.Dynamics.Nav.CodeAnalysis.Workspaces\Workspace\Solution\DocumentId.cs:Zeile 74.
   bei Microsoft.Dynamics.Nav.EditorServices.Protocol.BufferManager.TryAddTransientDocument(String filePath, String text, Boolean handleRad, DocumentId& documentId) in F:\a\460\s\source\Prod\Microsoft.Dynamics.Nav.EditorServices.Protocol\BufferManager.cs:Zeile 177.
   bei Microsoft.Dynamics.Nav.EditorServices.Protocol.LanguageServer.DidChangeWatchedFilesRequestHandler.HandleAsync(DidChangeWatchedFilesRequest request, Int32 requestId, CancellationToken cancellationToken) in F:\a\460\s\source\Prod\Microsoft.Dynamics.Nav.EditorServices.Protocol\LanguageServer\DidChangeWatchedFilesRequestHandler.cs:Zeile 30.
   bei Microsoft.Dynamics.Nav.EditorServices.Protocol.MessageProtocol.RequestHandlerBase`1.<HandleAsync>d__9.MoveNext() in F:\a\460\s\source\Prod\Microsoft.Dynamics.Nav.EditorServices.Protocol\MessageProtocol\RequestHandlerBase.cs:Zeile 43.

To Reproduce

Open a .workspace-file from VSCode with more than one AL-Project.
Checkout a different branch than your current one with "git checkout [branchname]". I even can reproduce the bug by using the "Checkout To"-Action from my source control.
Exception is thrown.

Expected behavior
The error should not be thrown. I am not sure what is effected by the error, but from time to time VSCode shows some warning/errors in my project B that objects from my project A "does not contain a definition", but they do.
Already discussed here: https://www.yammer.com/dynamicsnavdev/threads/361551778758656. Not sure if this error is related to this behavior.
5. Versions:

AL Language: 4.0.176004
Business Central: Plattform 15.0.36510.0 + Anwendung 15.0.36590.0 (docker hosted)

Hi! What is different between the two branches?

The only difference I can see so far is that the branch I want to check out is not available on remote. Not sure what happens if the remote branch still exists. Need to check it on Monday.

Hi @AndreasGloeckner thank you for reporting the issue. I tried to reproduce it using your steps with no success. We recently worked on something similar, could try to reproduce it with the latest AL Extension from market place. If it is still there, could you please attach a workspace demonstrating the issue. Thanks.

Hi @AndreyKorepanov. I installed the latest verison from the marketplace (<IP_ADDRESS>0) and deactivated the old version. Nevertheless, I still get the exception.
No files were opened in the same or another instance of VSCode.
Tested following scenarios:

Open one folder, checkout another branch => no error
Open one folder, add another project, checkout another branch => no error
Open one folder, add two other projects, ceckout another branch => no error. This is nearly the same initial situation unless I added the folders manually.
I open the original saved .code-workspace file with the three projects from step 3. Checkout a branch => Error occurs.

Then I created the same workspace again (see step 3). Saved it. Closed VSCode. Opened the .code-workspace and checkout another branch => no error.
I compared the workspaces: They are identical. Don't know what's the cause...
See here (had to rename the file extension):
Test.txt

Hi @AndreasGloeckner, it seems the problem is with the documents added in the branch you are switching to. We'll take care of it.

Sorry, but what documents? And why does it work if I create the same workspace again?

Are there any news? Still got the error with VSCode Version 1.42.1 and AL Language 4.0.206840.

This issue has been added to our backlog, but we cannot provide an estimate of when we will actively start working on it.


Python 2 End of Life

Update CI configuration to only test Python 3.

Coverage remained the same at 100.0% when pulling ba798a1a19a7dec8d340d046a2f6ffda2fb8c6d4 on packaging into 6f90791f7304b6bc5b269959fbdfd07b4080a4cb on master.

Coverage remained the same at 100.0% when pulling ba798a1a19a7dec8d340d046a2f6ffda2fb8c6d4 on packaging into 6f90791f7304b6bc5b269959fbdfd07b4080a4cb on master.


chore: disable unnecessary type check in Dispatcher test

Signed-off-by: Jakub Koci<EMAIL_ADDRESS>

Codecov Report

Merging #565 (42c25a9) into main (4e7b9cf) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #565   +/-   ##
=======================================
  Coverage   86.01%   86.01%
=======================================
  Files         267      267
  Lines        5840     5840
  Branches      875      875
=======================================
  Hits         5023     5023
  Misses        814      814
  Partials        3        3

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 4e7b9cf...42c25a9. Read the comment docs.


fix: do not discard already present set-cookie header

This PR aims at fixing the current behavior of nuxt-i18n when setting the detected language cookie.
If someone were to set a cookie within a Nuxt server-middleware (e.g. a CSRF token cookie), it will be discarded only the first time nuxt-i18n is setting the language redirection cookie.
The root cause comes from using res.setHeader('Set-Cookie', redirectCookie): it no longer implicitly append the cookie value to the current list of Set-Cookie values in Express > 4, as explained here: https://github.com/expressjs/express/wiki/Migrating-from-3.x-to-4.x#ressetheaderset-cookie-val
To keep compatibility of this middleware with requests/responses from Express/Connect/etc., using the cookies package instead of cookie seems like a sensible choice to me, and fixes nicely the issue.
If I missed something while refactoring the code, please let me know so we can find the most elegant and robust solution.

LGTM! Thank you @rclement !

Another way to fix that would be to get existing cookies and modify the array. Maybe that' better option than introducing this heavier dependency


bug in logging http.url

I'm not sure which side did this, but something in the jersey trace filter is printing a toString, not a url.
https://github.com/openzipkin/jaeger-jersey-example
      {
        "key": "http.url",
        "value": "org.glassfish.jersey.server.internal.routing.UriRoutingContext@20bca98f"
      },
      {
        "key": "http.url",
        "value": "http://localhost:9000/api"
      },

@adriancole thanks for catching this.
@vprithvi can you take a look?

This is such a coincidence, I was just about to open a ticket for the same. It's incorrectly set in the filter, and has no tests. I'll fix it!


[FR] Crossfade effect when scrubbing through song

Description
Can we please implement a cross fade effect option so when skipping around a song it isn't so jarring? (like how the audio fades out when you pause, or fades in when you hit play)
Maybe also have a feature for cross fade between multiple songs? e.g. prev/next would cross fade both tracks. Spotify has an option for this to demo it: https://support.spotify.com/us/article/crossfade-feature/

Thanks, Stale Bot.

We meet again, Stale Bot.

It seems that some streaming servers use this library...
Crossfade would be a really nice feature, indeed... Personally it's always been towards the top requirements for an audio player


Unable to schedule the export

Hi, I've set up everything and export runs succesfully. However I can't seem to schedule the export. When I click Schedule Export it tells me to check the Job Queue Entries but the scheduled job does not appear there. I am not that experienced with BC so maybe I'm doing something wrong.

It showed up briefly for a colleague, but then dissapeared as well. We found it in the Logs however. With the information shown there we ended up creating a manual Job Queue Entry Card with the corresponding Object ID for the export.


Give PSArm block an alias-free environment so property keywords work

Fixes https://github.com/PowerShell/PSArm/issues/126.
In this PR, we use internal PowerShell engine APIs to tear down the aliases in each parent scope and store them while the Arm block body is executed. When execution is complete, we then restore the alias definitions to each scope using other internal PowerShell engine APIs.

The changes look fine, but can you please add more context information in the PR description about why an alias-free environment is needed? The referenced issue doesn't have the related context information either.

I've updated the issue to describe the problem and the PR to describe the solution (the solution description not as detailed).


[DDW-839] Delegation setup improvements

This PR fix delegation section issues.
Todos

[x] Delegation Centre header percentage rounding
[x] Enable wallet selection "also" with 1ADA on Delegation setup dialog.

Screenshots
Delegation Centre header percentage rounding

Delegation setup dialog with 1ADA selected

Testing Checklist

Slack QA thread

[ ] Test Storybook story under: Staking -> Delegation Center - percentage in header should be rounded to max 2 decimals

[ ] Test Storybook story under: Staking -> DelegationStepsChooseWalletDialog - When you select wallet with exact 1ADA or more you should not see error message anymore.

Review Checklist
Basics

[ ] PR has been assigned and has appropriate labels (feature/bug/chore, release-x.x.x)
[ ] PR is updated to the most recent version of the target branch (and there are no conflicts)
[ ] PR has a good description that summarizes all changes and shows some screenshots or animated GIFs of important UI changes
[ ] CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub
[ ] Automated tests: All acceptance and unit tests are passing (yarn test)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in development build (yarn dev)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in production build (yarn package / CI builds)
[ ] There are no flow errors or warnings (yarn flow:test)
[ ] There are no lint errors or warnings (yarn lint)
[ ] There are no prettier errors or warnings (yarn prettier:check)
[ ] There are no missing translations (running yarn manage:translations produces no changes)
[ ] Text changes are proofread and approved (Jane Wild / Amy Reeve)
[ ] Japanese text changes are proofread and approved (Junko Oda)
[ ] UI changes look good in all themes (Alexander Rukin)
[ ] Storybook works and no stories are broken (yarn storybook)
[ ] In case of dependency changes yarn.lock file is updated

Code Quality

[ ] Important parts of the code are properly commented and documented
[ ] Code is properly typed with flow
[ ] React components are split-up enough to avoid unnecessary re-renderings
[ ] Any code that only works in main process is neatly separated from components

Testing

[ ] New feature/change is covered by acceptance tests
[ ] New feature/change is manually tested and approved by QA team
[ ] All existing acceptance tests are still up-to-date
[ ] New feature/change is covered by Daedalus Testing scenario
[ ] All existing Daedalus Testing scenarios are still up-to-date

After Review

[ ] Merge the PR
[ ] Delete the source branch
[ ] Move the ticket to done column on the YouTrack board
[ ] Update Slack QA thread by marking it with a green checkmark

@tomothespian please implement the change @yakovkaravelov requested (https://github.com/input-output-hk/daedalus/pull/1545#discussion_r316727361) and then we are ready to get this one merged 🙏


Site Kit page: fix search console API was renamed webmasters->searchconsole.

Follow up to https://github.com/google/WebFundamentals/pull/9252, this PR fixes an error shown when clicking the "Get Oauth Credentials" button.
Couldn't initialize Service 'webmasters.googleapis.com' not found or permission denied.
The error is caused because the Search Console API has been renamed and we can no longer create apps with the service webmasters.googleapis.com. Instead, we need to use the service name searchconsole.googleapis.com.
Target Live Date: YYYY-MM-DD

[ ] This has been reviewed and approved by (NAME)
[ ] I have run npm test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[ ] I've staged the site and manually verified that my content displays correctly.

CC: @petele

@petele Can you please review this when you have a chance!


feat: include raw response bodies in APIErrors

This adds raw error response bodies to APIErrors. This is a breaking change, as it modifies the public kong.NewAPIError() function signature, adding a new raw []byte parameter for the raw body.
go-kong does not provide universal coverage of all Kong endpoints, and does not have rich error handling for all endpoints it does cover. Currently, go-kong reads the body of any admin API error response (consuming it, so nothing downstream can read it) and extracts the message field for inclusion in the APIError it returns. It is not possible to perform further parsing on error bodies if desired.
Adding the raw response allows downstream clients to handle their own error parsing, primarily for ad-hoc requests where downstream builds its own requests and runs it via a go-kong client. I think this is also necessary for further parsing inside go-kong (I don't think raw bodies were available to go-kong services either), but need to confirm.

This came up in the context of KIC handling POST /config requests. go-kong does not provide a service for /config and does not provide error parsing for it as such. message isn't useful for this endpoint because it's a compressed version of the more machine-readable fields field those error responses.

Undrafting this in prep for expected gateway changes in FTI-4366. Although the expected format still isn't set in stone, getting this into go-kong will let us iterate rapidly on future gateway changes, since we'll always have the raw response available.


dialog opened with TemplateRef that contains ng-content is not cleaned up properly on close, causing stacking issues

See https://gist.run/?id=f3741ab47081095d12931e25acb6ce80

open dialog
select something in autocomplete (optional)
close dialog
open again
click on autocomplete

This stays in dom after closing the dialog for the first time

causing stacking issues the next time it is opened
@crisbeto @jelbourn

I tried looking into this a while ago and the issue is that a TemplateRef can't be associated with an injector. In the case of the close button we can fall back to closing the top dialog, but we probably need a better way of exposing the dialog.


[Feature]: Change CustomData to map[string]string

Tell us about your feature request
Why is CustomData a map[string]any if the value is always a string?
What problem are you looking to solve?
Changing it to map[string]string would make it easier to use
Additional context
No response
How important is this suggestion to you?
Nice to have

Hi @goenning :wave: Thank you for raising this issue.
The SDK currently reflects the API specification, which allows any object for custom_data (API Spec):
custom_data:
  title: Custom data
  type: object

If at any point in future this changes in the API, it would be reflected in the SDK.

how do I set custom_data values as numbers?

In Go, the custom data could be created as follows:
paddle.CustomData{
	"key1": "string value",
	"key2": 1,
	"key3": 1.2,
}

The resulting JSON object would look like this:
{
    "key1": "string value",
    "key2": 1,
    "key3": 1.2
}

When I get the webhook requests, the custom data values are always Strings

Hi @goenning :wave:
The paddle.com dashboard currently only supports creation/update of custom data with string values. However, nested custom data (with different value types) can be created via the API (using SDK), which is currently readonly in the dashboard. The dashboard will support nested custom data in future.


Document the planus crate

Feedback / error corrections welcome. It could probably still use some more examples and some more low level details, e.g. in traits.rs.
Checklist

[ ] Updated CHANGELOG.md with relevant changes
[x] Added tests for any new/fixed functionality
[x] Added/updated documentation for new/changed code <-- lol
[ ] Checked that README.md still makes sense (and updated it if necessary)

Closes #80


method arguments not rendering correctly in ReadTheDocs

The argument name and type are joined in one string but they should be separate , see the screenshot.

Probably the same problem as https://github.com/spacetelescope/jwql/issues/514

In my opinion, something must have changes since I first implemented this since I remember verifying that the rendering was fine.


#461: Don't forget to pass data argument forward

Not sure if there is need to duplicate signatures from ClientSession there, so open for comments.

I'm ok with just dropping data parameter.
Ideally it would be cool to have full signatures in our shortcuts.
I don't afraid code duplication but we need tests that make sure signatures are match.

I've merged it into 0.17 branch, I believe we should publish buxfix release with the change.


Search editor doesn’t highlight some C/C++ files

Search editor should highlight cxx, hxx, hh, c++, h++ as C++.

Ref #104339.


Implement reading from stdin

add builtins to read from standard input / output
read -> returns Ast.Literal
readNum -> returns Ast.Num

This is blocked by #75

This is blocked by #75

Fixed  with MR #75


why the data-cell must be [A-Z]+\d+ ?

why the data-cell must be macth [A-Z]+\d+ ?
how to confgure like taxMny1 reg: [A-Za-z]+\d+ or [A-Za-z]+\d+[A-Za-z]+
i found data-cell attr value only work such as A1 A2 K3 TEST1 , but no work like money1 tableName1_price

because at the first time, this plugin is intended to help me convert large excel based calculation into web form.


CSG auto unwrap feature and UV mapping editing

Godot 3 alpha 5
CSG with a texture applied, when it's scaled in one axis , gets the texture deformed, assets are not usable.
Some option to auto unwrap when a CSG object is scaled in some axis would make CSG something usable with texture to create game assets.
Something like Unity Probuilder plugin, that keeps constant UV mapping units and auto unwrap.
Another feature for CSG would be like Unity Probuilder, some UV editor tool to change UV mapping when needed.
One issue is the default cylinder UV map is not good.
It's not uniform on UV and cylinder caps should be top down view flat mapping.
The auto unwrap option would resolve such issues.

I think @Ace-Dragon is referring to the triplanar mapping option in SpatialMaterial. Keep in mind it has a performance cost, which means it should be used only when necessary.

This is why auto unwrap with some option values like angle for auto seams, would be a good option to automatically unwrap the mesh to avoid deformations.
Once unwrap is made there is no need for triplanar shader that have big GPU cost.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Initially the Play & More Info Button is not showing icons instead some text.

Describe the bug
Initially the Play & More Info Button is not showing icons instead some text.
To Reproduce
Steps to reproduce the behavior:

In the Home page
Do force refresh ie, CTRL + F5
Then for some times on the Play & more info icon an text will be shown not the icon.

The issue was because the default behaviour of google material icon.
The issue has been resolved now.


[code-completion] Add type context for single-expression closures

When completing in the only expression of closure, use the return type of the closure as the type context for the code-completion. However, since code-completion may be on an incomplete input, we only use the return type to improve the quality of the result, not to mark it invalid, since (a) we may add another statement afterwards, or (b) if the context type is Void it doesn't need to match the value.

@swift-ci please test

@rintaro this is a bit different than we discussed.  Instead of handling Void specially, I keep track of whether the type context is from a single-expression body and in that case do not mark anything as type-relation "invalid".

Build failed
Swift Test Linux Platform
Git Sha - b817cbb9bcbe121d6b554d6bd80cb20f595c4a63

Build failed
Swift Test OS X Platform
Git Sha - b817cbb9bcbe121d6b554d6bd80cb20f595c4a63

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - b817cbb9bcbe121d6b554d6bd80cb20f595c4a63

Build failed
Swift Test OS X Platform
Git Sha - b817cbb9bcbe121d6b554d6bd80cb20f595c4a63

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - f8a3afb7bb6c7e17e65a4467ee8ab35a1dcecd10

Build failed
Swift Test OS X Platform
Git Sha - f8a3afb7bb6c7e17e65a4467ee8ab35a1dcecd10

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 2b5a8a5be7911be7094fb6f2eec2c6b7705b5fe6

Build failed
Swift Test Linux Platform
Git Sha - 2b5a8a5be7911be7094fb6f2eec2c6b7705b5fe6

@swift-ci please test macOS


Add Inv and Pow traits.

This is not a breaking change, and closes #34 and #38.
This doesn't add any impls for the other num crates, just floats with std enabled. The trait has to be added before those other crates can be updated.

I figured I'd implement #38 in this as well considering how I was going to offer both, and I don't want to deal with merge conflicts. Let me know if everything looks alright!

Let's put Pow into the existing pow module, instead of under ops.

Should be ready to merge now.

Sorry if I misspoke, but I did not mean that we should have so many variations of Pow implementations.  Do you have your own reasons for all them?  I'm especially worried about the ones with lossy as casts.  Just the basic natively-supported pow implementations looked good to me.

@cuviper I accidentally added the u64 casts in error, but the rest are lossless casts (such as u8 as u32).
My main reasoning was to do something similar to how Shl is done in the standard library: https://doc.rust-lang.org/std/ops/trait.Shl.html

Ah, I got confused by the macros, and thought you had some signed->unsigned casts in there too.
Can we do it without the closures though?  I think if you leverage From/Into, then the final implementation can be just $method(self, rhs.into()), where $method is either the type's inherent pow or num's pow for usize.  No as casting at all.
Should floats do u32 and usize with num's pow too?  And perhaps also u8 and u16 this way under no_std (without powi)?
I count 372 Pow implementations so far in the generated docs!  The downside is that all this does significantly increase the compilation time, compared to the current master branch.

I think that doing without the closures is very fair and I'll refactor this in a bit to achieve that. Also I just noticed rust-lang/rust#48321 and I think that simply deferring to wrapping_pow once it's stable would be better for Wrapping, and that those impls can just be removed for now to avoid compile time hikes.
I'll see what I can do about benchmarking compile times and how that can be improved.

To put real numbers on it, cargo build --release goes from 0.72 seconds to 1.3 seconds on my i7-7700k.  That's still bearable, but quite a significant increase for just one feature.

I don't think a double in compile time is acceptable; I'll see what I can do.

@cuviper with the latest change, my compile time went from 2.29s to 1.84s, which is only a 20% increase. Could you provide benchmarks on your end?
Longer-term it may be best to make the standalone pow function private and change the usize exponent to a u64 for compatibility. This is breaking, obviously, and I didn't do that.

For me it's now 0.86s vs master's 0.72s -- that seems fine.  There are still a lot of implementations -- 292 -- so I'd guess the closures were the main culprit for the slowdown.
Let's merge!
bors r+

Awesome! Could you push a new version of num-traits with these changes added?

Yeah, but I still want to revisit FloatCore and perhaps add some more to it before it's published.  I'll try to do this today.

That's fair; no rush. :)


All projectiles are crashing my server

I'm pretty sure all of them crash the server, I have tested, Bows, experience bottles, snowballs, all types of potions, ender pearls and fireworks. The log:
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x958d7b]

goroutine 55 [running]:
github.com/df-mc/dragonfly/server/session.(*Session).handlePackets.func1()
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/session/session.go:303 +0x74
panic({0xe230a0, 0x1b70900})
        C:/Program Files/Go/src/runtime/panic.go:884 +0x212
github.com/df-mc/dragonfly/server/item.Bow.Release({}, {0x13703b8, 0xc0010482c0}, 0x5bd14d6c, 0xc000098210)
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/item/bow.go:86 +0x77b
github.com/df-mc/dragonfly/server/player.(*Player).ReleaseItem(0xc0010482c0)
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/player/player.go:1330 +0x2a2
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/session/player.go:659 +0x6c
github.com/df-mc/dragonfly/server/session.(*MobEquipmentHandler).Handle(0xe1ea20, {0x135fec0?, 0xc004b5c930}, 0xc0001bee00?)
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/session/handler_mob_equipment.go:24 +0x1c5
github.com/df-mc/dragonfly/server/session.(*Session).handlePacket(0xc0001bee00, {0x135fec0, 0xc004b5c930})
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/session/session.go:432 +0x9b
github.com/df-mc/dragonfly/server/session.(*Session).handlePackets(0xc0001bee00)
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/session/session.go:312 +0xef
created by github.com/df-mc/dragonfly/server/session.(*Session).Start
        C:/Users/Cobra/go/pkg/mod/github.com/df-mc/dragonfly@v0.9.6-0.20230507195931-1877140372de/server/session/session.go:217 +0xa5
exit status 2

are you using any multiworld providers

No I'm not

are you using any multiworld providers

We're using vhandler for player handlers, but we didn't use any world handler

It crashes the server both in the default world and the other worlds

"the other worlds" i thought you were not using a multi world provider


A few small refactors to reduce code complexity

Using radon as a guide, this splits up a few of the more egregiously complex functions. This'll be easiest to review commit by commit.

Integration test errors will be resolved once 18F/atf-eregs#459 is merged


Lots of broken documentation links

Your documentation is pretty much inaccessible at the moment
Seeing lots of broken links.

migration guide link from github readme
documentation link from both github readme
getting started from https://kodein.org/di/
core documentation from https://kodein.org/di/

Sorry for the trouble, we are moving the documentation onto Antora, so the the link format has changed.
The new docs will be available in a couple of days!

docs are back https://kodein.org/Kodein-DI/index.html.
Sorry again.


fix report not creating sub directories

Hello. The report fails with FileNotFoundError due to non-existing sub directories (e.g. "canary_mia/attacksComparison_Datasetresults/"). The original code only create directories from output_path (e.g. "canary_mia"), however filename can be a path with directories (e.g. "attacksComparison_Datasetresults/data (AUX)_AttackRaw.png"). With this commit we set prepend output_path to filename, create any missing parents, and save to filename.

Sorry for the late reply -- thanks for the fix!


Fixed adding-writepermission-iisfolder.config and aws-inspector-install.config files

Issue #, if available:
The Amazon Inspector Agent installation command was hanging due to missing /quite switch.
Also, added more checks before granting permission in adding-writepermission-iisfolder.config. .
Description of changes:
Fixed Amazon Inspector Agent installation command, removed symbols and added more conditions before granting permission in adding-writepermission-iisfolder.config.

I'm working with @jitsinj to create a new PR w/o merge conflicts.


EIP-7251 Add missed exit checks to consolidation processing

PR Description
As per https://github.com/ethereum/consensus-specs/pull/4000
Fixed Issue(s)
fixes #8801
Documentation

[X] I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

[X] I thought about adding a changelog entry, and added one if I deemed necessary.

I have a PR with all fixes for alpha.9. I have incorporated these changes there: https://github.com/Consensys/teku/pull/8882


Adding event context to EventLog service provider

Package targeted
Winter CMS
Description
The MessageLogged event listener in the ServiceProvider class excludes the event context instead of placing it in the details column (by passing it in as the details argument to EventLog::add).  I have dynamically overridden this event locally for a while now with no ill effects and the stock output renders quite nicely as-is.  I would like to submit a pull request to make this change upstream.
Additionally, a recent change added a type declaration to the EventLog::add function for the details parameter.  The type declaration was set to ?string when the function assumes and even explicitly casts it to an array.  The model has the details attribute set to JSONable, so I believe this type declaration is incorrect and causes needless double-encoding to JSON when using this function.  I believe the type declaration should have been ?array instead.
Will this change be backwards-compatible?
I have had this event dynamically overridden in a custom plugin since version 1.0.x with no negative consequences, so it should be backward compatible.

Here's a preview of the intended change
diff --git a/modules/system/ServiceProvider.php b/modules/system/ServiceProvider.php
index 3dfd76c7a..771971f18 100644
--- a/modules/system/ServiceProvider.php
+++ b/modules/system/ServiceProvider.php
@@ -315,7 +315,8 @@ protected function registerLogging()
     {
         Event::listen(\Illuminate\Log\Events\MessageLogged::class, function ($event) {
             if (EventLog::useLogging()) {
-                EventLog::add($event->message, $event->level);
+                $details = $event->context ?? null;
+                EventLog::add($event->message, $event->level, $details);
             }
         });
     }
diff --git a/modules/system/models/EventLog.php b/modules/system/models/EventLog.php
index f72c4f459..2d2efc358 100644
--- a/modules/system/models/EventLog.php
+++ b/modules/system/models/EventLog.php
@@ -40,7 +40,7 @@ class_exists('Model') &&
     /**
      * Creates a log record
      */
-    public static function add(string $message, string $level = 'info', ?string $details = null): self
+    public static function add(string $message, string $level = 'info', ?array $details = null): self
     {
         $record = new static;
         $record->message = $message;

@interworks-morr sounds good, submit the PR please!


[WIP] Run rank tests in CI

Suggestions of next steps for @harrisonpim:

Pull the Docker commands out into a shell script which gets run by Buildkite
Fetch the secrets for yarn test from Secrets Manager in the script
Pass those secrets as env vars to the Docker command


About the .ply file

Hello sir, I wonder how can I use the mvsgs to optimize the .ply file processed by other modeI. I met the error:
(mvsgs) $ python lib/train.py  --eval --iterations 3000 -s dataset/mvdif_demo_150_20i -p mvsgs_pointcloud/dtu_pretrain Optimizing ./output/mvdif_demo_150_20i Output folder: ./output/mvdif_demo_150_20i Tensorboard not available: not logging progress Reading camera 20/20 mvsgs_pointcloud/dtu_pretrain/mvdif_demo_150_20i/mvdif_demo_150_20i.ply Loading Training Cameras [ INFO ] Encountered quite large input images (>1.6K pixels width), rescaling to 1.6K.  If this is not desired, please explicitly specify '--resolution/-r' as 1 Loading Test Cameras Traceback (most recent call last):   File "lib/train.py", line 236, in <module>     training(lp.extract(args), op.extract(args), pp.extract(args), args.test_iterations, args.save_iterations, args.checkpoint_iterations, args.start_checkpoint, args.debug_from, init_ply=args.init_ply)   File "lib/train.py", line 67, in training     scene = Scene(dataset, gaussians, init_ply=init_ply)   File "/home/sunzhenyu/Projects/MVSGaussian/lib/scene/__init__.py", line 86, in __init__     self.gaussians.create_from_pcd(scene_info.point_cloud, self.cameras_extent)   File "/home/sunzhenyu/Projects/MVSGaussian/lib/scene/gaussian_model.py", line 129, in create_from_pcd     fused_point_cloud = torch.tensor(np.asarray(pcd.points)).float().cuda() AttributeError: 'NoneType' object has no attribute 'points'

I use other models to generate the point cloud from the same input dataset, and try to use it as initialization of gaussian optimization in mvsgs. However, the mistakes above happens. How can I fix the problem?

Sorry for the late reply.
We load the point cloud as initialization here. Please check it.

OK, sir. So you provide me the specific paragraph where I can change the loading directory. However, I found that if I change the point cloud file into the .ply file that I generated throuh other methods, the error
Traceback (most recent call last):   File "lib/train.py", line 236, in <module>     training(lp.extract(args), op.extract(args), pp.extract(args), args.test_iterations, args.save_iterations, args.checkpoint_iterations, args.start_checkpoint, args.debug_from, init_ply=args.init_ply)   File "lib/train.py", line 67, in training     scene = Scene(dataset, gaussians, init_ply=init_ply)   File "/home/sunzhenyu/Projects/MVSGaussian/lib/scene/__init__.py", line 86, in __init__     self.gaussians.create_from_pcd(scene_info.point_cloud, self.cameras_extent)   File "/home/sunzhenyu/Projects/MVSGaussian/lib/scene/gaussian_model.py", line 129, in create_from_pcd     fused_point_cloud = torch.tensor(np.asarray(pcd.points)).float().cuda() AttributeError: 'NoneType' object has no attribute 'points'
came up. It seems that there are some constraints while utilizing the .ply file as the initilization of gaussian optimization, and simply changin the original .ply file into another version does not work well.
Anticipating for your earliest reply!

I suspect the problem is caused by an incorrect path. Because AttributeError: 'NoneType' object has no attribute 'points'.
You can also set the path here.
And structured array of the point cloud can be found here.

Howerver, I simply put the new version of the .ply file into the place where the original version should be, and I change the name to avoid the directory error. However, the nonetype error still occuirs.

From your description, can I infer that: As long as the point cloud .ply file is obtained from the images of the four target views in the input dataset, and its path is correct, it can be optimized using the Gaussian optimization method of MVSGaussian. The point cloud does not necessarily have to be obtained from the previous run.py, right?


Giovannfox task3 class add

Okay, thank you!
Sent from my iPhone

On Jul 24, 2020, at 7:15 PM, iamamonte<EMAIL_ADDRESS>wrote:

@iamamonte commented on this pull request.
Please pull down the changes from upstream and adjust guitar.js. After which, try running the application in visual studio code. If all is well, submit a new PR.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Support  auto merge with /lgtm and /approved

/assign
/enhancement

/help-wanted
/good-first-issue

# OWNERS
reviewers:
  - reviewer
approvers:
  - approver
``


[V3] Extract Concepts from v2 exercise: high-scores

Extract the list of concepts required to solve the v2 Ruby exercise: high-scores. For each concept, describe why it is required to solve the exercise. Keep in mind that an exercise can have multiple approaches (you can find community solutions here: https://exercism.io/tracks/ruby/exercises/high-scores/solutions). The goal of this task is to help determine the total list of concepts that make up high-scores.
The list of concepts should be stored in the following document: languages/ruby/reference/exercise-concepts/high-scores.md. Use this link to create a PR to add this document.

I've done a bit of a deep dive on the various processes that different tracks have followed when developing their syllabus, and one of the things that I learned is that trying to come up with a full list of concepts up front was less successful than we had hoped it would be.
In general the most successful approach seemed to use a "just in time" strategy, working from the root of the concept tree, identifying a small handful of concepts that were not too far ahead in the tree, and then filling gaps where necessary.
I'm going to go ahead and close this issue. If someone wants to work on concept exercises, please open an issue and we can  help identify a good concept to tackle, as well as provide some guidance on how to proceed from there.


feat: support helm-chart way

Also fixed plugin delete function in #17
Signed-off-by: Ling Samuel<EMAIL_ADDRESS>

Codecov Report
Base: 2.78% // Head: 2.13% // Decreases project coverage by -0.64% :warning:

Coverage data is based on head (d96b479) compared to base (e149842).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff            @@
##            main     #21      +/-   ##
========================================
- Coverage   2.78%   2.13%   -0.65%
========================================
  Files          6       7       +1
  Lines        431     561     +130
========================================
  Hits          12      12
- Misses       418     548     +130
  Partials       1       1

Impacted Files
Coverage Δ

e2e/e2e.go
83.33% <ø> (ø)

e2e/framework/curl.go
0.00% <0.00%> (ø)

e2e/framework/framework.go
1.11% <0.00%> (-0.02%)
:arrow_down:

e2e/framework/httpbin.go
0.00% <0.00%> (ø)

e2e/framework/istio.go
0.00% <0.00%> (ø)

e2e/framework/k8s.go
0.00% <0.00%> (ø)

e2e/framework/nginx.go
0.00% <0.00%> (ø)

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.


Add Python 3.13 Docker image to Python egg

Description
This PR adds the Python 3.13 Docker image to the python generic egg.
Checklist for all submissions

[X] Have you followed the guidelines in our Contributing document?

[X] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

[X] Have you tested and reviewed your changes with confidence that everything works?

[X] Did you branch your changes and PR from that branch and not from your master branch?

If not, why?:

[X] You verify that the start command applied does not use a shell script

[X] If some script is needed then it is part of a current yolk or a PR to add one

[X] The egg was exported from the panel

Do we have a python 3.13 image?

https://github.com/pelican-eggs/yolks/blob/master/python/3.13


Removal of wagtail.contrib.wagtailapi needs upgrade note

As per https://github.com/wagtail/wagtail/pull/3925#issuecomment-340730987, creating as a new issue so it doesn't get forgotten...

@kaedroho Please can you add a note to the "Upgrade considerations" section of the 2.0 release notes, detailing what users need to do to restore access to API v1?

Completed in #4129


cmake: west version must be 0.7.1

West topdir 0.7.0 uses windows path style in Windows causing a failure
in CMake.
This is fixed in west, 0.7.1.
This fix ensures that west topdir is only used when
west version is >= 0.7.1.
See:
https://github.com/zephyrproject-rtos/west/pull/375
https://github.com/zephyrproject-rtos/west/pull/376
Signed-off-by: Torsten Rasmussen<EMAIL_ADDRESS>

Its a nit, but can you tweak the commit message.  As I read this it means zephyr needs west 0.7.1 to function, and I think its we need 0.7.1 to deal w/topdir

As I read this it means zephyr needs west 0.7.1 to function, and I think its we need 0.7.1 to deal w/topdir

I would suggest something like this:
This avoids an issue using Zephyr's "west build" command on Windows with west 0.7.0.

As I read this it means zephyr needs west 0.7.1 to function, and I think its we need 0.7.1 to deal w/topdir

I would suggest something like this:
This avoids an issue using Zephyr's "west build" command on Windows with west 0.7.0.

it will actually break even when running CMake directly.
So not tied to west build

Its a nit, but can you tweak the commit message. As I read this it means zephyr needs west 0.7.1 to function, and I think its we need 0.7.1 to deal w/topdir

Adjusted commit message.


Unify and improve database connection configs

Currently, there are too many indirections in the way spiral database configs can be written.
E.g here's what's being used for spiral's test configs:
'postgres'  => [
    'driver'     => Database\Driver\Postgres\PostgresDriver::class,
    'check'      => static function () {
        return !in_array('pgsql', \PDO::getAvailableDrivers(), true);
    },
    'conn'       => 'pgsql:host=<IP_ADDRESS>;port=15432;dbname=spiral',
    'user'       => 'postgres',
    'pass'       => 'postgres',
    'queryCache' => 100
],

And here's a latest(?) config example:
'postgres' => [
    'driver' => Spiral\Database\Driver\Postgres\PostgresDriver::class,
    'options' => [
        'connection' => 'pgsql:host=localhost;dbname=spiral',
        'username' => 'username',
        'password' => 'password',
        'options' => [
            PDO::ATTR_EMULATE_PREPARES => true,
            PDO::ATTR_STRINGIFY_FETCHES => true,
        ],
    ],
],

We could keep backward compatibility, but improve configs and update all the examples, docs, tests. I would like to suggest the following improvements:

Drop the first nested options key and write connection properties in the root config
Use dsn instead of  connection/conn
Add host, port, and dbname configs. (but ignore them if dsn is set explicitly - I believe that's how it's done everywhere else)
Use dotenv in examples to allow for easier adoption

Following these suggestions, a config would look like:
'postgres' => [
    'driver' => Spiral\Database\Driver\Postgres\PostgresDriver::class,
    'host' => env('DB_HOST'),
    'port' => env('DB_PORT'),
    'dbname' => env('DB_DATABASE'),
    'username' => env('DB_USERNAME'),
    'password' => env('DB_PASSWORD'),
    'options' => [
        PDO::ATTR_EMULATE_PREPARES => true,
        PDO::ATTR_STRINGIFY_FETCHES => true,
    ],
],

Not so coincidentally, this looks almost exactly like Laravel config.
I could take a crack at this once we agree on the format.

Thank you for the advice. Examples in the documentation do not work. There is no word about the fact that the entire connection (username, password, connection) block must also be wrapped in options. As a result, I received the 'invalid data source name' error.

It does not need to be wrapped in options. Can you provide me an example which does not work for you?
@rauanmayemir if we can backward compatibility to classic DSN declaration I'm all for it in 2.*.

The options were actually an older format. Where did you found it?

I'm new to Spiral so first I created a new project composer create-project spiral/app - all packages should be in latest version.
database.php that works:
<?php

declare(strict_types = 1);

use Spiral\Database\Driver\Postgres\PostgresDriver;

return [
    'default' => 'primary',
    'databases' => [
        'primary' => [
            'driver' => 'postgres',
        ],
    ],
    'drivers' => [
        'postgres' => [
            'driver' => PostgresDriver::class,
            'options' => [
                'connection' => 'pgsql:host=localhost;port=5432;dbname=' . env('DB_NAME'),
                'username' => env('DB_USERNAME'),
                'password' => env('DB_PASSWORD'),
                'options' => [],
                'profiling' => true,
            ],
        ],
    ],
];

Inside HomeController@index:
dump($this->db->getDriver());
Spiral\Database\Driver\Postgres\PostgresDriver object
(
·    addr = string(42) pgsql:host=localhost;port=5432;dbname=test
·    source = string(4) test
·    connected = boolean(1) true
·    options = array(3)
·    [
·    ·    [8] = integer(1) 0
·    ·    [3] = integer(1) 2
·    ·    [20] = boolean(0) false
·    ]
)

According to docs this should work:
return [
    'default' => 'primary',
    'databases' => [
        'primary' => [
            'driver' => 'postgres',
        ],
    ],
    'drivers' => [
        'postgres' => [
            'driver' => PostgresDriver::class,
            'connection' => 'pgsql:host=localhost;port=5432;dbname=' . env('DB_NAME'),
            'username' => env('DB_USERNAME'),
            'password' => env('DB_PASSWORD'),
            'options' => [],
            'profiling' => true,
        ],
    ],
];

but:
Spiral\Database\Driver\Postgres\PostgresDriver object
(
·    addr = string(0)
·    source = string(1) *
·    connected = boolean(0) false
·    options = array(3)
·    [
·    ·    [8] = integer(1) 0
·    ·    [3] = integer(1) 2
·    ·    [20] = boolean(0) false
·    ]
)

DSN/user/pass is empty. dump($this->db->select('*')->from('sample_table')->fetchAll());:
Spiral\Database\Exception\StatementException: invalid data source name in D:\Server\spiral\vendor\spiral\database\src\Driver\Postgres\PostgresDriver.php at line 141 • caused by PDOException: invalid data source name in D:\Server\spiral\vendor\spiral\database\src\Driver\Driver.php at line 664
php app.php db:list
+------------+-----------+----------+---------+--------------------------+---------+----------------+
| Name (ID): | Database: | Driver:  | Prefix: | Status:                  | Tables: | Count Records: |
+------------+-----------+----------+---------+--------------------------+---------+----------------+
| primary    | *         | Postgres | ---     | invalid data source name | ---     | ---            |
+------------+-----------+----------+---------+--------------------------+---------+----------------+

With extra options key:
php app.php db:list
+------------+-----------+----------+---------+-----------+--------------+----------------+
| Name (ID): | Database: | Driver:  | Prefix: | Status:   | Tables:      | Count Records: |
+------------+-----------+----------+---------+-----------+--------------+----------------+
| primary    | test      | Postgres | ---     | connected | sample_table | 1              |
|            |           |          |         |           | migrations   | 1              |
+------------+-----------+----------+---------+-----------+--------------+----------------+

I also tried public function index(Database $primary): string with no luck.

Unwrapped parameters can not be combined with options.
The old unwrapped form works:
'mysql' => [
    'driver'     => Driver\MySQL\MySQLDriver::class,
    'options' => [
        'connection' => sprintf('mysql:host=%s;dbname=%s', env('DB_HOST'), env('DB_NAME')),
        'username'   => env('DB_USER'),
        'password'   => env('DB_PASSWORD'),
    ]
]

The unwrapped form works, too:
'mysql' => [
    'driver'     => Driver\MySQL\MySQLDriver::class,
    'connection' => sprintf('mysql:host=%s;dbname=%s', env('DB_HOST'), env('DB_NAME')),
    'username'   => env('DB_USER'),
    'password'   => env('DB_PASSWORD'),
]

But you can not add options to the second form, no matter the options array is empty or not:
'mysql' => [
    'driver'     => Driver\MySQL\MySQLDriver::class,
    'connection' => sprintf('mysql:host=%s;dbname=%s', env('DB_HOST'), env('DB_NAME')),
    'username'   => env('DB_USER'),
    'password'   => env('DB_PASSWORD'),
    'options' => [], // this cause "invalid data source name"
]

'mysql' => [
    'driver'     => Driver\MySQL\MySQLDriver::class,
    'connection' => sprintf('mysql:host=%s;dbname=%s', env('DB_HOST'), env('DB_NAME')),
    'username'   => env('DB_USER'),
    'password'   => env('DB_PASSWORD'),
    // this cause "invalid data source name"
    'options' => [
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    ]
]

I think it was resolved in https://github.com/cycle/database/pull/14


Missing podspec React dependency

Fixes CocoaPods: +1.5.0 build

@KacperKozak cheers for this. can you explain this PR in more detail? Is it backwards compatible with previous versions of React?

@joeferraro I'm not an iOS developer, but it's probably a mistake and somehow was working (until now). And yes, it's backwards compatible.
Other podspec examples:
https://github.com/react-native-community/react-native-camera/blob/master/react-native-camera.podspec
https://github.com/oblador/react-native-keychain/blob/master/RNKeychain.podspec
https://github.com/crazycodeboy/react-native-splash-screen/blob/master/react-native-splash-screen.podspec

I've open this too for the same reason: https://github.com/joeferraro/react-native-cookies/pull/94
Yes, it's compatible with previous version 👍


Check error handling for Text to Speech

This question on dW Answers suggests that the error response may not always conform to the documentation. Let's check the error response that we would receive and whether it is sufficiently propagated to the user.
(For this particular edge case, it's possible that a decoding error thrown by Freddy that contains the full text of the error message may be sufficient...)

Please be noticed that I reopened the question

Thanks @mihui for letting us know! This PR addresses the new changes to error handling in Text to Speech and will be included in the next release of the SDK.

Great! @schen22 I updated the old repository too.


spack error building<EMAIL_ADDRESS>

Firstly rocprofiler-dev's package.py does not contain any releases past 5.4.3, and so this should be updated with latest builds. In order to get un-stuck, I added the verison in myself with the following patch:

git patch
diff --git a/var/spack/repos/builtin/packages/rocprofiler-dev/package.py b/var/spack/repos/builtin/packages/rocprofiler-dev/package.py
index 7da0ef96de..f8e1266b01 100644
--- a/var/spack/repos/builtin/packages/rocprofiler-dev/package.py
+++ b/var/spack/repos/builtin/packages/rocprofiler-dev/package.py
@@ -18,6 +18,7 @@ class RocprofilerDev(CMakePackage):

     maintainers("srekolam", "renjithravindrankannath")
     libraries = ["librocprofiler64"]
+    version("5.6.1", sha256="b952b80338a5374800784e9db8e34bad6daa5f49")
     version("5.4.3", sha256="86c3f43ee6cb9808796a21409c853cc8fd496578b9eef4de67ca77830229cac1")
     version("5.4.0", sha256="0322cbe5d1d3182e616f472da31f0707ad6040833c38c28f2b39381a85210f43")
     version("5.3.3", sha256="07ee28f3420a07fc9d45910e78ad7961b388109cfc0e74cfdf2666789e6af171")
@@ -123,6 +124,7 @@ class RocprofilerDev(CMakePackage):
         "5.3.3",
         "5.4.0",
         "5.4.3",
+        "5.6.1"
     ]:
         depends_on("hsakmt-roct@" + ver, when="@" + ver)
         depends_on("hsa-rocr-dev@" + ver, when="@" + ver)

Using the following spack.yaml, I then get the following build error:

spack.yaml
spack:
  specs:
  -<EMAIL_ADDRESS>amdgpu_target=gfx908
    ^ llvm-amdgpu%gcc
    ^ hsa-rocr-dev~image
  view: false
  concretizer:
    reuse: false
  compilers:
  - compiler:
      spec<EMAIL_ADDRESS>      paths:
        cc: /share/apps/gcc/8.4.0/bin/gcc
        cxx: /share/apps/gcc/8.4.0/bin/g++
        f77: /share/apps/gcc/8.4.0/bin/gfortran
        fc: /share/apps/gcc/8.4.0/bin/gfortran
      operating_system: centos7
      target: x86_64
      modules: [gcc/8.4.0]
  - compiler:
      spec<EMAIL_ADDRESS>      paths:
        cc: amdclang
        cxx: amdclang++
        f77: /share/apps/gcc/8.4.0/bin/gfortran
        fc: /share/apps/gcc/8.4.0/bin/gfortran
      flags:
        cxxflags: --gcc-toolchain=/share/apps/gcc/8.4.0
      operating_system: centos7
      target: x86_64
      modules: []
  config:
    concretizer: clingo
    install_tree:
      root: $SPACK_INSTALL
    source_cache: $SPACK_CACHE/source
    misc_cache: $SPACK_CACHE/misc
    build_stage: $SPACK_CACHE/build
    url_fetch_method: curl
  modules:
    default:
      roots:
        tcl: $SPACK_INSTALL/modules
  packages:
    all:
      permissions:
        write: group
        read: world
        group: exasgd
    mesa:
      externals:
      - spec<EMAIL_ADDRESS>        prefix: /usr
      buildable: false
    curl:
      externals:
      - spec<EMAIL_ADDRESS>        prefix: /usr/bin/curl
      buildable: false
    git:
      externals:
      - spec<EMAIL_ADDRESS>        prefix: /share/apps/git/2.42.0
        modules:
        - git/2.42.0
      buildable: false
    lua:
      externals:
      - spec<EMAIL_ADDRESS>        modules:
        - lua/5.4.2
      buildable: false
    python:
      externals:
      - spec<EMAIL_ADDRESS>        modules:
        - python/miniconda4.12
      buildable: false
    perl:
      externals:
      - spec<EMAIL_ADDRESS>        modules:
        - perl/5.26.0
      buildable: false

Spack Build Error
==> Concretized<EMAIL_ADDRESS>amdgpu_target=gfx908 ^hsa-rocr-dev~image ^llvm-amdgpu%gcc
 -   zxpp5lt  resolve<EMAIL_ADDRESS>cxxflags="--gcc-toolchain=/share/apps/gcc/8.4.0" ~cuda~ipo+klu+rocm amdgpu_target=gfx908 build_system=cmake build_type=Release dev_path=/people/ruth521/projects/resolve generator=make arch=linux-centos7-zen
[+]  rmou7zf      ^cmake<EMAIL_ADDRESS>build_system=generic build_type=Release arch=linux-centos7-zen
[e]  3emq5yx          ^curl<EMAIL_ADDRESS>build_system=autotools libs=shared,static tls=openssl arch=linux-centos7-zen
[+]  gwo76of          ^ncurses<EMAIL_ADDRESS>abi=none build_system=autotools arch=linux-centos7-zen
[+]  feah6zt          ^zlib-ng<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  6c7b35p      ^gmake<EMAIL_ADDRESS>cxxflags="--gcc-toolchain=/share/apps/gcc/8.4.0" ~guile build_system=generic arch=linux-centos7-zen
[+]  zpa2j7f      ^hip<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make patches=aee7249,c2ee21c,e73e91b arch=linux-centos7-zen
[+]  yl7z2re          ^comgr<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  vh5g6sx          ^glx<EMAIL_ADDRESS>build_system=bundle arch=linux-centos7-zen
[e]  xffioaq              ^mesa<EMAIL_ADDRESS>build_system=meson buildtype=release default_library=shared arch=linux-centos7-zen
[+]  l7nyr34          ^gmake<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  e3jea5v          ^hipify-clang<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make patches=54b8b39 arch=linux-centos7-zen
[+]  4on3xib          ^hsakmt-roct<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  6h77lxh              ^libdrm<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  sh2c4la                  ^libpciaccess<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  64inrmm                      ^util-macros<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  kcav646                  ^libpthread-stubs<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  vcdwjmb                  ^meson<EMAIL_ADDRESS>build_system=python_pip patches=0f0b1bd,ae59765 arch=linux-centos7-zen
[+]  7mpcwqq          ^numactl<EMAIL_ADDRESS>build_system=autotools patches=4e1d78c,62fc8a8,ff37630 arch=linux-centos7-zen
[+]  dcrbb7h              ^autoconf<EMAIL_ADDRESS>build_system=autotools patches=35c4492,7793209,a49dd5b arch=linux-centos7-zen
[+]  tvi3cks              ^automake<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  2bmpsy4              ^libtool<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[e]  6tdzqfd          ^perl<EMAIL_ADDRESS>build_system=generic patches=0eac10e,8cf4302 arch=linux-centos7-zen
[+]  nix64yx          ^perl-file-which<EMAIL_ADDRESS>build_system=perl arch=linux-centos7-zen
[+]  biqataj          ^perl-uri-encode<EMAIL_ADDRESS>build_system=perl arch=linux-centos7-zen
[+]  ayed35p              ^perl-module-build<EMAIL_ADDRESS>build_system=perl arch=linux-centos7-zen
[+]  nw7554i          ^py-cppheaderparser<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  creftnl              ^py-ply<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  ihu4sfq              ^py-setuptools<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  llv2yv4          ^rocm-core<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  5shaxxj          ^rocminfo<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  tdlpv7w      ^hsa-rocr-dev<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make patches=9267179 arch=linux-centos7-zen
[+]  23kjwto          ^elfutils<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  on73m5o              ^bzip2<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  m33ujza              ^gettext<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  6mgqxiy                  ^libxml2<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  atzwdgy                  ^tar<EMAIL_ADDRESS>build_system=autotools zip=pigz arch=linux-centos7-zen
[+]  btbzuey                      ^pigz<EMAIL_ADDRESS>build_system=makefile arch=linux-centos7-zen
[+]  o2hwfiz              ^libiconv<EMAIL_ADDRESS>build_system=autotools libs=shared,static arch=linux-centos7-zen
[+]  v5kymdq              ^xz<EMAIL_ADDRESS>build_system=autotools libs=shared,static arch=linux-centos7-zen
[+]  3ets7dy              ^zstd<EMAIL_ADDRESS>build_system=makefile compression=none libs=shared,static arch=linux-centos7-zen
[+]  733ltud          ^pkgconf<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  vy3wrnq      ^llvm-amdgpu<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=ninja patches=a08bbe1,b66529f,d35aec9 arch=linux-centos7-zen
[+]  ofxvwff          ^ninja<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  zmj4cst              ^re2c<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[e]  ob2n5zs          ^python<EMAIL_ADDRESS>build_system=generic patches=0d98e93,4c24573,ebdca64,f2fd060 arch=linux-centos7-zen
[+]  363odap          ^z3<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  arsno2b      ^rocblas<EMAIL_ADDRESS>amdgpu_target=auto build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  buxbznu          ^msgpack-c<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  gyn6his          ^procps<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  ukcd432          ^py-joblib<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  2xh5udm          ^py-msgpack<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  5f4zyzb              ^py-cython<EMAIL_ADDRESS>build_system=python_pip patches=c4369ad arch=linux-centos7-zen
[+]  yajovh7          ^py-pip<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  4mdsdw2          ^py-pyyaml<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  hidc7bw              ^libyaml<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  h4mzkzl          ^py-virtualenv<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  f25ay4b              ^py-distlib<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  rzqmlrq              ^py-filelock<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  hc6rq3a              ^py-hatch-vcs<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  hqzn5lb                  ^py-setuptools-scm<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[e]  k5crf2q                      ^git<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  ovqdpbs                      ^py-typing-extensions<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  bjpjiiq              ^py-hatchling<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  hrmamrk                  ^py-editables<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  7krugqt                  ^py-packaging<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  q3yng6k                      ^py-flit-core<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  vm5freh                  ^py-pathspec<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  lqpf66l                  ^py-pluggy<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  m4gh2nb                  ^py-tomli<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  iy66qnh                  ^py-trove-classifiers<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  pm6rj2c                      ^py-calver<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  6hnyp7h              ^py-platformdirs<EMAIL_ADDRESS>build_system=python_pip arch=linux-centos7-zen
[+]  dkkw2va          ^py-wheel<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  klwq5kk          ^rocm-cmake<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
 -   xszglxe      ^rocprofiler-dev<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make patches=16754a1,c482eee arch=linux-centos7-zen
[+]  wlgpkqj      ^rocsolver<EMAIL_ADDRESS>amdgpu_target=auto build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  4d5ehr5          ^fmt<EMAIL_ADDRESS>build_system=cmake build_type=Release cxxstd=11 generator=make arch=linux-centos7-zen
[+]  wtmfgyn      ^rocsparse<EMAIL_ADDRESS>amdgpu_target=auto build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  nu465tt          ^rocprim<EMAIL_ADDRESS>amdgpu_target=auto build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  lilld4h      ^roctracer-dev<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make arch=linux-centos7-zen
[+]  gbaoh25      ^roctracer-dev-api<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  cy34eno      ^suite-sparse<EMAIL_ADDRESS>build_system=generic arch=linux-centos7-zen
[+]  jbyetgm          ^gmp<EMAIL_ADDRESS>build_system=autotools libs=shared,static patches=69ad2e2 arch=linux-centos7-zen
[+]  bwzchwl          ^m4<EMAIL_ADDRESS>build_system=autotools patches=9dc5fbd,bfdffa7 arch=linux-centos7-zen
[+]  7ceszkk              ^diffutils<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  gzna4n3              ^libsigsegv<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  arxpx4m          ^metis<EMAIL_ADDRESS>build_system=cmake build_type=Release generator=make patches=4991da9,93a7903,b1225da arch=linux-centos7-zen
[+]  pf2mr55          ^mpfr<EMAIL_ADDRESS>build_system=autotools libs=shared,static arch=linux-centos7-zen
[+]  peuq4u2              ^autoconf-archive<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  eja2su5              ^texinfo<EMAIL_ADDRESS>build_system=autotools arch=linux-centos7-zen
[+]  lnpxyrn          ^openblas<EMAIL_ADDRESS>build_system=makefile symbol_suffix=none threads=none arch=linux-centos7-zen

[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/ncurses-6.4-gwo76ofckqwcdc2hbvehxv7o2zfa72c6
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/z3-4.11.2-363odapqokeirxyewemujbsyapimjny6
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/zlib-ng-2.1.4-feah6ztolctf7cjllcxrytkxvd7lccxk
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/llvm-amdgpu-5.6.1-vy3wrnqjafyyqecvn4azv2apududkipa
[+] /usr/bin/curl (external curl-7.29.0-3emq5yx6li2vgv2fvdvd7wuwvatjyexv)
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/ncurses-6.4-gwo76ofckqwcdc2hbvehxv7o2zfa72c6
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/zlib-ng-2.1.4-feah6ztolctf7cjllcxrytkxvd7lccxk
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/clang-16.0.0-rocm5.6.0/gmake-4.4.1-6c7b35p53uuzthzsbqevmphrxc5atdvi
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/z3-4.11.2-363odapqokeirxyewemujbsyapimjny6
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocm-core-5.6.1-llv2yv4t5pmtjxspqyulrelcpan6bdu4
[+] /usr (external mesa-23.0.2-xffioaq4lvpd6zoov2q2gxbqqef3j5gr)
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/bzip2-1.0.8-on73m5ogqhtx7byiganqwytgrc5ypxrr
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libiconv-1.17-o2hwfizgricmucq36jkmbwbubp2u2das
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/xz-5.4.1-v5kymdqlelldwarucdioohvviexfngdk
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/zstd-1.5.5-3ets7dyhqm45ecuj433zuiig23htxqpx
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/pkgconf-1.9.5-733ltudxfbqnejymtwzhletkh2p6ou2b
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libpthread-stubs-0.4-kcav646mcwr6jpcp5giyqi6lbulxavfg
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/numactl-2.0.14-7mpcwqquetegzbeqgovoph4gtv5obbqw
==><EMAIL_ADDRESS>: has external module in ['perl/5.26.0']
[+] /share/apps/perl/5.26.0 (external perl-5.26.0-6tdzqfdq3icaxhd6lq4ceotovqc2irsb)
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/roctracer-dev-api-5.6.1-gbaoh25k2t6edaxi6lax3nvfe26lua5l
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/msgpack-c-3.1.1-buxbznummp3vqzb7n5manqqljdvrlvet
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/gmake-4.4.1-l7nyr34qur4pjtwmh2cut6pcbgg2gxjr
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/cmake-3.27.7-rmou7zfs7n3om4siyztdn3v4pze6aqqc
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/glx-1.4-vh5g6sxqekieyyxocl2dkttjvn3dyhgb
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/perl-uri-encode-1.1.1-biqatajzjmtskeuz4np537222aesi47y
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/perl-file-which-1.27-nix64yxy7254fp63i2lw7vpl7abhubyu
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libxml2-2.10.3-6mgqxiynviu2u543n2ekuggnhgpyjkqe
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/gmp-6.2.1-jbyetgm3vxl6p6hqz5gh33e75cpipcc6
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/openblas-0.3.24-lnpxyrn3xagxbod7f5tkmgmr3ewzktwa
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libpciaccess-0.17-sh2c4la2cn37jgki2jhg3b5jvt3v4ir3
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/pigz-2.7-btbzueyotdgi4dxrkt6l4cdza44byrjl
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/llvm-amdgpu-5.6.1-vy3wrnqjafyyqecvn4azv2apududkipa
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/metis-5.1.0-arxpx4m2wqduoudgoox7n4u4foizqohl
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/mpfr-4.2.0-pf2mr55rf4aujfkhrgsklxbncimzzoyt
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libdrm-2.4.115-6h77lxhxywgmkw24xloyofy7p6qb24oz
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/tar-1.34-atzwdgyhdlq55dpibtoc5sbfow2egrv2
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hipify-clang-5.6.1-e3jea5vgt2sdtilu6xzltczweoldzwo2
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/comgr-5.6.1-yl7z2relywqsqt6nmodvarwurttzo52u
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/suite-sparse-5.13.0-cy34eno3dhhi3tavrf7o4qlk6mc6itpg
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hsakmt-roct-5.6.1-4on3xibiyb7vw75lb3xo7e6tywat46v7
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/gettext-0.22.3-m33ujzasirinhqj762gb6hdagiqv3bv4
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/elfutils-0.189-23kjwto4xp2p3gqu3lglflssksaiqxeg
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hsa-rocr-dev-5.6.1-tdlpv7wn64243clk23iuwhsllrlmhlxx
[+] /qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocminfo-5.6.1-5shaxxj42pfc6vcbogzz6j4fnwir5yqy
==> Installing rocprofiler-dev-5.6.1-xszglxebo2fgd3jwzqbsdv7za63yeizg [41/48]
==> No binary for rocprofiler-dev-5.6.1-xszglxebo2fgd3jwzqbsdv7za63yeizg found: installing from source
==> Using cached archive: /qfs/projects/exasgd/resolve/ruth521/spack-cache/source/_source-cache/archive/b9/b952b80338a5374800784e9db8e34bad6daa5f49.tar.gz
==> Applied patch /qfs/people/ruth521/projects/resolve/buildsystem/spack/spack/var/spack/repos/builtin/packages/rocprofiler-dev/fix-includes.patch
==> Applied patch /qfs/people/ruth521/projects/resolve/buildsystem/spack/spack/var/spack/repos/builtin/packages/rocprofiler-dev/0001-Continue-build-in-absence-of-aql-profile-lib.patch
==> Ran patch() for rocprofiler-dev
==> rocprofiler-dev: Executing phase: 'cmake'
==> Error: ProcessError: Command exited with status 1:
    '/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/cmake-3.27.7-rmou7zfs7n3om4siyztdn3v4pze6aqqc/bin/cmake' '-G' 'Unix Makefiles' '-DCMAKE_INSTALL_PREFIX:STRING=/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocprofiler-dev-5.6.1-xszglxebo2fgd3jwzqbsdv7za63yeizg' '-DCMAKE_BUILD_TYPE:STRING=Release' '-DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=OFF' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON' '-DCMAKE_INSTALL_RPATH:STRING=/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocprofiler-dev-5.6.1-xszglxebo2fgd3jwzqbsdv7za63yeizg/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocprofiler-dev-5.6.1-xszglxebo2fgd3jwzqbsdv7za63yeizg/lib64;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hsa-rocr-dev-5.6.1-tdlpv7wn64243clk23iuwhsllrlmhlxx/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/elfutils-0.189-23kjwto4xp2p3gqu3lglflssksaiqxeg/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/bzip2-1.0.8-on73m5ogqhtx7byiganqwytgrc5ypxrr/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/gettext-0.22.3-m33ujzasirinhqj762gb
6hdagiqv3bv4/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libiconv-1.17-o2hwfizgricmucq36jkmbwbubp2u2das/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libxml2-2.10.3-6mgqxiynviu2u543n2ekuggnhgpyjkqe/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/xz-5.4.1-v5kymdqlelldwarucdioohvviexfngdk/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/zlib-ng-2.1.4-feah6ztolctf7cjllcxrytkxvd7lccxk/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/ncurses-6.4-gwo76ofckqwcdc2hbvehxv7o2zfa72c6/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/pkgconf-1.9.5-733ltudxfbqnejymtwzhletkh2p6ou2b/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/zstd-1.5.5-3ets7dyhqm45ecuj433zuiig23htxqpx/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libdrm-2.4.115-6h77lxhxywgmkw24xloyofy7p6qb24oz/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libpciaccess-0.17-sh2c4la2cn37jgki2jhg3b5jvt3v4ir3/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libpthread-stubs-0.4-kcav646mcwr6jpcp5giyqi6lbulxavfg/lib;
/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/numactl-2.0.14-7mpcwqquetegzbeqgovoph4gtv5obbqw/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/llvm-amdgpu-5.6.1-vy3wrnqjafyyqecvn4azv2apududkipa/lib;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hsakmt-roct-5.6.1-4on3xibiyb7vw75lb3xo7e6tywat46v7/lib64;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocm-core-5.6.1-llv2yv4t5pmtjxspqyulrelcpan6bdu4/lib64;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/z3-4.11.2-363odapqokeirxyewemujbsyapimjny6/lib64' '-DCMAKE_PREFIX_PATH:STRING=/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/roctracer-dev-api-5.6.1-gbaoh25k2t6edaxi6lax3nvfe26lua5l;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocminfo-5.6.1-5shaxxj42pfc6vcbogzz6j4fnwir5yqy;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hsa-rocr-dev-5.6.1-tdlpv7wn64243clk23iuwhsllrlmhlxx;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/llvm-amdgpu-5.6.1-vy3wrnqjafyyqecvn4azv2apududkipa;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/z3-4.11.2-363odapqokeirxy
ewemujbsyapimjny6;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hsakmt-roct-5.6.1-4on3xibiyb7vw75lb3xo7e6tywat46v7;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/rocm-core-5.6.1-llv2yv4t5pmtjxspqyulrelcpan6bdu4;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/numactl-2.0.14-7mpcwqquetegzbeqgovoph4gtv5obbqw;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libdrm-2.4.115-6h77lxhxywgmkw24xloyofy7p6qb24oz;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libpthread-stubs-0.4-kcav646mcwr6jpcp5giyqi6lbulxavfg;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libpciaccess-0.17-sh2c4la2cn37jgki2jhg3b5jvt3v4ir3;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/elfutils-0.189-23kjwto4xp2p3gqu3lglflssksaiqxeg;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/gettext-0.22.3-m33ujzasirinhqj762gb6hdagiqv3bv4;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/tar-1.34-atzwdgyhdlq55dpibtoc5sbfow2egrv2;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/zstd-1.5.5-3ets7dyhqm45ecuj433zuiig23htxqpx;/qfs/projects/exasgd/resolve/
spack-ci/install/linux-centos7-zen/gcc-8.4.0/libxml2-2.10.3-6mgqxiynviu2u543n2ekuggnhgpyjkqe;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/xz-5.4.1-v5kymdqlelldwarucdioohvviexfngdk;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/bzip2-1.0.8-on73m5ogqhtx7byiganqwytgrc5ypxrr;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/libiconv-1.17-o2hwfizgricmucq36jkmbwbubp2u2das;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/cmake-3.27.7-rmou7zfs7n3om4siyztdn3v4pze6aqqc;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/zlib-ng-2.1.4-feah6ztolctf7cjllcxrytkxvd7lccxk;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/ncurses-6.4-gwo76ofckqwcdc2hbvehxv7o2zfa72c6;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/pkgconf-1.9.5-733ltudxfbqnejymtwzhletkh2p6ou2b;/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/gmake-4.4.1-l7nyr34qur4pjtwmh2cut6pcbgg2gxjr' '-DPROF_API_HEADER_PATH:STRING=/qfs/projects/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/roctracer-dev-api-5.6.1-gbaoh25k2t6edaxi6lax3nvfe26lua5l/roctracer/include/ext' '-DROCM_ROOT_DIR:STRING=/qfs/projec
ts/exasgd/resolve/spack-ci/install/linux-centos7-zen/gcc-8.4.0/hsakmt-roct-5.6.1-4on3xibiyb7vw75lb3xo7e6tywat46v7/include' '/qfs/projects/exasgd/resolve/ruth521/spack-cache/build/spack-stage-rocprofiler-dev-5.6.1-xszglxebo2fgd3jwzqbsdv7za63yeizg/spack-src'

1 error found in build log:
     41    -- hip::amdhip64 is SHARED_LIBRARY
     42    -- Profiling API: /qfs/projects/exasgd/resolve/spack-ci/install/linu
           x-centos7-zen/gcc-8.4.0/roctracer-dev-api-5.6.1-gbaoh25k2t6edaxi6lax
           3nvfe26lua5l/roctracer/include/ext/prof_protocol.h
     43    -- Found Python3: /share/apps/python/miniconda4.12/bin/python3.9 (fo
           und version "3.9.12") found components: Interpreter
     44    Traceback (most recent call last):
     45      File "<string>", line 1, in <module>
     46    ModuleNotFoundError: No module named 'lxml'
  >> 47    CMake Error at src/api/CMakeLists.txt:11 (message):
     48      The "lxml" Python3 package is not installed.  Please install it us
           ing the
     49      following command: "/share/apps/python/miniconda4.12/bin/python3.9
            -m pip
     50      install lxml".
     51
     52
     53    -- Configuring incomplete, errors occurred!

See build log for details:
  /qfs/projects/exasgd/resolve/ruth521/spack-cache/build/spack-stage-rocprofiler-dev-5.6.1-xszglxebo2fgd3jwzqbsdv7za63yeizg/spack-build-out.txt

Since I am using external python, feel free to close this as a non-issue, but I think this is a fixable bug in your package.py with a quick depends_on("py-xml") in the right place.

spack debug report
[ruth521@dmi spack]$ spack debug report
* **Spack:** 0.21.0.dev0 (86cd2a05389b886c9bd58b901e3359b7d8971f39)
* **Python:** 3.6.8
* **Platform:** linux-centos7-zen3
* **Concretizer:** clingo

@srekolam and @renjithravindrankannath you are the maintainers so perhaps you have some guidance
cc @PaulMullowney

Added https://github.com/spack/spack/pull/42459 . This is in review currently.


superscript is not handled correctly

After exporting to word I noticed that superscript are treated like subscript and I guess it is because of this line
https://github.com/curvenote/prosemirror-docx/blob/6975bd1c6edc5a80d07a9d6953c5a5818bd03ab7/src/schema.ts#L103

Quite right!
Fixed in 782d7d6267d2ed46977f873613f7adc3a427efa8


feat: adding release negative 3 e2e-tests and updating them to README

Description
We create 3 release manual e2e-tests that ensures behavior of release operator according to what is designed in case of missing required CRs ReleasePlan, ReleasePlanAdmission and ReleaseStrategy.
e2e-tests are added to README file with instructions  way to run.
##HACBS-2360
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[x] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/test redhat-appstudio-e2e

/test redhat-appstudio-e2e

/retest

/test redhat-appstudio-e2e

/retest

/retest

/test redhat-appstudio-e2e

/retest

/test redhat-appstudio-e2e

/test redhat-appstudio-e2e

/test redhat-appstudio-e2e


Feature: Press up key to start search with buffer.

It would be super helpful to just press up after typing part of a command and invoke this plugin.
Thanks

I need to look into this, but based on the following lines, I think it's supported already. Just not easily readable via docs.
https://github.com/joshskidmore/zsh-fzf-history-search/blob/ba342699cee38ad20471bf9a3c60587446479741/zsh-fzf-history-search.zsh#L5-L6

I apologize for my late response, but @jmuchovej is right. Currently, it's bound to Ctrl+r, but that key can be changed if needed (export ZSH_FZF_HISTORY_SEARCH_BIND).
To reiterate the behavior (which is hopefully what you're expecting):

When nothing is typed in the current terminal, Ctrl+r will bring forth all of your zsh history.
If you start typing typing a command, but cannot remember the arguments of the command (or want to reference a previous command), hitting Ctrl+r will list your history, but filter it based on what you've typed so far. So, for instance, if you type curl then hit Ctrl+r, your zsh history will be fuzzy filtered to anything with "curl" in the entry.

I would not recommend binding the up arrow though. I feel it will cause more issues within your terminal. Ctrl+r was chosen because it's pretty standardized for viewing terminal history in some sort of way for most interactive shells.

Ok. I'll try try up-arrow and see if anything breaks. Otherwise I'll just get myself used to it.
Thanks.