research: WDS font-family options, corresponding font-weight tokens

We need to evaluate whether we should provide font-family selection options and if yes which ones
We should switch from GFonts to self-hosting options, see #21427 and #20365
Font-weight tokens should be tailored to specific font-family options (extra points for accounting for light/dark mode and OS)

Please add your planning poker estimate with Zenhub @KelvinOm


Update docker images that build packages

High Level Overview of Change
Updated Dockerfiles used to package rippled.

Context of Change
Long overdue update of environment packaging uses.
Updated some dependencies.
Most importantly, rippled must be built a compiler supporting C++20.
rippled is building with GCC-11 now
Type of Change

[x] 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)
[x] Refactor (non-breaking change that only restructures code)
[ ] Tests (You added tests for code that already exists, or your new feature included in this PR)
[ ] Documentation Updates
[ ] Release

@legleux with Conan in, what do we still want to keep from this PR?

@legleux with Conan in, what do we still want to keep from this PR?

A good question. I'll have to go through the process and see what needs to be done.

@legleux any update on this?

@legleux any update on this?

I haven't looked too deeply yet but it looks like integrating these changes is going to be some work.


DO NOT MERGE - spring boot 3 support

Can we merge this at some point in a milestone?

@snicoll I'd like to do that once spans and metrics are working. There's still work to do in this branch. But, last I heard (2+ weeks ago) there wasn't an easy way to test this because there wasn't a Spring Boot 3.0 milestone with components instrumented with the micrometer tracing API.

I am also interested in this milestone to test things out before the final release.


docs: update repo name for links

I've updated the manifest.json file with a key that was recently added - moduleName.
This key is used to generate all the links to stuff like GitHub/StackOverflow/etc. Since your repo name has changed recently, I thought I'd save you some trouble and update it for you!

Thanks Dave! <3

Woo! Np!

@quartzmo Not sure when you guys plan to rename your repo, but just something to keep in mind!

@callmehiphop Thanks for explaining that, I added it to manifest.json, but I didn't know what it was for.


commando seems to disable windows updates for Windows 10 insider preview

Hi,
I installed commando vm on a copy of a Windows 10 Insider preview VM (build 18898). This copy doesn't update to the current Windows 10 Insider builds any longer although the original Windows 10 Insider VM does. Other Windows updates like Windows Defender seem to work.
Any ideas?

Unfortunately someone thought it was a great idea to knowlingly brick this feature (it's even documented in the source), reverting the registry keys and re-enabling the services should make it work again.
@fireeye please disable this 'feature' or at least make it optional, it prevents everyone from using WSL2 which means tools like nmap will not work in the current Kali subsystem

Please use this as a workaround if you run into this issue. We will not be enabling telemetry on the default install of Commando.


Add relabelling to generic write path

As with alerting, this goes after external labels are applied. Where should we put this in the config?

Probably it's own section for all related config. We probably also want to
have SD in there to discover write targets?
On Wed, Sep 7, 2016 at 11:27 AM Brian Brazil<EMAIL_ADDRESS>wrote:

As with alerting, this goes after external labels are applied. Where
should we put this in the config?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/issues/1955, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEuA8vzeiH2VqkoVBo6yjH1-Ln9g57yLks5qnoNsgaJpZM4J2tuE
.

Yeah, we'll probably ultimately want that. We're still on "target" right now :)

Yes, just another reason to have a new top-level section for remote as
there'll be more coming.
That might be best divided in read and write again.
On Wed, Sep 7, 2016 at 11:46 AM Brian Brazil<EMAIL_ADDRESS>wrote:

Yeah, we'll probably ultimately want that. We're still on "target" right
now :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/issues/1955#issuecomment-245230172,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEuA8oSFrP-EZdrslhY6S_Xbu9Kzy0C4ks5qnofhgaJpZM4J2tuE
.

I've have separate top-level write and read sections.

Will also want to include remote auth in the config, see #1957.


C-0001 - Forbidden Container Registries False Positive

Copied from here
Issue description
C-0001 control should not fail for k8s objects that use images from Docker Hub if in controls-inputs.json publicRegistries and untrustedRegistries fields are set to an empty array.
Steps to reproduce the issue

Create controls-inputs.json

{
  "imageRepositoryAllowList": [
    "*.dkr.ecr.*.amazonaws.com",
    "k8s.gcr.io",
    "quay.io",
    "docker.io"
  ],
  "publicRegistries": [],
  "untrustedRegistries": []
}

