warning Shade 30 colors

Platforms Impacted

[x] iOS
[ ] macOS

Description of changes

Update warning shade30 color from 8F761E to 816B1B based on design input to meet 4.5:1 contrast ratio on notificationview and badgeview of warning type.
for .warning MSFLabel, don't use warningPrimary color on light mode but use warningShade30.

Verification

Before
After

4.1 : 1 contrast
4.9: 1 contrast

Pull request checklist
This PR has considered:

[x] Light and Dark appearances
[x] VoiceOver and Keyboard Accessibility
[ ] Internationalization and Right to Left layouts
[ ] Different resolutions (1x, 2x, 3x)
[ ] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)

Microsoft Reviewers: Open in CodeFlow

Although nothing uses it yet (I think), we should probably update the hex value in FURN too


Replace moment.js with dayjs

To reduce the library size I suggest to replace moment.js with dayjs

Good idea! Thanks for the suggestion


versioning by branch doesn't support atoms

rebar2 allowed terms like this:
{rankmatcher, ".*", {git, "https://github.com/Licenser/rankmatcher.git", {branch, master}}}

this crashes rebar3 with
===> Fetching rankmatcher ({git,
                                      "https://github.com/Licenser/rankmatcher.git",
                                      {branch,master}})
===> rebar_fetch exception error badarg [{re,replace,
                                                 [master,"([ ()?`!$])",
                                                  "\\\\&",
                                                  [global,{return,list}]],
                                                 [{file,"re.erl"},{line,355}]},
                                                {rebar_git_resource,download,
                                                 3,
                                                 [{file,
                                                   "/Users/heinz/Projects/Other/rebar3/_build/default/lib/rebar/src/rebar_git_resource.erl"},
                                                  {line,99}]},
                                                {rebar_fetch,
                                                 download_source_,3,
                                                 [{file,
                                                   "/Users/heinz/Projects/Other/rebar3/_build/default/lib/rebar/src/rebar_fetch.erl"},
                                                  {line,45}]},
                                                {rebar_fetch,download_source,
                                                 3,
                                                 [{file,
                                                   "/Users/heinz/Projects/Other/rebar3/_build/default/lib/rebar/src/rebar_fetch.erl"},
                                                  {line,29}]},
                                                {rebar_prv_install_deps,
                                                 fetch_app,3,
                                                 [{file,
                                                   "/Users/heinz/Projects/Other/rebar3/_build/default/lib/rebar/src/rebar_prv_install_deps.erl"},
                                                  {line,565}]},
                                                {rebar_prv_install_deps,
                                                 maybe_fetch,5,
                                                 [{file,
                                                   "/Users/heinz/Projects/Other/rebar3/_build/default/lib/rebar/src/rebar_prv_install_deps.erl"},
                                                  {line,412}]},
                                                {rebar_prv_install_deps,
                                                 update_unseen_src_dep,10,
                                                 [{file,
                                                   "/Users/heinz/Projects/Other/rebar3/_build/default/lib/rebar/src/rebar_prv_install_deps.erl"},
                                                  {line,343}]},
                                                {lists,foldl,3,
                                                 [{file,"lists.erl"},
                                                  {line,1261}]}]
===> Failed to fetch and copy dep: {git,"https://github.com/Licenser/rankmatcher.git",
                                   {branch,master}}

changing it to
{rankmatcher, ".*", {git, "https://github.com/Licenser/rankmatcher.git", {branch, "master"}}}

solves this but it will make a lot of rebar2 projects incompatible when not modified.