Deploy example nginx

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80

Run kubescape

kubescape scan --controls-config controls-inputs.json --verbose control "Forbidden Container Registries"

What's the expected result?
Running the following command should not report any issues
kubescape scan --controls-config controls-inputs.json --verbose control "Forbidden Container Registries"

What's the actual result?
################################################################################
ApiVersion: apps/v1
Kind: Deployment
Name: nginx-deployment
Namespace: default
Controls: 1 (Failed: 1, Excluded: 0)
+----------+--------------------------------+------------------------------------+----------------------------------------+
| SEVERITY |          CONTROL NAME          |                DOCS                |         ASSISTANT REMEDIATION          |
+----------+--------------------------------+------------------------------------+----------------------------------------+
| Medium   | Forbidden Container Registries | https://hub.armosec.io/docs/c-0001 | spec.template.spec.containers[0].image |
+----------+--------------------------------+------------------------------------+----------------------------------------+
Additional details
Kubescape version: v2.0.166
k3d version v5.4.3
k3s version v1.23.6-k3s1 (default)

Hi all,
After some trials , I have not been able to reproduce the bug.
Here’s the result I got using the “same” environment/config files:
Controls: 1 (Failed: 0, Excluded: 0, Skipped: 0)
Failed Resources by Severity: Critical — 0, High — 0, Medium — 0, Low — 0
+----------+--------------------------------+------------------+--------------------+---------------+--------------+
| SEVERITY |          CONTROL NAME          | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % RISK-SCORE |
+----------+--------------------------------+------------------+--------------------+---------------+--------------+
| High     | Forbidden Container Registries |        0         |         0          |       9       |      0%      |
+----------+--------------------------------+------------------+--------------------+---------------+--------------+
|          |        RESOURCE SUMMARY        |        0         |         0          |       9       |    0.00%     |
+----------+--------------------------------+------------------+--------------------+---------------+--------------+

No failure at all.
The kubescape version that I'm using is: v2.1.3


Why adding branch "add-ar-nar"?

AR + NAR is better？

This is just an experiment branch, we are trying different ways to decode.


Feat: Underline related errors in postconditions

Previously, a failing postcondition like x >= 3 was not underlined in red because it was not a "diagnostic"

With this PR, the failing postcondition x >= 3 is also underlined in red:

The weird indentation is here to visually compare the two underlines.
Light mode version:

Implementation notes:

I added a capability in the DafnyLanguageServer to hook on the published diagnostics
I created a class RelatedErrorView that uses this hook, looks into diagnostics that start with "A postcondition might not hold", and stores the ranges of the first related informations in a map from document to ranges.
This class then displays these ranges using the textDecoration: "underline wavy red 1px" decoration.
There is no delay between the display of diagnostics and related errors implemented in this PR.

UX notes:

I picked up manually the color of regular errors
I did not find how to make the squiggle look exactly the same, but I'm happy with the result
With https://github.com/dafny-lang/dafny/pull/1946, hovering this error will also provide a meaningful error message and statistics about the failing postcondition.
With https://github.com/dafny-lang/ide-vscode/pull/147, the scroll bar on the left will already display a red mark for the line containing the failing postcondition. It will be very important to merge this PR after #147 because otherwise the gutter will display an error in the line but the error won't be visible.

What's the reason we want to show red squiggles under the return statement? I was thinking we might let the failing ensures clause be the main locations of such verification diagnostics.
For a problem like the following, the return statement doesn't seem relevant:
method Foo(x: bool) returns (r: int) ensures x > 1 {
  if (x) {
    r := 2;
  } else {
    r := 0;
  }
  var bar := zap;
}

Wouldn't it be better to show the entire error trace in related locations?

For a problem like the following,

I don't understand this example; did you mean the following?
method Foo(x: bool) returns (r: int) ensures r > 1 {
  if (x) {
    r := 2;
  } else {
    r := 0;
  }
  var bar := "zap";
}

I think that's arguably a bug, since the following is equivalent but provides much better diagnostics:
method Foo(x: bool) returns (r: int) ensures r > 1 {
  if (x) {
    return 2;
  } else {
    return 0;
  }
  var bar := "zap";
}

Btw, this is one case in which the trace is useful (albeit hard to read) on the command line, right?
Execution trace:
    (0,0): anon0
    (0,0): anon4_Else
    (0,0): anon3

For a problem like the following,

I don't understand this example; did you mean the following?
method Foo(x: bool) returns (r: int) ensures r > 1 {
  if (x) {
    r := 2;
  } else {
    r := 0;
  }
  var bar := "zap";
}

yes :) although the var bar := "zap" was meant to indicate some operation that should not be skipped in either of the if/then/else cases, so your equivalent program isn't really equivalent because it returns too early.

Is the reason for this PR because VSCode doesn't allow configuring showing red squiggles under related information? Have we tried cutting an issue to their repository?

No it's not just VSCode, it's a language server protocol problem: Diagnostics related informations only contain a message and a location, but no indication of whether they should be marked as errors. And it makes sense: You don't want to mark related locations as errors if they are on other functions for example. Errors visualized in the IDE should be only those in context.

What's the reason we want to show red squiggles under the return statement? I was thinking we might let the failing ensures clause be the main locations of such verification diagnostics.

I talked with the rest of the team today, and the consensus is that it does make sense to leave the main error here, because the ensures clause is asserted there even though it's not visible.
Perhaps it could make sense to put the error on the closing brace rather than the opening brace if applicable, but that would be another discussion.

For a problem like the following, the return statement doesn't seem relevant:
method Foo(x: bool) returns (r: int) ensures x > 1 {
  if (x) {
    r := 2;
  } else {
    r := 0;
  }
  var bar := zap;
}

Wouldn't it be better to show the entire error trace in related locations of the diagnostic?

That's an interesting suggestion. We would first need to prune the error trace because, as you can see, it's can be pretty messy. and in your case, I think it would make sense only if the main error is on the closing brace than the opening brace.
I suggest we keep this idea out of this scope, but that we keep this idea because I think it's promising. After all, a failed assertion's related ranges don't need to be failing sub-expressions, they can indeed display what is the path that was taken if it's not obvious.

Is the reason for this PR because VSCode doesn't allow configuring showing red squiggles under related information? Have we tried cutting an issue to their repository?

No it's not just VSCode, it's a language server protocol problem: Diagnostics related informations only contain a message and a location, but no indication of whether they should be marked as errors. And it makes sense: You don't want to mark related locations as errors if they are on other functions for example. Errors visualized in the IDE should be only those in context.

To me, how the IDE visualises the different information contained in a diagnostic is up to the IDE. What is the fundamental distinction between an error and related location? I thought error meant "look at this first" and related location meant "look at this second".

What's the reason we want to show red squiggles under the return statement? I was thinking we might let the failing ensures clause be the main locations of such verification diagnostics.

I talked with the rest of the team today, and the consensus is that it does make sense to leave the main error here, because the ensures clause is asserted there even though it's not visible.

Isn't saying that the ensures clause is asserted before the return statement just one way of interpreting it? Alternatively, you could interpret the return statement as jumping to the ensures clause before jumping to the calling function. If you do that, then you can show the main error on the ensures clause instead of on the "invisible assertion" on the return statement, which I think helps the user because then they don't have to find the ensures clause.
I think a good reason to show the error on the return statement is because it can also provide information about the error trace, but I don't feel that reason is good enough.


961 pairplot

What does this implement/fix? Explain your changes
Refactoring of the pairplot and marginal_plot functions, to make the plotting more transparent and easier to understand.
Here is a summary of all changes:
Passing keywords:

Figure kwargs are now passed in separate upper_kwargs,lower_kwargs, diag_kwargs and fig_kwargs dictionaries (similar to seaborn), making it easier to organise keywords
upper_kwargs,lower_kwargs, and diag_kwargs can include mpl_kwargs, which is directly passed to the matplotlib plotting function used, making it straightforward to change e.g. the cmap used.
backwards compatibility is ensured. If to-be-deprecated keywords are used, the previous version of plotting functions are called and a deprecation warning is thrown.

Tutorial:

A new tutorial is added that demonstrates some of the plotting options.

Restructuring of functions:

get_offdiag_funcs is declared outside of pairplot, bringing it inline with get_diac_funcs, and making pairplot easier to parse
all plotting functions, e.g., plt_hist_1d, plt_kde_2d, have their own function, making the code easier to parse, and making it easier to add new functions
arrange_plots is replaced by arrange_grid, which uses the newly defined plotting functions and avoids mixing plt and ax
styling the figure is done in a separate new function format_subplot
histograms can make use of the Freedman-Diaconis heuristic for selecting binsizes
diag can be None to only plot 2D marginals