If this happens in a dependency this leads to a silent failure. :(


Cannot run two camera nodes at the same time

I am trying to execute two camera nodes for two cameras at the same time, but the moment I subscribe to both of them at the same time, none of the cameras stream and I get the following error:
[vimbax_camera_node-1] [WARN] [1726131009.302508129] [vimbax_camera_rgb.vimbax_camera_rgb]: Frame with status -1 received
My cameras are Prosilica GT2050 and Mako-G 419-NIR.
I also tried running one camera with vimbax driver and the other with vimba driver but the same error occurs.

After debugging turns out that the problem was with the bandwidth of the network drive. Closing as it doesn't have to do with the driver.


Fix: Various small fixes

Overview
This PR contains small fixes for some minor flaws in CouchDB which affected me during the development of the new functionality.

Proper error handling of file:open/2 calls in couch_file.erl. According to Erlang file module docs open returns {error, Reason}  in case of failure but in the couch_file:sync and init functions there are no such checks. Consequently when I received {error, emfile} kind of error, process crashed with badmatch instead of proper error.
When you implement validate_doc_update as an Erlang function it doesn't work because of a missing case clause, namely: when couch_query_servers:try_compile() calls proc_prompt_raw() which in turn calls erlang:apply() for a native function the return value of it is an atom ok or true but in case of JS function we have response code 1. I added a more general check in the validate_doc_update and now it works for Erlang functions as well. This was crucial in our case because JS functions are much slower and in our production system we are going to use validation functions implemented in Erlang.
When we tested CouchDB 2.1 with our production DB which contains gazillion of different document couch_mrview_util:reduced_external_size() crashed with badmatch randomly because of some broken docs in our DB. This is because full_reduce returned response in the format {_, _} and not {ok, {_, _}} as was expected there. After this crash CouchDB was broken completely for me. In order to fix this I added an additional "match-anything" case clause, because even if we had something really broken in our DB, CouchDB still should handle this more gracefully I believe.

Testing recommendations
These fixes were tested and they resolved all the problems i reported.
Checklist

[x] Code is written and works correctly;
[ ] Changes are covered by tests;
[ ] Documentation reflects the changes;

I decided to close this one and send each of the changes/fixes I did as a separate fine-grained PR. I believe this will help to track changes better


Negate attribute - where to place it?

Hi,
this veery useful extension is applied as a filter at the end.
Filter, however, has option to include negate attribute - how can I apply that to this extension?
I tried it as attribute inside extensions.json:
{
  "extensions": {
    "check-dependencies": {
      "version": "1.0.1",
      "negate": true
    }
  }
}

-well, that was not working. I can't see any other place where I could try to insert this attribute.
So, from my point of view, when it is applied as a filter, it should somehow consume negate attribute which is standard filter attribute.
Thanks

Hi @mcbsdEU,
This is possible but does not currently appear to be documented outside of the sensu-extension source code. You should be able to add filter attributes via the definition attribute. e.g.
{
  "extensions": {
    "check-dependencies": {
      "version": "1.0.1",
      "definition": {
        "negate": true
      }
    }
  }
}

Please let me know if this addresses the issue.


Dynamically choosing a YAML document path?

Greetings,
Thank you for yaml-rust!
I see in the docs:
assert_eq!(doc["foo"][0].as_str().unwrap(), "list1");
I would like to do something like:
let key = "[foo][0]";
assert_eq!(doc.dynamic_lookup(key).unwrap(), "list1");

Do you know if it is possible with yaml-rust?
Thanks!

https://github.com/ejrh/yaml-path


UI Document Pane doesn't match container size when VSCode's Zoom level is not at 100%

VSCode Version: 1.9.1
OS Version: Win10

Steps to Reproduce:
Just opened VSCode after Upgrade.  I saw this issue before too with some other document, but I'm reporting it now that I'm still seeing it.  Resizing the window doesn't fix it.  Resetting the zoom does seem to make the size match exactly.  Any other zoom level seems to make the region off proportionally.

Duplicate of #5745


Fix dimensionless vertical coord standard_name

After a whole day banging my head against the wall to figure out why a sea surface filter I created was removing my z coord I realized we made a mistake in the standard_name for the derived z coord in ocean models.  (See  https://github.com/SciTools/iris/pull/509 and my reckless copying-and-pasting after that!)
This PR changes sea_surface_height_above_reference_ellipsoid to altitude.  From the CF-1.6 document:

Altitude is the (geometric) height above the geoid, which is the reference geopotential surface. The geoid is similar to mean sea level.

PS: -z is altitude :wink:

Pinging @rhattersley.
Let me know if there is anything else I need to do in this PR

:+1: - though I have 0 knowledge of this part of the codebase.

The CF spec for something like ocean sigma over z defines the derived coordinate as "height, positive upwards, relative to ocean datum (e.g. mean sea level)". I note the use of the vague term "ocean datum" and "e.g." which implies the ability to use any well defined vertical datum. So even with complete CF compliance the standard name of the derived coordinate is not limited to a single value. (It might not even have a standard name!) But the source coordinates such as eta and depth are also defined relative to the ocean datum, so we could check which standard name/datum they are using. In the case of ocean sigma over z it looks like the derived coordinate should have the same standard name as eta. Is that true?

In the case of ocean sigma over z it looks like the derived coordinate should have the same standard name as eta. Is that true?

That is not OK for me. I interpret  eta as Sea Surface Height (SSH is a 2D variable or, if varying in time, 3D) and not the model grid z cooridnate.
Pinging @rsignell-usgs to help interpret the CF-conventions (or maybe we should call a lawyer?)

I was just talking to Jonathan Gregory about this.   The CF documentation is very vague on the calculation of dimensionless vertical coordinates.    We agreed that we need a way to say that the output of the calculated vertical coordinate is "height_above_geopotential_surface" and then be able to specify that this geopotential surface is something like NAVD88 or ODN.   @ocefpaf is correct that the water level and water depth variable are not coordinates, but since those variables are the only way to get the units of the computed vertical coordinate, that's where they come from in the computation of z.

Because standard_name is already taken by the type of vertical coordinate (e.g. ocean_sigma_coordinate) , maybe we need something like vertical_coordinate_standard_name or something.   @JonathanGregory, can you correct me here?

That's right. I will propose a new attribute on a CF ticket. I was thinking of making it sound more general such as result_standard_name (meaning the result of the formula) in case there is a need for something like that elsewhere. Jonathan

By the way, I agree with Richard's interpretation. The standard_name of the result is implied in some cases (like this one) by the standard_name of one or more of the formula terms. However, this is not always so; sometimes the formula implies a particular standard name. Saying what it should be is redundant, but would be much easier for some purposes, I expect, and it could also be specified how it can be checked to avoid inconsistency. This need some clarification in every case in Appendix D, so it's a bit of work, but would be useful, I think. Anyway, this should be the subject of the CF ticket. Jonathan

That is not OK for me. I interpret eta as Sea Surface Height (SSH is a 2D variable or, if varying in time, 3D) and not the model grid z cooridnate.

That makes sense - I over simplified in haste. They're both the height of something relative to the same datum, but one is explicitly the height of the sea surface and the other is the height of the phenomenon. They will have different standard names.
So in the absence of any extensions to CF, how about a map from eta name to derived coordinate name? For example:

eta
derived coordinate

sea_surface_height_above_geoid
altitude

sea_surface_height_above_reference_ellipsoid
height_above_reference_ellipsoid

We'd also want to include the aliases.

So in the absence of any extensions to CF, how about a map from eta name to derived coordinate name?

Better than what we have now.  I will change this PR to reflect that.

Here are all possible eta names I could find.  I added some derived z-coord name suggestions:
derived_names = dict(
    sea_surface_elevation='elevation',
    sea_surface_height='height',
    sea_surface_height_above_geoid='altitude',  # or 'height_above_geoid' ?
    sea_surface_height_above_reference_ellipsoid='height_above_reference_ellipsoid',
    sea_surface_height_above_sea_level='height_above_sea_level',
    water_surface_height_above_reference_datum='height_above_reference_datum'
    )

After some thinking I have to say that I do not like this extra complexity.  I think that calling all the derived z-coord altitude (or height) is better.  The ambiguity, if that is a problem, should be resolved by the user via the eta standard_name.
My problem with this complexity is the difficulty to access the z-coord.  Using axis='Z' won't work since, we have more than one z-coord (the non-dimensional and dimensional vertical coordinate)*.  So the user must print the cubes, look for what s/he is getting, copy-and-paste the name, and than load the z-coord! That is too cumbersome when dealing with different models.
* In an ideal world axis='X'/'Y'/'Z'/'T' would always return one and only one coord.  We have that problem with time and z.  I know that this is a CF-bug... But maybe we have a loophole here to make users life a little better when it comes to the z-coord.
What do you think @rsignell-usgs and @rhattersley?

Dear @rsignell-usgs,  @ocefpaf and @rhattersley
Following my conversation with Rich and this discussion, please have a look at the proposal I have made in CF ticket http://cf-trac.llnl.gov/trac/ticket/143.
Jonathan

By the way, can you tell me if I can request github to copy my own comments back to me by email (for the record)? Thanks.

@JonathanGregory , github does not send you notifications of your own changes.   So I always go to the top of the e-mail thread and click on the "View it on GitHub" link at the bottom of the 1st notification.   By viewing the convervation on github issues instead of in your e-mail you can see your comments and also benefit from the embedded images, code syntax highlighting, etc.   Just like on Trac issues.

I am closing this.  The CF way will be http://cf-trac.llnl.gov/trac/ticket/143.
For now I will keep using the wrong and awfully long sea_surface_height_above_reference_ellipsoid.

Agreed.

The CF way:  we should encourage the use of sea_surface_height_above_geopotential_datum for standard_name (and the new computed_standard_name for coordinate calculated via formula_terms.  And we need to then also specify geopotential_datum_name=NAVD88
as described here: http://cf-trac.llnl.gov/trac/ticket/118


Unifying Service fn/access to support functions with Generic parameters

I think there should be one canonical way to define and consume services.
Since the Service access implementation currently does not support Generics, this means there are multiple ways.
I hope we can identify and document the problem / limitation and somehow look towards resolving it.
So far, using Service.define, .fn, .TypeOf etc seems to be fine with Generic functions, but .access specifically blocks it.
Im personally using a workaround to support it, with so far no issues/downsides, other than the inconvenience of using it separately or patching Service :)

@patroza there is simply no way to do this. The reason is access & implement, etc. make use of infer and infer erase generics to unknown. This is the reason why it is explicitly blocked.
The canonical way of using generics is to avoid usage of Service and use the classical way with definition of an interface and definition of the access helpers manually.
You can post your workaround and we can evaluate if it is a viable alternative

https://www.typescriptlang.org/play/?ssl=1&ssc=1&pln=16&pc=14#code/GYVwdgxgLglg9mABAdxlAFgcQKZmwJxggB4AVAPgAoBDALkVIEp7TEBvAKEW8X2yhD4k1DgF8OHCAgDOURAHlEAXnZceqDDjyEIYiVACeAB2yIAkmGAFiAaXLLVPRAG0A1ohhJX2A3GCIbAF16GzdAxGwADyhcABNpREoAfXpPK3xEAEFGZXs0gkQAIUQAfkSUrJyle2L6PAA3Aj0OWOwIABtqPkQpMFke+gt04kMTPwVyCQB6KfL6cFcwOGQwKvsFpZXJADoNLFwCIiA

This is getting removed in favour of the new Has mechanism in the next major #277

Confirm removal in next major release, reason being both Has is better and TS 4 has restricted usage of recursive types to shape interfaces (Service no longer works)


Forward Kiiroo messages directly to Kiiroo devices

Right now we convert Kiiroo commands from meta files to Launch commands, then back to Kiiroo inside Buttplug. If a device supports a raw Kiiroo message, we should just pass the message unchanged to the device.

Onyx2


[BUG] Docker images do not start the RAPIDS conda env when used with docker exec

@rlratzel reported:
docker run to start an interactive bash shell, or to run an individual command, automatically executes in the rapids conda env.  However, when a container is started with --detach and has commands executed in it with docker exec, the commands do not run in the rapids conda env.
This affects jobs using the Jenkins Docker plugin.
The workaround is to issue a source /opt/conda/bin/activate rapids command in the script they define in order to use packages in the rapids env.

This issue seems to be resolved in #127. closing


gcc13: apply default errors from gcc14

Description of changes
This is for after branch-off.
We wanted to update GCC to 14.  We were okay with fixing all the new errors, but ultimately it had to be rolled back due to stability issues.
We don't know at what point in the 25.05 release cycle the next release will come out, so let's get ready by taking care of the new errors in advance.  Once GCC 14 is the default, this should be reverted.
Source: https://gcc.gnu.org/gcc-14/porting_to.html
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@emilazy, do we have to wait for branch-off? Probably would help nudge a lot of upgrades/patches/fixes of potential issues of packages during the ZHF for the current release.
I would push to merge this before the freeze.

It was Alyssa’s idea to wait. It means that we will never ship a GCC 13 with warning flags inconsistent with upstream in a stable release, which seems good to me.

I’m ready to merge this when you are.

(This doesn’t work, so we shouldn’t merge it yet. It adds the flags to gcc13 but not gcc.)

I tried to fix this in https://github.com/NixOS/nixpkgs/pull/356545, and have now given up and opened https://github.com/NixOS/nixpkgs/pull/356812.


Do not log attempts to access local machine as CRITICAL

Requested by @teodorescuserban — see https://github.com/HXLStandard/hxl-proxy/issues/400

@teodorescuserban - the test branch of libhxl-python no longer logs a CRITICAL error for attempts to access the local filesystem. Please test with hxl-proxy if/when you have a chance.

@teodorescuserban - the test branch of libhxl-python no longer logs a CRITICAL error for attempts to access the local filesystem. Please test with hxl-proxy if/when you have a chance.

@davidmegginson , yes, after pulling the latest test libhxl-python on beta, it does work.
[2022-08-04 13:07:09,610] ERROR in hxl.input: Security settings forbid accessing local files or non http(s)/ftp(s) URL schemes: passwd

Thank you, @teodorescuserban ! Closing.


problem

Demo: https://www.ahmetozalp.net/

Hey @ahmetozalp! I suggest you try posting your question over on stackoverflow.com, with a detailed description of what problem you're having!

http://stackoverflow.com/questions/43205919/instafeedjs-doest-work-on-my-site


Support for OpenMP 4.5's reduction for c/c++ arrays?

If I'm not mistaken, cython.parallel does not already support OpenMP 4.5's reduction for c/c++ arrays feature.  This would be very useful for a number of tasks.  Are there any plans for supporting this?

Here is some code and explanation of what I think the problem is:
https://github.com/bearnshaw/mult-cython

Thanks for the test case. I'm still closing this in favour of #2316 which has more details in the discussion.

@scoder Did you accidentally forget to close?


updates Gemfile to push us to beaker 2.24.0

untested, so I'll keep an eye on CI as discussed...

:octocat:


update readme

/monitoring

Hey, @eosho!
:rocket: Deploying monitoring to WBADemo-RG is beginning! :rocket:

Hey, @eosho!
:tada: Monitoring deployment to WBADemo-RG completed! :tada:

/infra


Public strtok_r

Hello,
In one of the project that I've been involved, I had the need to use strtok_r.
Since this function is private in pdclib, I had to use the one provided by Charlie Gordon (link for reference: https://groups.google.com/forum/#!msg/comp.lang.c/akY2fEnquSU/hGZkhrvssSoJ).
I'm opening this issue to ask about the possibility to have a public strtok_r in pdclib, so we can use the internal one.
Thanks
PS: adding @JayFoxRox to this ticket because we were following this issue toghether.

I actually made some other recommendation (against public strtok_r), because pdclib README says:

This is a C Standard Library. Nothing more, nothing less. No POSIX
or other extensions, just what's defined in ISO/IEC 9899.

Here's my original suggestion:  https://github.com/Cxbx-Reloaded/xbox_kernel_test_suite/pull/58#discussion_r285334612  (introducing it with a prefix, so it's hidden under most circumstances)
This is important, as to not conflict with other POSIX layers.
- It might still be tricky to properly integrate it into header files (as one would have to wrap pdclib headers).

Turns out this whole issue (strtok*()) is a bit of a mess:

POSIX defines strtok_r
Windows API defines strtok_s
ISO/IEC 9899:2011, Appendix K defines strtok_s, but different from what Windows defines.

Naturally, I would prefer to go with the standard's strtok_s, and probably will for sheer stubbornness ;-) but I am afraid it won't satisfy anybody (no strtok_r, conflicting strtok_s)...
Any thoughts on this? Would you be satisfied with a standard strtok_s (to which a POSIX-style strtok_r wrapper could be conceived)?

C11 strtok_s sounds fine with me. I wasn't even aware it existed.
I'm also against mixing POSIX or Windows API in this upstream libc.
strtok within pdclib can then be implemented by calling strtok_s internally (or a helper; as strtok_s should probably only exist for C11 and after). And strtok_r for POSIX can be layered as part of other projects (if necessary).
However, I wonder how to avoid conflicts with Windows strtok_s. This is also relevant for our original Xbox toolchain, as we also mimic Windows. Do we know how Microsoft or Clang for Windows deal with this?

The Annex K functions will only be declared if STDC_WANT_LIB_EXT1 is defined prior to including the standard headers. I guess Windows headers will just croak if it's defined, as Windows has several *_s() variants of standard functions in its API, and I don't think all of them match C11 definitions...
Handling that STDC_WANT_LIB_EXT1 -- and the standard's requirements for calling a constraint violation handler function instead of invoking UB if preconditions aren't met -- requires a bit of plumbing on the libc side, which I have already added to PDCLib.
I then wanted to implement strtok_s, looked for a reference implementation to test against, and found there isn't one (because, as I said, both POSIX and WinAPI disagree). At which point I shelved it for the day and went back to preparing my upcoming RPG campaign until inspiration strikes or one of you guys buggers me about it. Which just happened. ;-)
I could provide the "worker" function (with C11 strtok_s() functionality) as _PDCLIB_strtok(), and provide a C99 strtok() wrapper for that always, plus a C11 strtok_s() wrapper if STDC_WANT_LIB_EXT1 was defined.
This would give you the option to have a POSIX strtok_r() wrapper that accesses _PDCLIB_strtok(). How does that sound?

So... I commited an implementation of _PDCLIB_strtok(), which is referenced by both the (old) strtok() and (new) strtok_s().
The way to get at strtok_s():
#define __STDC_WANT_LIB_EXT1__ 1
#include <string.h>

Note that, in a translation unit, the define has to come before any includes of standard headers, as the definition is required to be consistent for all standard headers affected by it. I.e., you may not #include <stdlib.h> with no definition and #include <string.h> with definition. PDCLib will issue an #error diagnostic in this case.
strtok_r can be implemented like this:
#define __STDC_WANT_LIB_EXT1__
#include <string.h>

char * strtok_r( char * _PDCLIB_restrict s1, const char * _PDCLIB_restrict s2, char ** _PDCLIB_restrict ptr )
{
    rsize_t max;

    if ( s1 == NULL )
    {
        max = strlen( *ptr );
    }
    else
    {
        max = strlen( s1 );
    }

    return _PDCLIB_strtok( s1, &max, s2, ptr );
}

The additional strlen()s are a bit unfortunate, and right now the _PDCLIB_strtok() backend doesn't even "do" anything with the parameter, but I guess I will add appropriate bound checks to _PDCLIB_strtok() eventually (as they are required by the standard).
Using C11's strtok_s() instead of the strtok_r() above will save you those extra strlen()s, as the C11 parameter is preserved between calls the same way ptr is.
Does this solve the issue to your satisfaction?

I think this should be perfect.
@JayFoxRox what do you think about it? Can I close this issue?
Thanks

Thanks for looking into it that quickly @DevSolar .
Regarding what @Luca1991 asked:

what do you think about it?

I'm not responsible for that part of our downstream toolchain. I'm not an expert about strtok either.
But skimming over it, the integration appears to be a good solution.

Can I close this issue?

You are the user that has to use it in their application (and owner of this issue): It's up to you.
(Worst case would be that it has to be re-opened or a new issue has to be created)

Closing this for now. Feel free to re-open if there should be any issues with the implementation.
Sidenote, I'm in the process of "polishing" this. Adding documentation for strtok_s() to string.h, adding the required-by-standard calling of the constraint handler function in case of runtime constraint violation etc.; meaning that, while _PDCLIB_strtok() should satisfy you already, it doesn't satisfy me yet as it's not yet up to C11 specs. Just so that you know. ;-)

The _s functions are non-portable and at best optional (in C11). I'd go with _r, they're easier to implement and more widely-used.


db is undefined error - Firefox Incognito

Just checked this one. I probably misremember. I thought it was upon exporting settings string, but it's currently upon inputting a rom, preventing the green checkmark from appearing. (does also prevent seed gen, because the site will mark the rom as bad when trying to generate a seed).
Import/Export settings string works in Frefox Incognito. Sorry if it's just me misremembering, though.

https://discord.com/channels/463917049782075395/559837167430664203/1112856215853207632


Youtube API is exposed.

Hey mate, great project btw. Kudos to that. Although I did notice that your youtube API key is public. You delete this key in your google console. Create a new one and inject it when you are deploying your code using env variables. Just a suggestion.

Hey dude, thanks for your message. I know that my YT API key is public and also my MongoDB Atlas Key, but with the next update I will change it to env. variables, thank you for your message!


Nick list from slack?

Is it possible to query the slack channel about who is there?

No, that's not possible at the moment. As far as I can see this isn't supported by node-slack-client either, but if you want to get it working in a fork you could use this.slack's private _apiCall method (from here: https://github.com/slackhq/node-slack-client/blob/5cc18662ca09c299ff3a93a109803d728ab77616/src/client.coffee#L539) in the following way:
var channelId = this.slack.getChannelByName('#channel-name');
this.slack._apiCall('channels.info', { channel: channelId }, callback);

The channel.info API endpoint is documented here: https://api.slack.com/methods/channels.info.
I'm gonna close this, as I don't think this is something that is needed in slack-irc's core functionality.


gNMI-1.4:Removed TestSoftwareModule test and deviation_components_software_module_unsupported

Removed TestSoftwareModule test and deviation 'deviation_components_software_module_unsupported' as discussed in b/277134501.

Pull Request Functional Test Report for #1767 / c749b2c05ccf19c5fae332a7712fce775d098f06
Virtual Devices

Device
Test
Test Documentation
Job

Arista cEOS

gNMI-1.4: Telemetry: Inventory

Cisco 8000E

gNMI-1.4: Telemetry: Inventory

Cisco XRd

gNMI-1.4: Telemetry: Inventory

Juniper cPTX

gNMI-1.4: Telemetry: Inventory

Nokia SR Linux

gNMI-1.4: Telemetry: Inventory

Openconfig Lemming

gNMI-1.4: Telemetry: Inventory

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 47.79%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1341

Relevant Lines:
2806

💛  - Coveralls

Please resolve merge conflcts

Resolved the conflicts. Please check.

/gcbrun

Sorry, I missed that the deviation is used by Arista. Please revert the change to metadata.proto. By bad

Sorry, I missed that the deviation is used by Arista. Please revert the change to metadata.proto. By bad

Reverted the changes in metadata.textproto. Please check.

Alternate to /components/component/software-module/state/module-type is /system/state/software-version/ and the same is covered under gNMI-1.10

Sorry, I missed that the deviation is used by Arista. Please revert the change to metadata.proto. By bad

Reverted the changes in metadata.proto. Please check.

Removed the deviation in deviations.go, metadata.proto, metadata.textproto for all as the testcase using the deviation is removed.


Allow decode options to specify required claims

Hi, this is a potential solution for https://github.com/jwt/ruby-jwt/issues/244
When decoding, the caller can optionally supply an array of claims that must be present for the jwt to be valid. For example requiring the 'exp' claim to both be present and valid.
I wasnt sure whether to put the check within Verify.verify_claims and ultimately added Verify.verify_required_claims alongside. Let me know if you want any changes to how this is structured.

Looks good.
Would it make sense to have one "integration" test for this, testing the public interface for the required_claims parameter. For example some of the examles in the readme is also tested in readme_examples_spec.rb.

Just letting you know that I have been on a short holiday but I'm back now. I will get back to this in the next 2-3 days :)

@anakinj  Ive pushed a commit with an integration test. Let me know if anything needs more work.

Looks great. A minor adjustment to get RuboCop happy and we are ready to merge. https://github.com/jwt/ruby-jwt/pull/430/checks?check_run_id=3077229521

@anakinj I have fixed those rubocop warnings.


Zend\Mvc\Controller\Plugin\Forward::reattachProblemListeners

When controller->dispatch throw Exception Forward::reattachProblemListeners will never executed.
And SharedEventManager will never restore self state

This issue does still exist in the ZF2 codebase.  What's the practical consequence of it?  If I've grokked this part of the MVC stack properly it means that if the controller making the forward call swallows the exception and returns an array from the action it won't be converted to a ViewModel automatically (https://github.com/zendframework/zend-mvc/blob/master/src/Controller/Plugin/Forward.php#L85).  I don't see a way for userland applications to inject their own listeners into the problem list, and that's the only listener on the list.  That said, it is wrong and should be fixed if it's not considered a BC break (which it doesn't to me)

this is very old issue, not actual


Removed ability to ban yourself

There's a conflict due to the changes in the file structure. Redo the pull request, editing the latest file, and the problem will be corrected

This adds a lot more than just 'not being able to ban yourself anymore'.
💀

I'm actually not sure what happened to the file structure. I'll fix it when I get the chance.

Bippity boppity boop

memes

This isn't an actual issue, as the command checks to see if the admin level of the person executing the command is higher than the admin level of the target. Since your admin level is not higher than your admin level, the command shouldn't run.
I guess a hint telling someone that they aren't allowed to ban themselves is a good idea, though.

Im gonna work on this and make a new pull request as this one won’t be fixed anytime soon


Add file function

Adds file() command which gets file contents in the hops bundle.

 Add file() function to DSL


Improvements for system-notify

Expected Behavior

[x] Add additional options to the blade component.
[x] manage buttons
[x] possibility to add a custom HTML
[x] add a small doc

System GA

flex-grow: 1; */ remove & npm run build

https://git.awescode.com/awes-io/system-notify/merge_requests/11


user/db switcher for handling multiple database instances

With PivotalMySQLWeb you currently can connect to one(!) MySQL service instance only.
If you are using multiple db instances, as we do with our microservice architecture, this leads to the multiple PivotalMySQLWeb apps running on a PCF (which is ugly and ressource costly).
It would be great to have a user/db switcher (e.g. top right corner, where you see the logged in user already) in the PivotalMySQLWeb so that you could handle multiple mySQL instances with only one PivotalMySQLWeb app being installed on a PCF.
Thanks a lot in advance!

Done


Orc update

Merging the branch with main that I never needed in the first place.

rebasing because to kill the history of the second, unneeded branch


backups files not create in sub folder

like this: octoprint/Artillery Hornet
and the plugin thinks that this "octoprint/Artillery Hornet" is the name of the folder
Thank you! , Love the plugin, for alerts I use IFTTT and as soon as a new file pops up in the folder then I get an email alert.

Are you trying to put it in a sub-folder of a sub folder? Try including the / at the end, ie octoprint/Artillery Hornet/ maybe? Another option for keeping multiple printer separated is changing the Title setting in OctoPrint's Appearance settings and the backup file will be named based on that setting.

FYI, this is still an issue. Adding a trailing slash / does not fix that you cannot store more than one folder deep from root. (IE. Backups/Octoprint).

Thanks for the pointer, I have a similar function call in this plugin and I suspect it just needs to be made recursive for the additional /.

Hi,
Same issue.
Just a message to follow this topic.

Hi,
This issue is still present in the latest version.
Any plans to fix this?

Eventually, I just haven't had much time lately for plugin development.

Would really appreciate to be able to set the folder ID instead of a string. this would allow to use a folder in a shared drive as well

So, I'm looking at the code again and in theory if you have an existing folder that is writable, shared or not, if the configured folder name in the plugin's settings matches the plugin should find it. The one caveat to that is if there are multiple folders with the same name, then the plugin will use the first one found for processing. I'm still looking into a possible recursive approach to a provided path in the settings, ie OctoPrint Backups/Printer1, but in my experience I've been able to handle multiple printers by adjusting the title setting in OctoPrint's appearance settings to have unique zip file names.

I've been able to make the folder creation/upload recursive using linux style folder pathing, ie OctoPrint/Backups/Printers/1

Thanks a bunch for this - sub folders is working great !!
However for my purpose I actually need to store them in 'Shard folders' will create a new issue for this.


sidecar when outboundTrafficPolicy is set to REGISTRY_ONLY,what the envoy config will changed to be,I can not find the changed config?

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sleep
spec:
  workloadSelector:
    labels:
      app: sleep
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY

sidecar when outboundTrafficPolicy is set to REGISTRY_ONLY,what the envoy config will changed to be,I can not find the changed config?

If it is allowany there will be catchall virtual host with Passthrough destination and if it registry only, it will a blackhole cluster.
Can you please ask these questions in https://discuss.istio.io/ ?
Issues are meant to report bugs or request for new features.

ok


Fix broken links on the main page.

Linking the README.adoc file to the overview.adoc in the doc directory causes all links on the first page not to work.
My fix removes the overview.adoc, and moves it into the root as README.adoc with updated references (so the links still work). I also replaced filenames with a textual representation (ex: doc/intro.adoc with Introduction).
This is a very small change, but I think it is important not to have broken links on the first tutorial page, and would like to merge it sooner rather than later.

Where are you looking at this? The tutorial shouldn't be read on Github, but on a deployed version like https://alpha.plutus.iohkdev.io/tutorial/.
The README in the folder should probably not be the tutorial overview, though. Github does a sort of best-effort rendering of adoc files, but it's got no chance if you have multi-file documents. So we only want people to look at the deployed versions now.
Incidentally, getting rid of overview.adoc will definitely break the tutorial build, so I have no idea how the CI passed here...

@michaelpj, I added a README pointing to the built tutorials (production and development).

@michaelpj  I squashed all commits into one and used the syntax change you suggested.


Turn off stalebot

A lot of valid issues are being closed because this project is not active. Can we at least remove stalebot? @yogevbd

@yogevbd any updates?

@erkie, thanks for your contribution 💟 . I do understand your request but let's give it another shot. If we'll see again in the future that  issues are being closed without a reason we will rethink about it.

@DanielEliraz will you go in an reopen all issues and PRs that stalebot wrongly closed?

@erkie, hopefully yes. And this should be done anyway..


use GTK+ theme for rendering where relevant

First, the EditView widget needs a css name (so CSS rules of the form xieditview { background-image: linear-gradient(45deg, yellow, blue); } work) and the .view CSS class (so the CSS rules from existing GTK+ themes will do something sane for Xi.EditView widgets).
Then the EditView asks GTK to render a background for it according to the theme, rather than painting its own in a hard-coded color. It passes its Gtk.StyleContext down to Line.draw so Line inherits the view's visual state.
In Line, we add a special case to draw the selection using the theme color scheme. Other styles that specify foreground/background have no corresponding selectors in the GTK+ theme system, so they keep using the colors and styles from xi-core.
Because the visual appearance of selection can change without the underlying Style being updated by xi-core, Line separately tracks selected ranges and the Pango.AttrList for other styles; then it merges these into a single AttrList in draw().
The application still has the final say in all coloring decisions, as it can register a custom CSS provider with higher priority than themes, but this gives sane defaults and allows user configuration via the same interface as other GTK+ programs.

I'm not sure how well this will fit with the design/direction of Xi (there is some discussion in google/xi-editor#96 but I don't think there has been a decision yet on the final design) so for now I would like to wait with merging this until we know where Xi is going.
Generally speaking, I expected that xi-core has full control over the theme (which would be quite the opposite from what you are proposing here) and color themes for Xi would work across different front-ends.
Also it is not clear to me how this approach you suggest here will work in the end. I certainly expect to be able to switch color themes independently of the system GTK theme and I don't expect GTK themes to ship styles for xi-gtk so these themes would have to be defined separately from the system GTK themes. If this is the case then why not let the core handle themes so that themes can be used across different front-ends of Xi instead of themes that are specific to xi-gtk?
As a last point my gut feeling tells me that trying to mix themes from different sources won't result in something good looking so I'd prefer one single source to have complete control over the color scheme.

The point of this code is not to override or replace any of the style work in xi-core; it exists so that users can choose to have xi-gtk follow their GTK+ theme. I tried to keep changes to the minimum necessary to enable functionality that was impossible before.
It isn't sufficient to simply copy colors from a GTK+ theme to xi-core styles, because GTK+ CSS can specify (for backgrounds) multiple images and gradients and (in general) the applicable CSS style is dependent on widget nesting and state. This patch implements the same level of support for GTK+ CSS features as GtkTextView and GtkSourceView have, which isn't possible if users are simply writing xi-core styles.
Conversely, it would be insane (and probably prohibitively expensive in rendering) to do syntax highlighting based on CSS; I think xi-core has already decided to go for textmate- or sublime-compatible syntax highlighting definitions initially, and I don't see any benefit in not reusing this work. (With plugins, someone could probably write a parser and highlighter based on GtkSourceView language- and style-specs, but that should have no effect on the design of xi-gtk; such a plugin should work with any frontend.)
I don't think xi-core actually has support for styles yet, but when it gets them, it will need a way for styles to specify "use the terminal (for terminal-based frontends) or GUI library (for frontends like xi-gtk) default" for foreground or background colors. Otherwise there will be hordes of upset folks with transparent terminals that have gone opaque, along with problems for GUI frontends that want to work with the system theme.
If possible, I'd rather see this merged sooner rather than later, because it conflicts with other changes to style and rendering logic, which are necessary for fixing issues #16 and #19.

I disagree that the colors coming from the sublime-compatible syntax highlighting definitions should be mixed with colors coming from the system GTK theme. I just can't imagine how this would result in a good looking color scheme.

I disagree that the colors coming from the sublime-compatible syntax highlighting definitions should be mixed with colors coming from the system GTK theme.

I don't see why we should prevent users from doing this. We should not indiscriminately mangle themes by overwriting bits of them, but we should allow themes to specify that the underlying frontend defaults should be used (which is useful for both terminal and GUI frontends). Is there an alternative route to getting xi-gtk to fit into the visual style of a user's system that I'm not seeing?
I don't think we should tell users they need to use a different editor if they want to be able to get their editor to look like the rest of their (GTK+-based) system. I'm not advocating limiting xi's styling system to a least-common-denominator of core and GTK+; if there are specific problems this implementation would cause, please let me know so I can investigate and fix them.

Is there an alternative route to getting xi-gtk to fit into the visual style of a user's system that I'm not seeing?

They could just create/use a Xi/Sublime theme that fits their system theme.

We should not indiscriminately mangle themes by overwriting bits of them, but we should allow themes to specify that the underlying frontend defaults should be used (which is useful for both terminal and GUI frontends).

This would be great but I think this would need to be discussed with the xi-core people before I want to implement it in xi-gtk.

Is there an alternative route to getting xi-gtk to fit into the visual style of a user's system that I'm not seeing?

They could just create/use a Xi/Sublime theme that fits their system theme.

This isn't able to recreate the same appearance as users' GTK+ themes, because of features like complex backgrounds and widget-state-dependent rendering in GTK+. If a user's GTK+ theme has a gradient background, for example, xi-gtk using a solid color will stick out like a sore thumb.
I've discussed this a little in the xi IRC, but I'll make a specific inquiry about plans in this area and report back.

I'll weigh in here briefly. I'll confess to not having thought too deeply about how to reconcile a user-chosen system them with an also user-chosen editor theme. My gut feeling is to agree with @eyelash that the best option is for the user to choose a xi theme which is most harmonious with the system theme (or not harmonious, if their goal is to have a color riot on their desktop).
I can think of more sophisticated approaches, something involving mapping either at a coarse or a fine level. An example of the first is choosing a default xi theme for some of the known popular gtk themes. An example of the second would be to substitute elements of the themes which are "close". For example, if the system theme specified a blue-to-black gradient and xi requested a dark-blue background, the front-end could decide that it's a better user experience to substitute the system background from the one requested by the core. (obviously if one were a light color, this would not be a good experience).
Honestly this seems premature. There's a lot more work that needs to be done about how to resolve styles, especially if there are going to be multiple plugins generating syntax highlighting. My current thinking is to change the plugin<->core protocol to be in terms of scopes instead of concrete styles, and then to do style resolution in the core. This has a bunch of advantages, not least of which is fostering a theme library that can be used across the front-end ecosystem. But one option I'd be open to is propagating scopes all the way up to the FE.
Have you gathered empirical data from other editors (Sublime, Atom, Code, etc) that deal with this same problem?

Logs from irc discussion:
[:21:50] <sp3d> could anyone here take a look at https://github.com/eyelash/xi-gtk/pull/22 ?
[:25:47] <sp3d> I'm wondering how xi-core wants to share control over with frontends over styling; my thought is styles should be able to opt into frontends' default rendering for foreground or background
[:18:00] <raph> commented
[:18:31] <raph> hope it's useful
[:18:38] <sp3d> thanks
[:25:13] <raph> thinking about this a little more, maybe it's just a special role for bg
[:25:40] <raph> i don't think there's too much you can do for fg, because an arbitrary chunk of highlighted code is going to have a whole bunch of colors
[:26:11] <raph> the "default" fg isn't all that meaningful; in any case, the rest of the theme is designed to harmonize with it
[:26:27] <raph> but i think bg can be replaced as long as it's in the same ballpark
[:27:05] <sp3d> I'd really rather not be doing colorspace computations, since there's no universal notion of correctness there
[:27:06] <raph> i'm also thinking it shouldn't be up to the _style_ to opt into a system default or a fe default
[:27:25] <raph> colorspace similarity is a pretty well understood problem
[:27:37] <sp3d> right, but it's fuzzy and opaque to users
[:27:45] <raph> we're not talking precision here, we're talking about avoiding dark blue on black text
[:28:10] <raph> rather, it seems to me a reasonable option for the fe to allow the _user_ to opt the bg
[:28:14] <sp3d> the user should definitely be able to select dark-blue on black if they want?
[:28:21] <sp3d> yes, right
[:28:41] <sp3d> do you just mean we should move that decision from being stored in the style to being stored in the frontend?
[:28:56] <raph> it would make sense to me
[:29:09] <raph> keep in mind, i'm not really designing this, you and eyelash own the gtk fe
[:29:16] <sp3d> that sounds fine; it'd just be a boolean on top of the PR, which is what I'd planned
[:29:34] <raph> my role is basically to figure out what the core needs to do to support these various use cases
[:29:50] <raph> and i really wanna keep it simple
[:30:18] <raph> but i'm certainly open to putting more stuff in the fe<->core protocol if it leads to a great xp
[:30:43] <sp3d> yes, I initially wrote code that would have wanted to push GTK stuff into xi styles which is probably a bad idea
[:30:48] <raph> in this case, i'd need serious convincing :)
[:31:07] <sp3d> in general I don't think any core changes are necessary
[:31:10] <raph> cool
[:31:17] <sp3d> i.e. the PR works well without them
[:31:23] <raph> i would +1 a change that gave a user control to override xi's bg color
[:31:31] <sp3d> well
[:31:37] <sp3d> the problem is that it's not as simple as "bg color"
[:31:38] <raph> i mean at this point, i don't think xi is even requesting a bg color, right?
[:31:53] <sp3d> yes, my PR simply replaces the hard-coded white with using GTK's rendering
[:31:55] <raph> maybe it would help to break it down some
[:32:04] <raph> what other things besides colors?
[:32:21] <sp3d> positioned images and gradients
[:32:23] <raph> fonts and font size are currently up to the fe entirely, xi core doesn't get involved
[:32:43] <raph> (again, that might change; i think themes in eg sublime often do specify a font)
[:33:15] <raph> my gut feeling is that positioned images and gradients are useful in the context of bg but not fg
[:33:23] <sp3d> they're not supported in fg
[:33:29] <raph> ok then
[:33:36] <raph> then i don't understand what we're arguing about :)
[:34:07] <raph> when i say "override xi's bg color" i meant the fe can render any bg it likes, not be constrained to be the xi theme bg color
[:34:13] <sp3d> oh
[:34:15] <sp3d> ok
[:34:45] <sp3d> yes, I implemented the code to override the bg; the next thing to implement is a way to toggle this on/off
[:34:49] <raph> sg
[:35:11] <raph> my sense is that gtk users who use themes like options
[:35:14] <raph> i think that'll go well
[:35:33] <raph> in mac the philosophy is very different, there's essentially no theme support in the os at all
[:35:47] <sp3d> yes... OS 9 was a different time
[:35:54] <raph> and most apps don't present the user with a huge variety of choices
[:38:30] <sp3d> raph: so, in summary, this implementation seems sane, but the "use gtk base style" toggle should be in the frontend, not in styles?
[:38:43] <raph> i think so
[:39:12] <raph> (of course i haven't looked in detail at your impl, i'm just addressing the questions of consistency  that were brought up in the thread)
[:39:23] <sp3d> that sounds good to me; I just want it to be *possible* to opt into using the GTK rendering for otherwise "regular" text
[:39:28] <raph> (feel free to cut'n'paste anything if you like)
[:39:48] <sp3d> I'll just dump logs into the bug thread if that's fine

@eyelash with the above discussion in mind, what code changes are necessary to get this merged?

That discussion made the whole thing a lot clearer to me, thanks. I'm open to merge this if it is an option (and turned off by default). I'm still not very happy about adding more code to the draw method but I only just saw your comment so I'll have to think about this. Also I still think this would better be done at a later stage once themes are implemented in the core and xi-gtk has a UI for preferences.


Update documentation

Input.Execute doc update:
The description should be clearer, specifying that this value should only contain the name of the procedure without database name or semicolons etc..

merged


Just testing to see what the conflicts are

DO NOT MERGE!!
Just doing some analysis of merge conflicts between the two branches

Only 2 very minor merge conflicts. One in plans controller and the other in phases controller


Option to send html instead of text

Something if we want to work on getting the URLs, we're gonna need to send in the html. Plus I think most models are pretty good at groking html anyways.

It ends up being so much slower. Don't wanna introduce additional overhead for users.


CMake build configuration for iree::vm2

This adds a CMake build configuration for iree::vm2. The subdirectory is not yet added to the root CMakeLists.txt, due to missing required internal CMake variables.

Actually looks like this breaks the cmake build. My bad, I should've gotten it to run the cmake presubmit before starting the pull. Your description says "The subdirectory is not yet added to the root", but it looks like the PR actually does add it to the root
https://github.com/google/iree/runs/365609185
CMake Error at build_tools/cmake/iree_tablegen_library.cmake:50 (tablegen):
  Unknown CMake command "tablegen".

Uhh, yeah, I should have commented on this. I initially did not add the subdirectory, but later added a commit that does and also enables compiling C.
Anyway, tablegen was working, thus I am confused what went wrong. Should I rebase onto the latest master?

Yeah I'm waiting to see if that's just a incompatibility with the CL it's getting bundled into right now. This is already submitted upstream but the sync process is taking longer than expected to push it to master. Let's see how the cmake build looks when it gets pushed and then if it's failing, try to fix it before pulling any of these other PRs.

:+1:

On my local machine i tested with  IREE_BUILD_COMPILER=ON, but the pre-submit build sets -DIREE_BUILD_COMPILER=OFF. So either there is something I am currently missing or this is somehow related with MLIR moving to LLVM (also I thought that the master still relies on the "old" submodules), since TableGen.cmake is part of LLVM. On quick fix would be to exclude the subdirectory and I can check within the next days what went wrong if it's not magically resolving itself.

Yeah looks like this is failing now at head. I'll see if I can repro locally and fix. I think it shouldn't have anything to do with the MLIR move, since we haven't incorporated that into our repo yet.
https://github.com/google/iree/runs/365622691

Do any of your other outstanding PRs depend on each other? I think not, right. Just checking since once the build is fixed I'll go ahead and pull them all in and want to make sure there isn't any ordering requirement. If you can rebase them all on top of #296 when it goes in, I'll pull them all

No, there are no (active) dependencies. Whenever a dependency cannot be fulfilled, it is commented out and marked as a TODO or the subdirectory is not yet added. So it should build... Rebased all outstanding PRs onto df2dbe1.


WIP: Webpack v4

In this PR and branch, we are preparing the forthcoming upgrade to Webpack v4.

[X] upgrade webpack to v4
[x] update configs to basically work
[ ] re-enable extract-text-webpack-plugin
[x] review and thoroughly revise configs
[x] fix chunking (CommonsChunkPlugin is deprecated)
[x] get rid of manifest.js mechanism (config, react, template...)
[x] investigate sideEffects: false

Re sideEffects: false: this is an ESM-only feature - we ought to enable this as soon as hops-{react, redux,graphql} migrated to ESNext.

Waiting for one of the following issues/PRs to be resolved:

https://github.com/webpack-contrib/extract-text-webpack-plugin/issues/701
https://github.com/webpack/webpack/pull/6448

We could also investigate switching to extract-css-chunks-webpack-plugin once this PR is merged:

https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/pull/61

@ZauberNerd since we discussed making this upgrade non-breaking, I checked what we broke, here. As far as I can tell, these are the two breaking changes introduced in this PR. We could re-introduce startServer (paging @robin-drexler), but honestly, removing it is quite an easy fix.
The first one, however, is the bigger issue. Reverting/mitigating that one would essentially make us re-implement WDS...
56315a3: refactor(build): get rid of WDS, use Express
BREAKING CHANGE: Since we got rid of webpack dev server, its config is
no longer supported. All existing hops features (including SSL) are
still supported, though.

d11c9d5: refactor(express): convert exports to getters
BREAKING CHANGE: remove legacy startServer export

What do you think?

LGTM, Although I'd prefer to split this into fixes / features / refactoring that we can deploy with the current Hops@10 and the breaking changes / webpack 4 integration that we'll release as a prerelease.

@ZauberNerd agreed. Could you help with that?
And how do you think we should deal with the DevServer stuff? If we treat it as non-breaking, we could merge it before the Webpack stuff...

@ZauberNerd should we not work on #417 in lieu of this PR, i.e. close this..?


Automatic registration of defautl serializers in ruby

The current api constructor body doesn't contain any code to automatically register serialization providers so client users don't have to do it manually.
https://github.com/microsoft/kiota-samples/blob/092356cbaeb09fc2e3632ce2fee3db116b4c9fbc/msgraph-mail/ruby/graphrubyv4/api_client.rb#L35
Should contain something along the lines of
ApiClientBuilder.RegisterDefaultSerializer<JsonSerializationWriterFactory>();
ApiClientBuilder.RegisterDefaultDeserializer<JsonParseNodeFactory>();

Which the request adapter implementation would default back to in case nothing has been explicitly passed to it.
This requires:

[ ] adding singletons for the registries in abstractions
[ ] (optional) adding helper methods to insert factories into those registries
[ ] updating the method writer
[ ] updating the ruby refiner to replace the default values (when nothing is passed to Kiota from CLI options)

closing as duplicate of #478


It requires pytest-runner for build

Let me quote pyproject.toml:
[build-system]
requires = [
    "setuptools>=67.4",
    "wheel", "pytest-runner",
]

is it really required to build it, not test?

This used to be a requirement for being able to use setup.py test. But direct setup.py invocation is deprecated anyway, so it can probably be removed. I think this is mostly a leftover from the automatic migration to pyproject.toml.

Thanks for very fast fix!

The same issue exists at https://github.com/MatthiasValvekens/certvalidator and https://github.com/MatthiasValvekens/pyHanko at least


non-root podman not able to ping external services (limited net capability)

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Non-root podman not able to ping external services (limited net capability).
Steps to reproduce the issue:
$ podman run -it --rm busybox /bin/sh
Trying to pull docker.io/busybox:latest...Getting image source signatures
Copying blob 697743189b6d: 738.18 KiB / 738.18 KiB [========================] 0s
Copying config d8233ab899d4: 1.46 KiB / 1.46 KiB [==========================] 0s
Writing manifest to image destination
Storing signatures
/ # ping google.com
PING google.com (<IP_ADDRESS>): 56 data bytes
^C
--- google.com ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss  ===> Not able to received

$ sudo podman run -it --rm busybox /bin/sh
[sudo] password for prkumar:
Trying to pull docker.io/busybox:latest...Getting image source signatures
Copying blob 697743189b6d: 738.18 KiB / 738.18 KiB [========================] 0s
Copying config d8233ab899d4: 1.46 KiB / 1.46 KiB [==========================] 0s
Writing manifest to image destination
Storing signatures
/ # ping google.com
PING google.com (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=54 time=7.746 ms
64 bytes from <IP_ADDRESS>: seq=1 ttl=54 time=8.390 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss   ===> able to receive

Output of podman version:
 $ podman version
Version:       1.0.0
Go Version:    go1.11.4
Git Commit:    "49780a1cf10d572edc4e1ea3b8a8429ce391d47d"
Built:         Tue Jan 15 02:08:17 2019
OS/Arch:       linux/amd64
```

**Output of `podman info --debug`:**

```
 $ podman info --debug
debug:
  compiler: gc
  git commit: '"49780a1cf10d572edc4e1ea3b8a8429ce391d47d"'
  go version: go1.11.4
  podman version: 1.0.0
host:
  BuildahVersion: 1.6-dev
  Conmon:
    package: podman-1.0.0-1.git82e8011.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 49780a1cf10d572edc4e1ea3b8a8429ce391d47d'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree:<PHONE_NUMBER>0
  MemTotal:<PHONE_NUMBER>4
  OCIRuntime:
    package: runc-1.0.0-68.dev.git6635b4f.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: ef9132178ccc3d2775d4fb51f1e431f30cac1398-dirty
      spec: 1.0.1-dev
  SwapFree:<PHONE_NUMBER>0
  SwapTotal:<PHONE_NUMBER>4
  arch: amd64
  cpus: 8
  hostname: localhost.localdomain
  kernel: 4.20.6-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 75h 13m 59.7s (Approximately 3.12 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/prkumar/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/prkumar/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
  ImageStore:
    number: 2
  RunRoot: /run/user/1000
```

**Additional environment details (AWS, VirtualBox, physical, etc.):**
On Fedora 29 installed.

Can you enable --log-level=debug for the rootless call and pastebin results? F29 should have slirp4netns installed, but it's possible it doesn't.
@giuseppe Slirp supports arbitrary traffic, right, not just TCP/UDP?

this is a known problem that we have documented here: https://github.com/containers/libpod/blob/master/troubleshooting.md#5-rootless-containers-cannot-ping-hosts

ping for an unprivileged user works because it is a file caps binary, but we don't have that in the container.  We need root to enable access to ICMP for unprivileged users

Can we turn on the icmp boolean then it would work.
If you enable this sysctl does it work?
net.ipv4.ping_group_range = 0<PHONE_NUMBER>

If yes, then we should document this.

@rhatdan, we already have that in the troubleshooting.md file.  Do you think we should add something more?

Should be in the man page for podman run, I would guess.

@rhatdan Should we start a podman-rootless manpage for rootless-specific things like this, the newuidmap errors, etc?

Well you would have to reference it from the other man pages.  But I am fine with that.  Just realize that the average user executing podman commands does not know that we call this rootless. So they would not know where to find the man page.

I think some of the information in troubleshoot.md needs to be added to the podman run/create man pages.


Suppor for WCH-Link - CMSIS-DAP V2 probe

Hi!
There are CMSIS-DAP v2 adapters from China that works with openocd
[40975.589210] usb 1-3: USB disconnect, device number 12
[40984.609307] usb 1-3: new full-speed USB device number 13 using xhci_hcd
[40984.754909] usb 1-3: New USB device found, idVendor=1a86, idProduct=8011, bcdDevice= 1.05
[40984.754915] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40984.754917] usb 1-3: Product: WCH-Link
[40984.754918] usb 1-3: Manufacturer: wch.cn
[40984.754920] usb 1-3: SerialNumber: 0001A0000001
[40984.757874] cdc_acm 1-3:1.0: ttyACM1: USB ACM device
[40984.759750] hid-generic 0003:1A86:8011.0004: hiddev96,hidraw0: USB HID v1.00 Device [wch.cn WCH-Link] on usb-0000:00:14.0-3/input2

log from openocd
info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Warn : gdb services need one or more targets defined

probe-run/probe-rs doesnt find it since it detects cmsis-dap adapters by  checking for CMSIS-DAP in product string

Aw, the one thing that makes a cmsis-dap probe cmsis-dap is that it has to say "CMSIS-DAP" in the product string!!
Do you know if openocd has to do anything with these besides talk regular cmsis-dap to them? Could you test just updating our cmsis-dap detection to include their product strings, just to check that works?

Hi!
I tryed updating product detection like this
diff --git a/probe-rs/src/probe/cmsisdap/tools.rs b/probe-rs/src/probe/cmsisdap/tools.rs
index fd6c2c75..d161bec7 100644
--- a/probe-rs/src/probe/cmsisdap/tools.rs
+++ b/probe-rs/src/probe/cmsisdap/tools.rs
@@ -62,7 +62,7 @@ fn get_cmsisdap_info(device: &Device<rusb::Context>) -> Option<DebugProbeInfo> {
         .ok();

     // All CMSIS-DAP probes must have "CMSIS-DAP" in their product string.
-    if prod_str.contains("CMSIS-DAP") {
+    if prod_str.contains("CMSIS-DAP") || prod_str.contains("WCH-Link") {
         let config_descriptor = device.active_config_descriptor().ok()?;

         log::trace!(
@@ -124,7 +124,7 @@ fn get_cmsisdap_info(device: &Device<rusb::Context>) -> Option<DebugProbeInfo> {
 /// Checks if a given HID device is a CMSIS-DAP v1 probe, returning Some(DebugProbeInfo) if so.
 fn get_cmsisdap_hid_info(device: &hidapi::DeviceInfo) -> Option<DebugProbeInfo> {
     if let Some(prod_str) = device.product_string() {
-        if prod_str.contains("CMSIS-DAP") {
+        if prod_str.contains("CMSIS-DAP") || prod_str.contains("WCH-Link") {
             log::trace!("CMSIS-DAP device with USB path: {:?}", device.path());
             log::trace!("                product_string: {:?}", prod_str);
             log::trace!(

After that I can detect probe using
$ ./probe-rs-cli list
The following devices were found:
[0]: WCH-Link (VID: 1a86, PID: 8011, Serial: 0001A0000001, CmsisDap)

but info doesnt work =\
$ ./probe-rs-cli info
Error: Failed to open the debug probe.

Caused by:
    0: Probe could not be created
    1: Probe was not found.

lsusb info for the probe
$ lsusb -v -d 1a86:8011

Bus 001 Device 015: ID 1a86:8011 QinHeng Electronics WCH-Link
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0         8
  idVendor           0x1a86 QinHeng Electronics
  idProduct          0x8011
  bcdDevice            1.05
  iManufacturer           1 wch.cn
  iProduct                2 WCH-Link
  iSerial                 3 0001A0000001
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x006b
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               4 WCH CMSIS-DAP
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      0
      iInterface              4 WCH CMSIS-DAP
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x01
          call management
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               2
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              5 (error)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              6 (error)
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      33
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1

BTW: working config for openocd
source [ find  interface/cmsis-dap.cfg ]
adapter speed 500
cmsis_dap_vid_pid 0x1a86 0x8011
transport select swd

so it looks like
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz

Seems there were similar issue with https://github.com/pyocd/pyOCD/issues/1121

Interestingly it looks like using the path provided by hidapi let them check if the interface says "CMSIS-DAP" instead of the product string - we could probably do the same when searching for HID devices, as well as checking interface names for composite devices that don't have it in the product string when using rusb. It'l require some tweaks to the probe searching code but seems like it would be possible and work with the WCH-Link.
My guess is your tweak let it detect it when scanning for probes but it then refused to open it, but running with RUST_LOG=trace might give more details. Still, it looks like we might not need to search for "WCH-Link" at all if we can check the interface strings too.

cc @adamgreig
I've updated on 0.14, but it still can't flash:
       DEBUG probe_rs::probe::cmsisdap::tools > Searching for CMSIS-DAP probes using libusb
       TRACE probe_rs::probe::cmsisdap::tools >   Interface 0: WCH CMSIS-DAP
       TRACE probe_rs::probe::cmsisdap::tools > Could not read string for interface 1, skipping
       TRACE probe_rs::probe::cmsisdap::tools > Could not read string for interface 2, skipping
       TRACE probe_rs::probe::cmsisdap::tools > WCH-Link: CMSIS-DAP device with 3 interfaces
       TRACE probe_rs::probe::cmsisdap::tools > No HID interface for CMSIS-DAP found.
       DEBUG probe_rs::probe::cmsisdap::tools > Found 1 CMSIS-DAP probes using libusb, searching HID
       DEBUG probe_rs::probe::cmsisdap::tools > Found 1 CMSIS-DAP probes total
       DEBUG jaylink                          > libusb <IP_ADDRESS>96
       DEBUG jaylink                          > libusb has capability API: true
       DEBUG jaylink                          > libusb has HID access: true
       DEBUG jaylink                          > libusb has hotplug support: true
       DEBUG jaylink                          > libusb can detach kernel driver: true
       TRACE probe_rs::probe::cmsisdap::tools > Attempting to open device matching 1a86:8011:0001A0000001
       TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 004 Device 001: ID 1d6b:0003
       TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
       TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 003 Device 002: ID 322e:202c
       TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
       TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 003 Device 005: ID 1a86:8011
       TRACE probe_rs::probe::cmsisdap::tools >   Interface 0: WCH CMSIS-DAP
       TRACE probe_rs::probe::cmsisdap::tools > Could not read string for interface 1, skipping
       TRACE probe_rs::probe::cmsisdap::tools >   Interface 2: WCH CMSIS-DAP
       TRACE probe_rs::probe::cmsisdap::tools >     HID interface found
       TRACE probe_rs::probe::cmsisdap::tools > WCH-Link: CMSIS-DAP device with 3 interfaces
       TRACE probe_rs::probe::cmsisdap::tools > Will use interface number 2 for CMSIS-DAPv1
       DEBUG probe_rs::probe::cmsisdap::tools > Could not open 1a86:8011 in CMSIS-DAP v2 mode
       TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 003 Device 003: ID 13d3:3563
       TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
       TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 003 Device 001: ID 1d6b:0002
       TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
       TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 002 Device 001: ID 1d6b:0003
       TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
       TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 001 Device 001: ID 1d6b:0002
       TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
       DEBUG probe_rs::probe::cmsisdap::tools > Attempting to open 1a86:8011 in CMSIS-DAP v1 mode
       DEBUG probe_rs::probe::stlink::usb_interface > Acquired libusb context.
       DEBUG probe_rs::probe::espusbjtag::protocol  > Acquired libusb context.
       Error Probe could not be created

             Caused by:
                 Probe was not found.
        INFO cargo_embed                            > Metadata {
    chip: Some(
        "Unspecified(\"STM32F411CEUx\")",
    ),
    probe: Some(
        "CmsisDap",
    ),
    speed: None,
    release: "0.14.0",
    commit: "crates.io",
}

Although probe-rs-cli detects probe:
❯ probe-rs-cli list
The following devices were found:
[0]: WCH-Link (VID: 1a86, PID: 8011, Serial: 0001A0000001, CmsisDap)

In the end we merged #1142 to get it in 0.14 for orbtrace and similar probe support, but it still doesn't work with wchlink. Though it seems like we might be closer to getting it to work now that it's detected - I've finally got one so I will try and get it working in a separate PR.


fix deleting sections

fixes #383

Coverage remained the same at 88.339% when pulling 2953d8e7f85f3b38f4f2c4066506bf33794b7991 on fix/delete-sections into 4913b54d4433c70ddcc2a1fc8d18b124f54fe1a9 on main.


Payment Form

Is your feature request related to a problem? Please describe.
.
Describe the solution you'd like.
.
https://user-images.githubusercontent.com/72241207/168656648-aa1708f0-ef6d-4822-b078-e64fe58eb729.mp4
Describe alternatives you've considered.
.
Add any other context or screenshots about the feature request here.
No response


build not same as src

Hello, I was just able to test your branch, I see that you tried to require mapboxgl only if using markers, here's your code which looks good
 mapboxgl: {
      type: Object,
      default: null,
      required: this.marker,
    },

here's the output at v-mapbox-geocoder.esm.js
 mapboxgl: {
      type: Object,
      default: null,
      required: undefined.marker
    },

I seems you can't access this at this point or the compiler at least can't find it

Downgraded to 0.2.3 as a workaround for now. More instructions here
I can't seem to be able to install from this Github repo with
npm install https://github.com/geospoc/v-mapbox-grocoder.git
It would be a better workaround to get v0.3.0 working.

Error output
><EMAIL_ADDRESS>preinstall <omitted path>\node_modules\@geospoc\v-mapbox-geocoder
> npx npm-force-resolutions

npx: installed 5 in 2.516s
ENOENT: no such file or directory, open './package-lock.json'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\jest-haste-map\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\watchpack-chokidar2\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\webpack-dev-server\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>preinstall: `npx npm-force-resolutions`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>preinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!  There is likely additional logging output above.
163 verbose exit [ 1, true ]

npx force-resolutions seems to be the culprit. will do a fix right away!

@vinayakkulkarni, did you fixed the issue already?

@karol-bujacek - Yep, was fixed in https://github.com/geospoc/v-mapbox-geocoder/pull/171/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519L88-L90

@vinayakkulkarni, the error with ‘undefined.markers’ is still not fixed in the latest package – https://github.com/geospoc/v-mapbox-geocoder/packages/233812


Update upgrade.md

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Deploy preview for docsdocker ready!
Built with commit 3fe0b28abd2301b424ead201f78ed8492be40433
https://deploy-preview-8887--docsdocker.netlify.com


Unable to build/test as root (was: bazel build -c opt envoy not working on mian branch)

it seems bazel build -c opt envoy not working on main branch
bazel build -c opt envoy
Starting local Bazel server and connecting to it...
WARNING: The following configs were expanded more than once: [clang]. For repeatable flags, repeats are counted twice and may lead to unexpected behavior.
INFO: Repository python3_10_x86_64-unknown-linux-gnu instantiated at:
  /root/go/src/istio.io/envoy/WORKSPACE:17:25: in <toplevel>
  /root/go/src/istio.io/envoy/bazel/repositories_extra.bzl:17:31: in envoy_dependencies_extra
  /root/.cache/bazel/_bazel_root/7f7b02015e8f8c68d9ee0e5dc9b62be7/external/rules_python/python/repositories.bzl:366:26: in python_register_toolchains
Repository rule python_repository defined at:
  /root/.cache/bazel/_bazel_root/7f7b02015e8f8c68d9ee0e5dc9b62be7/external/rules_python/python/repositories.bzl:269:36: in <toplevel>
ERROR: An error occurred during the fetch of repository 'python3_10_x86_64-unknown-linux-gnu':
   Traceback (most recent call last):
        File "/root/.cache/bazel/_bazel_root/7f7b02015e8f8c68d9ee0e5dc9b62be7/external/rules_python/python/repositories.bzl", line 153, column 25, in _python_repository_impl
                fail("The current user is root, please run as non-root when using the hermetic Python interpreter. See https://github.com/bazelbuild/rules_python/pull/713.")
Error in fail: The current user is root, please run as non-root when using the hermetic Python interpreter. See https://github.com/bazelbuild/rules_python/pull/713.
ERROR: /root/go/src/istio.io/envoy/WORKSPACE:17:25: fetching python_repository rule //external:python3_10_x86_64-unknown-linux-gnu: Traceback (most recent call last):
        File "/root/.cache/bazel/_bazel_root/7f7b02015e8f8c68d9ee0e5dc9b62be7/external/rules_python/python/repositories.bzl", line 153, column 25, in _python_repository_impl
                fail("The current user is root, please run as non-root when using the hermetic Python interpreter. See https://github.com/bazelbuild/rules_python/pull/713.")
Error in fail: The current user is root, please run as non-root when using the hermetic Python interpreter. See https://github.com/bazelbuild/rules_python/pull/713.
INFO: Reading rc options for 'build' from /root/go/src/istio.io/envoy/.bazelrc:
  'build' options: --color=yes --workspace_status_command=bash bazel/get_workspace_status --incompatible_use_platforms_repo_for_constraints=false --incompatible_strict_action_env --host_force_python=PY3 --java_runtime_version=remotejdk_11 --tool_java_runtime_version=remotejdk_11 --platform_mappings=bazel/platform_mappings --copt=-DABSL_MIN_LOG_LEVEL=4 --action_env=CC --host_action_env=CC --action_env=CXX --host_action_env=CXX --action_env=LLVM_CONFIG --host_action_env=LLVM_CONFIG --action_env=PATH --host_action_env=PATH --enable_platform_specific_config --test_summary=terse --define absl=1 --@com_googlesource_googleurl//build_config:system_icu=0 --test_env=HEAPCHECK=normal --test_env=PPROF_PATH
WARNING: The following configs were expanded more than once: [clang]. For repeatable flags, repeats are counted twice and may lead to unexpected behavior.
ERROR: @com_googlesource_googleurl//build_config:system_icu :: Error loading option @com_googlesource_googleurl//build_config:system_icu: error loading package '': at /root/go/src/istio.io/envoy/bazel/dependency_imports.bzl:10:6: Encountered error while reading extension file 'requirements.bzl': no such package '@base_pip3//': no such package '@python3_10_x86_64-unknown-linux-gnu//': The current user is root, please run as non-root when using the hermetic Python interpreter. See https://github.com/bazelbuild/rules_python/pull/713.

cc @phlax can you take a look?

Error in fail: The current user is root, please run as non-root when using the hermetic Python interpreter. See https://github.com/bazelbuild/rules_python/pull/713.

Looks like you're running as root which isn't supported, relevant convo from that issue: https://github.com/bazelbuild/rules_python/pull/713#issuecomment-1214865360

The command used to be ok, and it's broken after rebase with main.

@keith looks like this is hitting envoy-mobile also https://github.com/envoyproxy/envoy-mobile/runs/8307530744?check_suite_focus=true#step:6:43

this's a huge changed will break downstream CI, for example: https://github.com/istio/proxy/pull/4055

this's a huge changed will break downstream CI

yep, it wasnt trivial fixing Envoy's CI to work with the newer version.
not sure what we can do about that tho - we do want to track the latest version of rules_python - it is used extensively and is being actively developed

Also hitting oss-fuzz builds

I think we need to revert this until we have a better path forward. Can we do that?

(The path forward may be to just warn/fix dependent projects and give them time to update.)

Can we do that?

reluctantly yes - but im wondering on how we move it forward if we do so

also wondering if another possible fix is that downstreams pin their versions of rules_python rather than us doing so

I think we need to make some announcement about this at the very least. Can we revert and then come up with a plan for that?

I think we should revert, then do a blast to all the email lists, slack, etc. and say that we are going to roll forward in a week. This will give people time to pin, schedule work to stop using root, etc.

Is there no fix we can do in rules_python? Wasn't much response on the thread

i think only patching it - im a bit ambivalent about the whole thing - otoh it really isnt their responsibility to check for this - otoh its kinda virally enforcing best practice (certainly it improved our ci/sandboxes which were failing)
i think its unlikely to be reverted upstream from my reading of the context, and maintaining a patch to make it more insecure doesnt seem like a good way forward - so ive come to the conclusion we have to suck it up - but the knock on effect seem pretty huge - so not sure

Turns out there's a bool so we can unblock the update but not yet force the root issue. Updating here https://github.com/envoyproxy/envoy/pull/23231

thanks for tracking this down @keith


Security and overflow patch

Fixed issues with printing via sprintf and header_and_json file size.

Please review if this change takes place:
https://github.com/syoyo/tinygltf/pull/467/commits/1c6f6efafcf10f8a2981a1316253e16a5a2ed546

For sprintf_s,  it is not guaranteed  to be available when  __STDC_LIB_EXT1__  is not defined.
https://en.cppreference.com/w/c/io/fprintf

As with all bounds-checked functions, printf_s , fprintf_s, sprintf_s, and snprintf_s are only guaranteed to be available if STDC_LIB_EXT1 is defined by the implementation and if the user defines STDC_WANT_LIB_EXT1 to the integer constant 1 before including <stdio.h>.

So please use snprintf, which is available from C99
https://stackoverflow.com/questions/59948723/how-to-use-sprintf-s-for-linux-c

I really appreciate your attention. Hope this small fix will be fine

@rhiskey Thanks! Merged!


Check PHP extensions on runtime

Resolves https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/4329

Thank you @kubawerlos.


Node "use_list" for lang "rust" is not configured

basically title says it all

Submit an example of node "use_list"

use path::to::{This, Is, Use, List};


Implement Plan.amount_in_cents

The Checkout.js API requires the plan's amount in cents. This commit implements the amount_in_cents property on the plan which takes the plan's currency into account and doesn't multiply zero-decimal currency plans (although I haven't tested that, according to #247 zero-decimal currencies aren't working right now).

@jleclanche Go ahead and add your thoughts to #247. It'd be best to just tackle the underlying issue.

Sure. I think regardless of the resolution on that ticket this is good to land.

I agree that the property should land separately from that resolution. If you remove the zero-decimal code from this PR, I'll merge.

Any reason to remove it? It's straight up incorrect code if I do.

It'll be incorrect for zero-decimal currencies, which we won't support until a proper fix for #247 lands.

Updated. Leaving the list of currencies, it doesn't hurt there.

it doesn't hurt there.

It doesn't help there either :)

I can take it out, but I fully intend to add it back later. Help me out here, I have 27 branches in my local git repo and it's getting hard to get everything merged ;)

I fully intend to add it back later. Help me out here

The thing is, it depends on how we choose to go about #247. Having that list in the codebase means it needs to be maintained.
If you want to keep it in, move it to settings.py and I'll just make a note in #247 to remove it if the implementation doesn't need it.

Moved to settings.py.

./djstripe/settings.py:124:1: E305 expected 2 blank lines after class or function definition, found 1

Oops, fixed.


Inconsistent behaviour of checkExistenceById

Iam trying to use genericResources().checkExistenceById(id) to check my azure resource's existence, but this API returns 405 error code even when the resource exists and returns false when the resource does not exist. Is this expected behaviour? Iam using Azure sdk version 1.31.0, and tried this API for compute disks.

@xccc-msft please take a look at this issue? //cc @yungezz

@galitharun Thanks for reporting this issue. I'm able to reproduce it on different resource providers and resource types, like Compute/disks, Network/virtualNetworks, Storage/storageAccounts, Resources/deployments. Most of them return code 405, and some of them return code 503/400/404. Additionally we test same scenario on Python SDK and found out it also could be observed there. We will need help from service team to check this.


Dependency is not resolving.

Expected behavior
Added it in the build.gradle
implementation 'com.github.seik.kotlin-telegram-bot:telegram:6.0.0'
It doesn't seem to be work properly.
Classes are not importing.

Hey @Takshaksh,
the package name changed and also the coordinates of the library. So now you should add the next to make it work:
implementation 'io.github.kotlin-telegram-bot.kotlin-telegram-bot:telegram:x.y.z'


[zh] Rework the reconfig kubelet task

Most of the translation are good. However, there are quite some places
where the current Chinese text failed to convey the correct message ...

/approve


Azure Key vault plugin sends root certificate unnecessarily

Describe the bug
win-acme Azure Key vault plugin stores root certificate in key vault, causing azure services such as App Gateway to send the root certificate unnecessarily. Only the leaf certificate and intermediate certificate should be stored in Key Vault.
To Reproduce

Issue any certificate and chose Azure Key Vault as the store location
Observe "ISRG Root X1" being transmitted as part of the handshake (example: https://www.ssllabs.com/ssltest/analyze.html?d=policy.bai.org&hideResults=on)

Expected behavior
Only the leaf certificate and intermediate certificate should be stored in Key Vault.
Log
Nothing about the root cert available in log; there are no errors and the certificate install works. It simply contains the root cert unnecessarily when it should not.
Platform:

OS: Windows 2022, English
Version: WACS <IP_ADDRESS>9, 64-bit, pluggable; Azure Key vault plug-in v<IP_ADDRESS>

Additional context
Add any other context about the problem here, for example possible network issues (firewalls, proxies, NAT) that might play a role.

The "root" certificate is kind of ill-defined with Let's Encrypt. ISRG Root X1 has two signatures: it's both self-signed (root) and also signed by DST Root CA X3, see https://letsencrypt.org/certificates/
Sending ISRG Root X1 as part of the chain allows clients that only trust DST Root CA X3 to verify the chain. We're talking really old legacy clients here. But that might be the reason for Microsoft to include it.
I'm not sure if we can influence Azure's behaviour in that sense.

Weridly, IIS doesn't send the ISRG root certificate when configured by WACS. I guess was expecting the "same" behavior between the two,.

Yeah we had the same problem in CTW, this is a feature of Azure, specifically App Gateway is not IIS, so it doesn't behave the same way and doesn't follow the Window conventions for path building. The solution is to use the ISRG Root X1 preferred chain over the Let's Encrypt default (intended for compatibility, but which windows ignores). This involves using the R3 intermediate that's signed by ISRG Root X1.
In win-acme I believe this involves setting PreferredIssuer to "ISRG Root X1" - https://www.win-acme.com/reference/settings then re-requesting your cert.
You pretty much never serve the actual Root cert (because no client should trust what you send it anyway), but I've also seen azure build a weird variation of this chain as it tries to make sense of it all.

Chris' suggestion might work if Azure literally uses the .pfx file that's uploaded. But Microsoft products tend to be 'opinionated' on how to build chains. If it works out then I can document it for future reference.

Setting PreferredIssuer: "ISRG Root X1" results in the same behavior unfortunately. I guess I will file a bug report with Azure. You can close this one.

Setting PreferredIssuer: "ISRG Root X1" results in the same behavior unfortunately. I guess I will file a bug report with Azure. You can close this one.

Belay my that last message... it seems the app gateway hasn't picked up the new certificate from the Key Vault yet. Will advise on results as soon as it changes.

I can confirm your current certificate chain is now using the valid, modern ISRG Root X1 chain (I'm using https://chainchecker.certifytheweb.com/) to check.

Yeah we had the same problem in CTW, this is a feature of Azure, specifically App Gateway is not IIS, so it doesn't behave the same way and doesn't follow the Window conventions for path building. The solution is to use the ISRG Root X1 preferred chain over the Let's Encrypt default (intended for compatibility, but which windows ignores). This involves using the R3 intermediate that's signed by ISRG Root X1.
In win-acme I believe this involves setting PreferredIssuer to "ISRG Root X1" - https://www.win-acme.com/reference/settings then re-requesting your cert.

Wow... this actually worked! After setting PreferredIssuer: "ISRG Root X1", force-renewing the certificate (which stores it in Key vault), then waiting 30 minutes the certifticate chain is correct. Screenshot from SSL Labs test (image below).
I suppose at some point in the future after this should become the default issuer/chain requested by WACS, correct? Would it make sense to enter a backlog issue or roadmap item for that?

@rmalayter it's a tricky one because:

in the future ISRG Root X1 may not be the correct chain anymore
if users are currently exporting certs for use with Apache/nginx or other non-windows http.sys/schannel based services, then they are actually currently serving the default [Leaf] > R3 > ISRG Root X1 > DST Root CA X3 (expired), which is the default served by let's Encrypt and intended for old Android compatibility. So, changing this default would change the compatibility of those services.

It's a quirk of Windows certificate path building that means windows clients and windows services only really serve the [Leaf] > R3 > ISRG Root X1 (self signed) chain. This meant that when the old DST Root CA X3 root expired, windows happily switched over to serving with the modern chain by itself but also at the time broke a lot of clients and there was no real way back (if serving using IIS etc).
That said, the next major release of CTW (which is unrelated to win-acme) will indeed switch to using ISRG Root X1 by default. So there is (or will be) some precedent to changing the default. I'd actually prefer if win-acme did it first so they can be a canary for any potential problems :)

makes sense... closing issue