Does this close any currently open issues?
Adresses #961
Any relevant code examples, logs, error output, etc?
See here for more examples

Any other comments?

I did not change any of the defaults, as I felt it is quite subjective what is desired, we could discuss whether defaults should be changed or not.

Once this is roughly approved conditional_pairplot and conditional_marginal_plot should be updated to be inline with the new functions.

Some tutorial plots should use updated syntax for plotting to avoid throwing deprecation warnings.

Checklist
Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask. We're here to
help! This is simply a reminder of what we are going to look for before merging
your code.

[x] I have read and understood the contribution
guidelines
[x] I agree with re-licensing my contribution from AGPLv3 to Apache-2.0.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added tests that prove my fix is effective or that my feature works
[ ] I have reported how long the new tests run and potentially marked them
with pytest.mark.slow.
[ ] New and existing unit tests pass locally with my changes
[x] I performed linting and formatting as described in the contribution
guidelines
[x] I rebased on main (or there are no conflicts with main)

high-level review: This is so great!!! Thanks a ton for improving the plotting 🎉
Before a detailed review,

can you please add type annotations to the arguments of the new functions,
and run pre-commit hooks. it seems the formatting is inconsistent. make sure you are using pre-commit --version 3.5.0. then run pre-commit run --all-files

thanks 🙏

Checks have now passed.
I will still update the tests, add typing for the non main functions, and update the conditional plots next week

@Matthijspals the pairplots really look better now!
Is there a reason why you avoided type hints for the return values?

@Matthijspals the pairplots really look better now!
Is there a reason why you avoided type hints for the return values?

Nope, I just didn't get to it yet, so feel free to have a go at it!

@famura Thanks a lot for your commits! Regarding the "warning-free testing of pairplot" I think we should update the tests, instead of (or in addition to?) adding  ignore::DeprecationWarning statements?

@Matthijspals the pairplots really look better now!
Is there a reason why you avoided type hints for the return values?

Nope, I just didn't get to it yet, so feel free to have a go at it!

I don't know if I'm ready for so much fun :)

@famura Thanks a lot for your commits! Regarding the "Warning-free testing of pairplot" I think we should update the tests, instead of (or in addition to?) adding ignore::DeprecationWarning statements?

I don't know what you mean by that since I understood you that we will nevertheless encounter these warnings until we delete the old plotting function and with that the conversion and warning. I think it is very safe to ignore our own warnings for specified tests.

@famura Thanks a lot for your commits! Regarding the "Warning-free testing of pairplot" I think we should update the tests, instead of (or in addition to?) adding ignore::DeprecationWarning statements?

I don't know what you mean by that since I understood you that we will nevertheless encounter these warnings until we delete the old plotting function and with that the conversion and warning. I think it is very safe to ignore our own warnings for specified tests.

Sorry for being unclear! What I meant is, we should a add a new test for the updated pairplot function (which shouldn't throw deprecation warnings if used correctly)

The new functions (and old functions used by them) now all have typing.
TODOs are:

update conditional plotting functions
update tests
update tutorials (some will now throw deprecation warnings)

Sorry for being unclear! What I meant is, we should a add a new test for the updated pairplot function (which shouldn't throw deprecation warnings if used correctly)

No worries, now I got you and agree. In a world with enough time, should do that. pytest also allows for marks that ignore things on a per-function-level. It didn't work instantly for me, so I went for this solution. Feel free to change it. However, I think that our time is better spent on other things :)

Ping @Matthijspals :)
I think this is almost done. It just needs the two changes about the kwargs and the renaming of x to theta in the tutorial.

Ping @Matthijspals :)
I think this is almost done. It just needs the two changes about the kwargs and the renaming of x to theta in the tutorial.

Hi Jan, sorry for the delay!
Do you mean to change:
def plt_name(
    ax: Axes,
    samples: np.ndarray,
    limits: torch.Tensor,
    kwargs: Dict,
) -> None:

into:
def plt_name(
    ax: Axes,
    samples: np.ndarray,
    diag_kwargs: Dict,
   **kwargs: Optional[Any]
) -> None:

or to make to limits part of the kwargs Dict?

No worries!

If the arguments are not used at all, which is the case for the limit args for those two functions I believe, then we just drop them. Otherwise it might be confusing, e.g., a user passes them to set limits but nothing changes.

If it is useful to pass them on to scatter, then we should add a **kwargs and pass that on. But as I understand it, option 1 makes more sense.

No worries!

If the arguments are not used at all, which is the case for the limit args for those two functions I believe, then we just drop them. Otherwise it might be confusing, e.g., a user passes them to set limits but nothing changes.
If it is useful to pass them on to scatter, then we should add a **kwargs and pass that on. But as I understand it, option 1 makes more sense.

Just dropping them won't work as the _arange_grid functions calls all plotting functions (e.g. plt_scatter_1d as  diag_f(ax, sample, limits, diag_kwargs)) - we would have to get rid of them for every function. In that case it is easiest to just add them to diag_kwargs, shall I do that?

Oh, I see. I finally understand why they were there in the first place :)
I am sorry for the back and forth then.
Then I suggest that we just keep them and add an inline comment or info in the docstring why they are there.
Another question I should have asked earlier: why are the limits not used in scatter or to plot, e.g., setting plt.xlim(limits...)?

Oh, I see. I finally understand why they were there in the first place :) I am sorry for the back and forth then.
Then I suggest that we just keep them and add an inline comment or info in the docstring why they are there.

Will do!

Another question I should have asked earlier: why are the limits not used in scatter or to plot, e.g., setting plt.xlim(limits...)?

The x and y limits are currently set for every plot in the _format_subplot function. Some of the plotting functions additionally need the limits, e.g., to set the extent of imshow.


Support new eslint suggestions API

Eslint has a new Suggestions API that was initially described in this RFC, and recently merged and released in eslint 6.7.0.
The suggestions API provides information for users to manually apply fixes for lint issues that don't have enough context to be auto-fixable. I think we'll want to have vscode-eslint support suggestions as a Quick Fix. Here is an example of how it would work:
new RegExp("*\.js", "u")
//           ^^
//           ├ Remove the `\`. This maintains the current functionality. (no-useless-escape)
//           └ Replace the `\` with `\\` to include the actual backslash character. (no-useless-escape)

I agree that adopting this in ESLint makes sense. However for auto fix on save there can't be an additional UI and for single error fixing we would simply provide both fixes as a code action.

This would be a good candidate for a PR.


semanage login - new mapping

Hi there,
Is it possible to create a new login mapping, similar to running the following command?
semanage login -a -s user_u newuser

I had a quick search through the cookbook and couldn't find a way of doing this. Apologies if its there and this is something I've missed.
Thanks!

Hi!
You're right, there is no such resource in this cookbook, yet.
I'll be happy to see a pull request from you / someone else adding this feature!

@csghuser if you want to implement your feature but missing guidance LMK and I'll be happy to help.

Closing due to inactivity.
If this is still an issue please reopen or open another issue. Alternatively drop by the #sous-chefs channel on the Chef Community Slack and we'll be happy to help!
Thanks,
Sous-Chefs


[FEATURE REQ] Use Exists() in CreateIfNotExists() implementation to optimize storage costs

Library name
Azure.Storage.Blobs
Please describe the feature.
With how storage calls are billed, read operations are much cheaper than write/create operations, so I think there's room for calls like CreateIfNotExists() to be optimized for cost by using Exists().
So instead of something like:
try
{
    response = await CreateInternal(...);
}
catch (RequestFailedException storageRequestFailedException)
when (storageRequestFailedException.ErrorCode == BlobErrorCode.ContainerAlreadyExists)
{
    response = default;
}

By simply adding an Exists call we can potentially use avoid a CreateContainer call:
if (await Exists(...))
{
   response = default;
   return;
}

try
{
   response = await CreateInternal(...);
}
catch (RequestFailedException storageRequestFailedException)
when (storageRequestFailedException.ErrorCode == BlobErrorCode.ContainerAlreadyExists)
{
   response = default;
}

Is this optimization reasonable or are there any flaws with this approach?

Thank you for reporting the issue. Tagging the team best able to assist you here.
/cc: @seanmcc-msft

Some issues with this approach

This would be a behavior breaking change. Customers who once expected only 1 Create request to go out, will now have to account to 2 requests going out (Get Properties, then Create)
There are customers who would argue that the current approach is preferred because another extra request, would be slower more prone to latency

I do see the optimization in billing, that a Get Properties request is cheaper however, a better alternative would just to be to call Exists then Create, that way it's clear that two requests are going out, on top of which requests are going out to better maintain billing.


Fixed issue with engine introducing duplicate child elements

Fixed issue with engine introducing duplicate child elements in field xml.

Hi @erwinvanhunen, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;


some preview contents questions.

I would like to show preview content in this space, but is it currently possible to implement this?

This is possible, I just haven't added the proper field to Result due to the way it is coded in Flow Launcher.
I'll add it today if I get a moment.

Added to v0.8.1:
https://github.com/Garulf/pyFlowLauncher/blob/e15b1b7f9c2f51447785e800c6dbc4b2f8e3351b/pyflowlauncher/result.py#L31-L36

@Garulf Thank you for adding it to the development list for me, I will change this issue to resolved if I can apply it as soon as possible. thank you

@Garulf Thank you for adding it to the development list for me, I will change this issue to resolved if I can apply it as soon as possible. thank you

No problem, it was on the todo list to implement, I just needed to familiarize myself with the data structure again.
You should be able to use it with the latest release.

Closing this issue. Let me know if this needs further discussion.


If a dataset is not in CREATE_COMPLETE status, disable S3 Upload functionality

Is your idea related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Currently (v.1.4.3), if a user creates a new dataset, and the dataset is not yet in the CREATE_COMPLETE status, the user can still click into the dataset, go to the "Upload" tab, and try to upload and crawl the data that is uploaded.  This will lead to errors and the table seems to never be correctly crawled.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Upload tab and/or the Upload functionality should be disabled or greyed-out to the user, if the dataset is not in the CREATE_COMPLETE state.  Once the dataset has reached status CREATE_COMPLETE, the Upload functionality can be re-enabled for the user.
P.S. Don't attach files. Please, prefer add code snippets directly in the message body.

Hi @rbernotas, thanks for raising the issue! We'll pick it up as soon as possible or we can work together in developing it.

dear @dlpzx  since could please consider pushing this as part of v1.6?

@noah-paige @dlpzx was this merged? can we close this then?

We have feature flags to enable / disable file upload altogether for a data.all deployment but if file upload actions are enabled we currently do not conditionally disable the upload feature until the dataset stack status is in a CREATE_COMPLETE or UPDATE_COMPLETE stage


Corrected broken links to non-existent pages in doco

doco updates only
There were two references to a missing page: docs/2-provision-azure-resources.md.
Presumably, the content of this page is now covered by the /README.md#deploy-to-azure section. I corrected the Next link on the Intro page to go straight to the Run locally page. On the Run locally page, I've pointed the link in Prerequisites back to the  /README.md#deploy-to-azure section.
Also, on Run locally , I corrected a recursive link to correctly point to the docs/5-add-identity.md page.

@microsoft-github-policy-service agree


update federation graphic

@jdries As I saw you updated this the other day. Should I remove CreoDias as "own" backend as it's more a different deployment location of your TerrasScope backend than it's own backend? Also are you okay with keeping the SH/EDC connection? Probably something I should also draw a arrow from our SH openEO backend to.

indeed, best to remove creodias for now, gives us time to figure out what it will become
keeping the connection is fine, I was first thinking of making it to the sentinelhub backend, but if we keep edc as separate entity it should surely point to that!

Thanks, I removed creodias and moved EODC to the most left position as I think it's the nicest distribution.
*Technically the Sentinel Hub backend is our Sentinel Hub openEO backend which connects via EDC to Sentinel Hub but I think that will cause more confusion and in this graphic we don't need to be 100% accurate as it's more about the idea and which backends are involved.


Blind attempt to fix warnings issued by gcc V9

Fixes #3643
@diehlpk Could you check whether this fixes the warnings you reported in #3643, please?

@msimberg FWIW, I added this to the 1.2.1 milestone. We should consider having it in the point release

@hkaiser It seems that the one I reported vanished, but there are more of these
make[2]: Leaving directory '/builddir/build/BUILD/hpx_1.2.1/serial'
BUILDSTDERR: /builddir/build/BUILD/hpx_1.2.1/src/runtime/agas/server/route.cpp: In member function 'void hpx::agas::server::primary_namespace::route(hpx::parcelset::parcel&&)':
BUILDSTDERR: /builddir/build/BUILD/hpx_1.2.1/src/runtime/agas/server/route.cpp:49:25: warning: implicitly-declared 'hpx::error_code::error_code(const hpx::error_code&)' is deprecated [-Wdeprecated-copy]
BUILDSTDERR:    49 |         error_code ec = throws;
BUILDSTDERR:       |                         ^~~~~~
BUILDSTDERR: In file included from /builddir/build/BUILD/hpx_1.2.1/hpx/lcos/future.hpp:11,
BUILDSTDERR:                  from /builddir/build/BUILD/hpx_1.2.1/hpx/runtime/agas/interface.hpp:15,
BUILDSTDERR:                  from /builddir/build/BUILD/hpx_1.2.1/hpx/runtime/applier/apply.hpp:12,
BUILDSTDERR:                  from /builddir/build/BUILD/hpx_1.2.1/src/runtime/agas/server/route.cpp:8:
BUILDSTDERR: /builddir/build/BUILD/hpx_1.2.1/hpx/error_code.hpp:222:32: note: because 'hpx::error_code' has user-provided 'hpx::error_code& hpx::error_code::operator=(const hpx::error_code&)'
BUILDSTDERR:   222 |         HPX_EXPORT error_code& operator=(error_code const& rhs);
BUILDSTDERR:

BUILDSTDERR: /builddir/build/BUILD/hpx_1.2.1/src/runtime/agas/server/primary_namespace_server.cpp: In member function 'hpx::naming::gid_type hpx::agas::server::primary_namespace::statistics_counter(const string&)':
BUILDSTDERR: /builddir/build/BUILD/hpx_1.2.1/src/runtime/agas/server/primary_namespace_server.cpp:1268:31: warning: implicitly-declared 'hpx::error_code::error_code(const hpx::error_code&)' is deprecated [-Wdeprecated-copy]
BUILDSTDERR:  1268 |     hpx::error_code ec = hpx::throws;
BUILDSTDERR:       |                               ^~~~~~
BUILDSTDERR: In file included from /builddir/build/BUILD/hpx_1.2.1/hpx/lcos/future.hpp:11,
BUILDSTDERR:                  from /builddir/build/BUILD/hpx_1.2.1/hpx/async_launch_policy_dispatch.hpp:11,
BUILDSTDERR:                  from /builddir/build/BUILD/hpx_1.2.1/hpx/async.hpp:10,
BUILDSTDERR:                  from /builddir/build/BUILD/hpx_1.2.1/src/runtime/agas/server/primary_namespace_server.cpp:11:
BUILDSTDERR: /builddir/build/BUILD/hpx_1.2.1/hpx/error_code.hpp:222:32: note: because 'hpx::error_code' has user-provided 'hpx::error_code& hpx::error_code::operator=(const hpx::error_code&)'
BUILDSTDERR:   222 |         HPX_EXPORT error_code& operator=(error_code const& rhs);
BUILDSTDERR:
```      |                                ^~~~~~~~

Fore more details https://kojipkgs.fedoraproject.org//work/tasks/2067/32522067/build.log

@diehlpk I fixed two more warnings. The attribute warnings should have been fixed by #3505, no idea why they still show up - @sithhell?

The attribute warnings were and are a mystery to me. Seems to be very much compiler and configuration dependent. Perhaps our defines are not doing what they should be doing. This is most worrying:
BUILDSTDERR: /builddir/build/BUILD/hpx_1.2.1/hpx/runtime/actions/basic_action.hpp:861:43: warning: type attributes ignored after type is already defined [-Wattributes]
BUILDSTDERR:   861 |         template struct HPX_ALWAYS_EXPORT transfer_action< action>;

Line 861 is within an #if defined(HPX_MSVC) || defined(HPX_MINGW) block, which should not be happening... I'll have a look.

@msimberg should we add that patch to V1.2.1?

@hkaiser yes, it's already on the release branch (although I forgot to push it before leaving work, it'll be there tomorrow).


Add the Jelly logo to Maven releases

We have a logo here: https://github.com/Jelly-RDF
We should find a way to add it to our Maven releases :3

OK, it turns out that the thing should just work automatically, and if it didn't, then it won't: https://stackoverflow.com/questions/30661826/icons-and-tags-on-mvnrepository-com
Oh well.
I will at least add package descriptions to what we publish on Maven.