python311Packages.wagtail: 5.2.2 -> 6.0.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.wagtail is: A Django content management system focused on flexibility and user experience
meta.homepage for python311Packages.wagtail is: https://github.com/wagtail/wagtail
meta.changelog for python311Packages.wagtail is: https://github.com/wagtail/wagtail/blob/v5.2.3/CHANGELOG.txt
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 5.2.3 with grep in /nix/store/b911d1i7xp8agbalf6npvpyrw5qdbkvd-python3.11-wagtail-5.2.3
found 5.2.3 in filename of file in /nix/store/b911d1i7xp8agbalf6npvpyrw5qdbkvd-python3.11-wagtail-5.2.3

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
python311Packages.wagtail
python311Packages.wagtail-factories
python311Packages.wagtail-localize

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/b911d1i7xp8agbalf6npvpyrw5qdbkvd-python3.11-wagtail-5.2.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.wagtail https://github.com/r-ryantm/nixpkgs/archive/8a8fc4708f77767b1b636b8029871270693d240a.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/8a8fc4708f77767b1b636b8029871270693d240a#python311Packages.wagtail

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/b911d1i7xp8agbalf6npvpyrw5qdbkvd-python3.11-wagtail-5.2.3
ls -la /nix/store/b911d1i7xp8agbalf6npvpyrw5qdbkvd-python3.11-wagtail-5.2.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

python311Packages.wagtail-localize

2 packages built:

python311Packages.wagtail
python311Packages.wagtail-factories

Maintainer pings
cc @sephii for testing.

@ofborg build python311Packages.wagtail-localize

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.wagtail is: A Django content management system focused on flexibility and user experience
meta.homepage for python311Packages.wagtail is: https://github.com/wagtail/wagtail
meta.changelog for python311Packages.wagtail is: https://github.com/wagtail/wagtail/blob/v6.0/CHANGELOG.txt
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 6.0 with grep in /nix/store/pvym9kv0pyqh0risw3fyq4v3gsx8vv05-python3.11-wagtail-6.0
found 6.0 in filename of file in /nix/store/pvym9kv0pyqh0risw3fyq4v3gsx8vv05-python3.11-wagtail-6.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
python311Packages.wagtail
python311Packages.wagtail-factories
python311Packages.wagtail-localize

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/pvym9kv0pyqh0risw3fyq4v3gsx8vv05-python3.11-wagtail-6.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.wagtail https://github.com/r-ryantm/nixpkgs/archive/cdc995e9c3e129eb5e414a7f10207fa27b790b90.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/cdc995e9c3e129eb5e414a7f10207fa27b790b90#python311Packages.wagtail

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/pvym9kv0pyqh0risw3fyq4v3gsx8vv05-python3.11-wagtail-6.0
ls -la /nix/store/pvym9kv0pyqh0risw3fyq4v3gsx8vv05-python3.11-wagtail-6.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

python311Packages.wagtail-localize

2 packages built:

python311Packages.wagtail
python311Packages.wagtail-factories

Maintainer pings
cc @sephii for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.wagtail is: A Django content management system focused on flexibility and user experience
meta.homepage for python311Packages.wagtail is: https://github.com/wagtail/wagtail
meta.changelog for python311Packages.wagtail is: https://github.com/wagtail/wagtail/blob/v6.0.1/CHANGELOG.txt
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 6.0.1 with grep in /nix/store/jv0nr9b616c5qplv4y4rdnqi4gr6pmgv-python3.11-wagtail-6.0.1
found 6.0.1 in filename of file in /nix/store/jv0nr9b616c5qplv4y4rdnqi4gr6pmgv-python3.11-wagtail-6.0.1

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
python311Packages.wagtail
python311Packages.wagtail-factories
python311Packages.wagtail-localize

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/jv0nr9b616c5qplv4y4rdnqi4gr6pmgv-python3.11-wagtail-6.0.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.wagtail https://github.com/r-ryantm/nixpkgs/archive/dd3a9d7ca5446ec337d41333cfcbb3b24bc9f764.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/dd3a9d7ca5446ec337d41333cfcbb3b24bc9f764#python311Packages.wagtail

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/jv0nr9b616c5qplv4y4rdnqi4gr6pmgv-python3.11-wagtail-6.0.1
ls -la /nix/store/jv0nr9b616c5qplv4y4rdnqi4gr6pmgv-python3.11-wagtail-6.0.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

python311Packages.wagtail-localize

2 packages built:

python311Packages.wagtail
python311Packages.wagtail-factories

Maintainer pings
cc @sephii for testing.

This update depends on the following pending pull requests:
https://github.com/NixOS/nixpkgs/pull/289714
https://github.com/NixOS/nixpkgs/pull/289713
The dependency on laces will also have to be added to the Wagtail package.

Already on master.


OIDC feature for oAuth flow

Motivation
This PR adds support for JWKS in the AuthenticationProviderToken class. The reason why I didn't create a new plugin for this, is because I think it's a standard and it's really common to use.
Modifications
I've changed the AuthenticationProviderToken class so you're able to enable JWKS through the conf files.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): yes
The public API: no
The schema: no
The default values of configurations: yes
The wire protocol: no
The rest endpoints: no
The admin cli options: no
Anything that affects deployment: don't know

Documentation
You can try it out by setting jwkEnabled=true in standalone.conf and then also set the jwkUrl=[the URL for the JWKS]
HELP NEEDED
I can get this to work for the standalone version but when I try to use it in a cluster, it doesn't quite work. I hope someone can help me with this PR so we can merge the JWKS functionality. 😄  :octocat:

What about creating a separate Maven Module and use the Maven shade plugin to include all the third party deps in the .jar file for this Provider ?
This way we are not bundling the provider out of the box but we are adding it to the build.
Users will be able to pick the jar file and put it into "lib" in order to be able to use it
So zero impact to existing users and especially to other users who built something like this and need other versions of the same libraries

What about creating a separate Maven Module and use the Maven shade plugin to include all the third party deps in the .jar file for this Provider ?
This way we are not bundling the provider out of the box but we are adding it to the build.
Users will be able to pick the jar file and put it into "lib" in order to be able to use it
So zero impact to existing users and especially to other users who built something like this and need other versions of the same libraries

I can try this out if it's necessary. @cckellogg @michaeljmarshall I would like your feedback on this on as well 😄

I don't think I agree with making this its own module. If we did, I'd wonder why it wasn't in its own repository, or some kind of Pulsar Contrib repository. I don't have a fully formed opinion, though. I can provider more feedback tomorrow.

I don't think I agree with making this its own module. If we did, I'd wonder why it wasn't in its own repository, or some kind of Pulsar Contrib repository. I don't have a fully formed opinion, though. I can provider more feedback tomorrow.

@michaeljmarshall we have other components that are in the repo and that are not released in the "lib" directory, for instance the offloaders.
If this is meant to be a core feature, available out of the box, then it is fine to put it in "lib", otherwise it is better to create a separate module and let users add it to their system if they want.
My point here is about not adding "optional" modules to the core distribution.
Probably having some high level description of this feature, would help in understanding why this feature is so useful and why we should add it to Pulsar core.
Maybe it is just me, that I do not know JWKS and so I do not see the value in adding it to the core distribution, but I see more third party dependencies added to the core distribution.
Please note that I am not against this feature, I am sure it is useful. I am concerned only about the distribution of this code and the dependencies to the end users

Thanks for your response @eolivelli.

Probably having some high level description of this feature, would help in understanding why this feature is so useful and why we should add it to Pulsar core.

Yes, I think we need more definition for the problem that @MathiasHaudgaard would like to solve with this PR.

Maybe it is just me, that I do not know JWKS and so I do not see the value in adding it to the core distribution, but I see more third party dependencies added to the core distribution.

The JWKs data structure is defined in this RFC: https://datatracker.ietf.org/doc/html/rfc7517. The data structure can hold several kinds of cryptographic information, like public keys or private keys. Here is a helpful quote from the introduction:

JWKs and JWK Sets are used in the JSON Web Signature [JWS] and JSON Web Encryption [JWE] specifications.

I don't know all of the use cases of the JWK and JWKs data structure. I know it is used in the OpenID Connect protocol, an extension of the OAuth2.0 protocol, to store public keys that can be used to verify the signature on a JWT. An Identity Provider implementing the OIDC protocol will issue JWTs for an authenticated entity. These tokens will be signed by the Identity Provider using a private key. The Identity Provider will serve the paired Public Keys at an endpoint on the server to make it easy to verify token signatures.
The PR currently uses the JWKs endpoint to retrieve a single Identity Provider's public keys to verify the signature of the JWT.
For reference, the current AuthenticationProviderToken class verifies a JWT in the same way that this new class verifies a token (although each uses different libraries). The AuthenticationProviderToken class relies on a public key that is available in to the broker's file system. This implementation is limited because it allows for only one active public key, which means that to rotate keys requires downtime: first to distribute new tokens signed by a new private key and then to update the paired public key in the broker.
By adding support to retrieve a JWKs from an Identity Provider, we will gain the ability to have multiple valid public keys at the same time. That means it'll be possible to rotate keys without downtime. Further, because the public keys are discovered, operators will be able to remove public keys in the event that some part of the chain were compromised.
Ultimately, this PR would make it much easier for end users to integrate with an independent Identity Provider service, which is a great feature. However, from my perspective, I think this PR does not go far enough to implement a specific authentication protocol. I know that the JWKS endpoint is used in OpenID Connect. I'm not sure if it is used in any other authentication protocols. I think I would prefer to see a complete implementation of the OpenID Connect protocol (or some other protocol) instead of a partial implementation.
The main features that I currently see missing in this implementation (assuming we want to implement the OpenID Connect protocol):

Discover the issuer's jwks_uri by retrieving it at the issuer's /.well-known/openid-configuration endpoint (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)
Implement configurable caching of public keys (https://openid.net/specs/openid-connect-core-1_0.html#RotateEncKeys)
The trusted issuers should be required to use https, by default (it could be optional to override this requirement). This is technically required in the protocol: https://openid.net/specs/openid-connect-discovery-1_0.html.
(Optional) Allow for multiple issuers to be considered "allowed" or "trusted". This is convenient if you're running your identity provider in the same kubernetes cluster due to the way that k8s DNS works. (This component could be debatable, but in the event that we implement number 1, it'd be pretty easy to allow for this implementation too.)
(Optional) Allow for more algorithms than just RS256. Available algorithms are defined here: https://datatracker.ietf.org/doc/html/rfc7518#section-3.1. (This would be easy to add later, so it doesn't need to be a priority now.)

If we do implement the OpenID Connect protocol (or even some other protocol), I think it would certainly deserve to be in the core distribution.
@eolivelli - I think the question of which dependencies to use is a valid one that needs to be answered. I am not sure of the right answer, but I do think it'd be worth adding dependencies to get full support of the OpenID Connect protocol. The current 3rd party libraries from auth0 do not support retrieving the the provider metadata from the /.well-known/openid-configuration endpoint. Further, the auth0 library does not use nonblocking asynchronous IO. It'd be great if we could find a library that offers this. I'm not sure if one of these exists for OIDC.
Finally, I think we should resolve the asynchronous authentication provider issue that I raised on the dev mailing list before we can merge this PR. Otherwise, any network calls made by this provider will block netty event loop threads.
@MathiasHaudgaard - what do you think about my comments? Do you agree that this is meant to implement the OpenID Connect protocol or were you seeking to implement something different? I am not an expert on uses of the JWKS, so your insight will be helpful.
@eolivelli - I hope my comment has helped explain some of the context for this PR and its significance.

@MathiasHaudgaard - what do you think about my comments? Do you agree that this is meant to implement the OpenID Connect protocol or were you seeking to implement something different? I am not an expert on uses of the JWKS, so your insight will be helpful.

@michaeljmarshall, I think you're absolutely right. My knowledge of OIDC is a bit deficient, so I'll look into how I can implement it. Thanks for the feedback! 😃

Implement configurable caching of public keys (https://openid.net/specs/openid-connect-core-1_0.html#RotateEncKeys)

@michaeljmarshall is there a prefered way of doing this?

I left some more comments.
Can you post a reference to Licenses for the new libraries ?

https://github.com/auth0/auth0-java/blob/master/LICENSE

https://github.com/auth0/auth0-java/blob/master/LICENSE

This is very good.
You will probably see that CI will fail about the LICENSE check, because we list all third party libs here:
https://github.com/apache/pulsar/tree/master/distribution/server/src/assemble
and here
https://github.com/apache/pulsar/tree/master/distribution/server/licenses

I believe that we are on our way.
Thank you for your patience, we are giving feedback in multiple steps
Good job

I see that we are missing tests.

@eolivelli  I'm not quite sure how to test this plugin since it depends on a third-party provider. Any ideas? 😄

I'm not quite sure how to test this plugin since it depends on a third-party provider. Any ideas? 😄
it is possible to create a mock server with WireMock ?
otherwise we could (as last resort) use PowerMock to override the behaviour of Auth0 library

@eolivelli I've started on the tests for the plugin. I'm not done yet, but I would like your feedback so I know that I'm heading in the right direction 😄

The pr had no activity for 30 days, mark with Stale label.

Closed as stale and conflict. Please rebase and resubmit the patch if it's still relevant.


设置Image可以，但是把这个Image设置到UIButton上就显示不出来了

如题~

UIButton's internal imageView is not a YYAnimatedImageView subclass.
I think UIButton is suitable for small UI image, so you can create a _UIAnimatedImage with - [UIImage animatedImageWithImages:duration:] and set it to the button. You can try SDWebImage's coder wrapper such as SDWebImageGIFCoder or write a little code. :)


Use Travis CI to build doxygen documentation

Finish addressing #193.
This test will ensure that the Doxygen documentation builds without raising any warnings.
The bad news is that we currently have 86 of them that will need to be resolved.
We can either merge early and fix the warnings later OR wait and push fixes to this PR before we merge.  What do you all think?

The Travis CI build doxygen_documentation did run.  As expected, it is failing.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #195   +/-   ##
=======================================
  Coverage   95.71%   95.71%
=======================================
  Files         380      380
  Lines       28126    28126
=======================================
  Hits        26921    26921
  Misses       1205     1205

Continue to review full report at Codecov.

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

@sslattery I brought the number of warnings from 86 to 7.  Would you please take care of the few remaining ones?
Note that the Docker image is missing LaTeX at the moment.  I will add it once we get rid of all the current warnings.  Do not merge until I say it is ready.

Here is how to use the Docker image used on our Travis CI build to generate the doc and check for warnings.  From the DTK root dir, run:
[host]$ docker run --rm -v $PWD:/scratch -w /scratch dalg24/clang-format ./docker/travis/check_doxygen_documentation.sh

Consider using <...> | grep warning:.

I suggest to make this one blocking for #187.  (Which means we need would need to expedite it.)

Ready for review/merge

OK to merge once jenkins is happy


Squash migrations

When container starts it takes time to run migrations, and due to
migration to different DB it’s a good idea to squash them once (not all
of them will be even supported by Cassandra).
#222

Changes Unknown when pulling 43a90d532684b4660df2119d80e008a33f760a00 on squash-migrations into ** on master**.


Add 'pageName' configuration as a property

Hi,
This library we've found to be very useful so far. We need to add the capability to specify a page by ID to load when the report loads. This change allows that by accepting pageName as a property which passes on to the PowerBI-Client API behind the scenes.
I've tested locally on a multi-page report, with both nav enabled and disabled and this appears to work fine.
(I haven't bumped version numbers in this PR, but if you're happy with it then publishing to NPM a new version would be very helpful!)
Happy for feedback.
Thanks,
Dave

Thanks for the contribution! Would you mind changing it to pageId?

Hi @howlowck ,
I've updated as you've requested. I was torn too - I went with pageName initially because that's what the underlaying API seems to call it (https://github.com/Microsoft/PowerBI-JavaScript/wiki/Embed-Configuration-Details)
However, I don't think that makes much sense as what you have to type in seems much more "ID" based than the "display" value.
Happy to go either way you want :)

Gotcha. yea, that makes sense. we should conform to the core JS library's setting property name.  I'll up the minor version by EOD today.

Brill, thanks! :)

@howlowck - did you manage to publish anything to NPM? Thanks in advance!

@randompixel Published changes to 0.3.1

Sorry for the delay!

Brill. All working now. Thanks!
On Thu, 27 Sep 2018 at 14:49 Hao Luo<EMAIL_ADDRESS>wrote:

Sorry for the delay!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/howlowck/react-powerbi/pull/7#issuecomment-425099788,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACNZOSawbDTpJwp5AKIiPGeaTt6kdWWoks5ufNdxgaJpZM4WyQ5x
.


Upper and lower part of card and text are cutting at the time of hovering.

Hey @ANSHIKA-26 There is a issue on the home page. When we hover on the card, it's upper lower section cuts and the bottom texts of the image get hide.
I want to improve design of the card, so that UI/UX of the website can improve and issue get resolved.

Please assign this task to me, So that I can start working on it.
Kindly add the Labels (gssoc-ext, hactoberfest and Level1, Level2, Level3).

Add any level (Level1, Level2, Level3) also.

#319 exsits


During combat after the first move the colors are incorrect

If you have tracking on for combat and you have colored trails based on movement rate, it tracks your movement for the first move each turn during combat. If you move a second time, the trail is just green no matter how far you move.

Fixed in v0.8.11. Thanks!


fix: Codegen issues re: recursion, Swift keywords in unions

Issue #
https://github.com/awslabs/aws-sdk-swift/issues/1234 (Recursive unions)
https://github.com/awslabs/aws-sdk-swift/issues/1235 (Reserved word)
https://github.com/awslabs/aws-sdk-swift/issues/1096 (Recursive unions protocol test)
Description of changes
Fixes two codegen issues that prevented models from generating valid Swift.

Recursive unions were not being marked with the indirect keyword when Swift requires it.
Swift reserved words appearing in the cases of Smithy unions (i.e. Swift enums with associated types) resulted in invalid Swift

Also fixes an issue which arose when the recursive unions protocol test was re-enabled: that protocol test suite includes a model with sparse timestamps, which were not generating valid Swift in their deserializer method.  That code is now fixed, though it is not used in protocol tests.
Scope

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@jbelkins What do you think about adding a codegen test that starts with a smithy file?


"Cannot read property 'length' of undefined" when using bars on time series without 'labels' defined

Creating a bar dataset with xAxis of type "type" can result in error "Cannot read property 'length' of undefined". Should add check for definition of data.labels before checking the length.
Adding empty labels[] to data avoids the error, but bars are drawn.
https://jsfiddle.net/dotacoach/p8vLm0bj/5/

Adding the an empty Array literal for "labels" worked for me:

I think the label issue is fixed in master but still need #4661 for the {x, y} bar data.

Fixed in master (https://jsfiddle.net/p8vLm0bj/19/)


Adding automated build plus instructions

closes #73

Last thing to do on this one is to start with blank machine and install/build using README instructions and make sure it works


CLI is not working for Vue

When running npx @park-ui/cli init and selecting the following options an error is thrown.

https://park-ui.com/registry/tailwind/vue/helpers/index.json seems to be missing
Same goes for https://park-ui.com/registry/tailwind/vue/components/index.json

@raymondmuller
Thanks for taking your time to create this issue. I will have a look shortly

@cschroeter anything I can do to help?

Maybe park-ui isn’t ready for Vue yet? I don’t see Vue components folder on github.

@dannylin108 this should be fixed by now

with @park-ui/cli version 0.5.0 still the same error.
❯ pnpx @park-ui/cli add card
Packages: +1
+
Progress: resolved 1, reused 1, downloaded 0, added 1, done
│
◇  Failed to download Card component
The "path" argument must be of type string. Received an instance of Array

Should work by now


The part of the test after await does not run after instrumented by stryker

Summary
I am using async functions in the tested code.
The tests run fine with npx jest.
Stryker complains that the initial test run did not succeed.
After putting a lot of console.logs to the code, and changing directory to the stryker sandbox, running npx jest there gives an output which contains the log before an await, but nothing after it, including the log right after the await.
The offending await is at line 24 of src/runContractsfromList.ts of https://github.com/kode-konveyor/cdd-ts/tree/bugreport/test_disappears_after_await
Stryker config

{
  "$schema"<EMAIL_ADDRESS>  "mutate": [
    "src/**/*.ts"
  ],
  "thresholds": {
    "low": 100,
    "high": 100
  },
  "ignoreStatic": false,
  "warnings": {
    "slow": false
  },
  "testRunner": "jest",
  "reporters": [
    "progress",
    "clear-text",
    "html",
    "json"
  ],
  "concurrency": 2,
  "coverageAnalysis": "perTest"
}

Test runner config
package.json
{
  "name": "cdd-ts",
  "version": "1.0.0",
  "description": "Test-time Contract Development framework for TypeScript",
  "main": "index.js",
  "type": "module",
  "directories": {
    "test": "test"
  },
  "scripts": {
    "qa": "npm run lint &&npm run test&& npm run mutate",
    "mutate": "stryker run",
    "test": "jest",
    "lint": "eslint"
  },
  "jest": {
    "preset": "ts-jest",
    "testEnvironment": "node",
    "roots": [
      "<rootDir>"
    ],
    "modulePaths": [
      "<rootDir>"
    ],
    "moduleDirectories": [
      "node_modules"
    ]
  },
  "dependencies": {
    "@stryker-mutator/jest-runner": "^6.4.1",
    "fast-deep-equal": "^3.1.3",
    "fast-glob": "^3.2.12",
    "jest-mock": "^29.4.3",
    "tslib": "^2.3.0",
    "@nestjs/common": "^9.3.9"
  },
  "devDependencies": {
    "@babel/preset-typescript": "^7.21.0",
    "@jest/globals": "^29.4.3",
    "@stryker-mutator/core": "^6.4.1",
    "@types/jest": "^29.4.0",
    "eslint": "^8.30.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-config-standard-with-typescript": "^24.0.0",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-n": "^15.6.0",
    "eslint-plugin-promise": "^6.1.1",
    "jasmine-core": "~4.5.0",
    "jest": "^28.1.3",
    "jest-mock-extended": "^3.0.3",
    "stryker-cli": "^1.0.2",
    "ts-jest": "^28.0.8",
    "typescript": "~4.8.2"
  }
}

Stryker environment
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>

├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>
Test runner environment
# npx jest
# npx stryker run
# cd .stryker-tmp/sandbox*
# npx jest

Your Environment

software
version(s)

node
v19.7.0

npm
9.5.1

Operating System
Debian bullseye

Add stryker.log
stryker.log

Okay, no error handling in async function led to missing an exception.
The root cause was a missing return type definition.
A mutation changed the return type (from T to T|undefined), which in turn caused the test to err, which error was not handled and neither surfaced.
So I guess the fix is to show uncaught exceptions, and probably it belongs to jest.


CXF-8698: Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded (limiting decoding only to % encoded characters)

Limiting decoding only to % encoded characters (as per  RFC-2392).
// A "cid" URL is converted to the corresponding Content-ID message
// header [MIME] by removing the "cid:" prefix, converting the % encoded
// character to their equivalent US-ASCII characters

@atnyxp would it fix your issue with + encoding / decoding?


Add the field maps (when selected) to the subset QC sheets

In: https://github.com/nih-fmrif/abcd-dicom2bids/blob/feature/data-subset/src/subset_data.py

It would only be accurate without the --intended-for flag because only then could you just select ALL fmaps for a given subject session.

Bad idea, closing!


pdf-to-text only extracts first tiny part of document

hi^^ i tried today to use fast-p to make some math papers more searchable, but it just stops after a tiny fraction of the document.
using pdftotext on the same pdf works fine, then the whole thing is turned into a txt.
i've attached the cache-file when using fast-p in a folder that contains just a trial file (i had to change the ending bc github didn't let me upload a .db file but the content is the same...)
fast-p_cached_pdftotext_output.txt

Only the first two pages are extracted because this is typically where to find the author, title and abstract. The goal is only to find the pdf of the paper you are looking for, not to find certain keywrods in the whole document.
fzf which processes the extracted text as a single line would not be well-suited to process dozens of pages of extracted text. If you are interested in searching in the whole pdf beyond the first 2 pages, I suggest https://github.com/phiresky/ripgrep-all

my bad. sorry for rasing the (non-)issue!


Enable dynamic time zone information

Not sure if any country is using dynamic daylight saving time. If so, this now considers to use it.

That's been the last PR for now 😅

Even after reading the internal source code, I don't understand the difference between the non-Ex and Ex variants of these functions.

😯 For me this is unexpected. I must have misunderstood the docs then.

[...] Converts a local time to a time with dynamic daylight saving time settings to Coordinated Universal Time (UTC).[...]
[...][in, optional] lpTimeZoneInformation
A pointer to a DYNAMIC_TIME_ZONE_INFORMATION structure that specifies the time zone and dynamic daylight saving time.[...]

(emphasis mine)


Upgraded our OS to 14.2 and the enterprise app starts crashing, couldn't open it, install via MDM

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

CLI: 6.5.3
Cross-platform modules:
iOS Runtime: 6.5.3
Android Runtime (if applicable):5.5.0
Plugin(s):

Describe the bug
https://developer.apple.com/forums/thread/666399
OS: iOS 14.2, iOS 14.3 Beta 1, iOS 14.3 Beta 2
Hardware: Any arm64e cpu device (ex: iPad Pro 11" 1st/2nd gen, iPad Pro 12.9" 3rd/4th gen, iPad 8th gen, iPad Air 3rd/4th gen, iPhone 11, etc)
Deployment:
Deployed via any MDM and AppStore, install via MDM -> crash,install via AppStore -> works fine,
Ad-hoc .ipa deployment works fine even via MDM,
so via -> AppStore -> MDM -> crash
To Reproduce

Expected behavior
Sample project

Additional context
Does anyone have a similar problem? This is currently the same problem with Xamarin Apps.

Duplicate of #9079


Add USD plugin

What is blocking this @Meakk ?

Half of the reader code is not covered, we need to fix that :)

@Meakk could we move this one forward with SSIM or PSNR image comparison ?

I just need to add another test for covering the remaining lines. Feel free to review again.

@mwestphal please take a look. Coverage is good now and all comments have been addressed.


GCS authentication error

I'm trying GCS and I've incorrectly set the credentials (on purpose). I don't get an appropriate error message. The error returned by Create is nil, and every field in the response is nil, including status. I was confused, so I checked it out and the JSON response it's getting is:
{"message":"Invalid authentication credentials"}

ie. seems to be an unhandled case

Hi @vidaoaaron this has been fixed yesterday. Now all the services should return a meaningful err message if the call to the API failed.
Please open another issue if you see any problems or are missing errors where you'd expect them. I'm closing this now.


chore: cache node_modules

Hey there - this broke tests it appears.

Well, I guess this is some issue with the makefile. In general the scripts shoul be in package.json and .travis.yml.
I guess I'll port the makefile to npm scripts and .travis.yml scripts.
Because makefiles do not work on all platforms and this is more complex than needed.

GNU Make* doesn't work on all platforms. Makefiles work just fine. MSVC has its own make but it's slightly different.
I agree about moving those into package.json, as per #584.

We also don't include lockfiles in the repository, so I'm not sure how much I like the idea of caching node_modules. IMO it's an anti-pattern caching anything in CI.

IMO it's an anti-pattern caching anything in CI.

In general: no, CircleCI also does it and all others do it too. =)

I understand that the option is there to cache various artifacts, but the whole point of CI is to test - fresh - the entire process, from source checkout to final target artifacts. Caching and re-using those things is an anti-pattern given that definition.
Just because software gives you the ability to do something doesn't necessarily mean it's the best idea to utilize it. Plus, with this module in particular, the performance gains are tiny while the potential for error is high. There are already so many problems with Node.js package managers under normal use that I'm not sure there's a good enough reason to attempt to optimize in a way that might produce false positives/negatives.
@TooTallNate @thebigredgeek thoughts?

I see it differently also this is just about the dependencies and I saw no issues so far, also in big projects.
There is a reason for npm ci and the caches, also composer has a cache (for CI).

And what is that reason?

And what is that reason?

For what?

There is a reason for npm ci and the caches

What is the purpose of a cache in CI other than to decrease happy path builds?

Not sure what you mean. You normally do not reinstall the dependencies on every install (on normal machines), there are npm ci and lockfiles (they are meant to be committed), ...
Dependencies like jQuery, lodash, upath, ... do not change between builds.
So far I see no real facts against build caches ) and it's also for better DX as we can get more builds in the same time and testing is faster. For example magento/magento2 had definitely faster build. CircleCI 2 per default creates efficient build caches and their builds are extremely fast.
And I still did not see any issues arising in big projects of orgs like facebook/jest, angular/angular and others.
Can you provide real and current reasons not to use any caches on CI (even npm or composer cache) and actual issues of this?

Not sure what you mean. You normally do not reinstall the dependencies on every install (on normal machines)

CI is not a normal machine
CI is not an "install", it's CI. It's testing the entire flow from beginning to end.

Dependencies like jQuery, lodash, upath, ... do not change between builds.

They do if you don't pin them or have lockfiles.
Lockfiles are an anti-pattern for two reasons:

They are an artifact of the install/build process; artifacts do not belong in source control (just like binaries do not belong in source control)
They have a very, very lengthy history of bugs and false negatives/positives

So far I see no real facts against build caches

I just presented several, one of which particularly important in https://github.com/visionmedia/debug/pull/585#issuecomment-400093508: CI and tests are not supposed to be fast.
To expand a bit, CI and testing is supposed to be correct. Period. Caching modules is not correct. Caching modules does not reflect the flow a normal user would experience on their end when consuming the repository.
There are cases where packages would change from build-to-build. Here's one now:

Package A depends on package B; A is configured to cache modules, and A's package.json has all modules pinned (no ^ or ~ prefix)
Package B gets an update published; package A maintainers are notified
Package A updates B in dependencies block to newest version
Package A has a build as a result
Package B sees massive flaw in release and reacts by unpublishing since they're within the 24 hour policy NPM has mandated after the left-pad incident.
PR comes in for package A - no problem! Modules are cached. CI Passes, PR is merged.
Package A bumps as a patch release.
Package C, which relies upon package A, has "package-A": "^1.0.0" in their dependencies block; users automatically start acquiring the new version of Package A
Everything breaks.

This sounds far fetched. It isn't. It's happened before (we were package B in this scenario).
I'll leave other scenarios as an exercise to the reader. Just remember that CI is supposed to be complete and correct, not fast. Cached modules violate both ends of that contract.

and it's also for better DX

Not when you have false positives and negatives causing CI to fail, especially since the details of failures are not reported back to GH. Over the course of maintaining a slew of packages, I've found it rare that someone that submits a PR goes into the failed CI builds to see what the error is and push a fix completely autonomously. In most cases it results in a "I'm not sure why tests are failing" even though the error is right there.
Dependency errors are hard to track down, especially when you don't own the caching mechanism. As a maintainer, it's one more thing for me to worry about - whereas not having a cache means I never have to worry about false negatives/positives.

For example magento/magento2 had definitely faster build.

They're a larger repository. 10% faster on debug means seconds shaved off. 10% faster with magento (which has a lot1 of dependencies2 and loads of tests) means minutes or even, potentially, hours.
The comparison doesn't stick. As well, I'd make the same argument for them - I still firmly believe it's an anti-pattern.

And I still did not see any issues arising in big projects of orgs like facebook/jest, angular/angular and others.

And now also yargs/yargs caches them.

They also have hordes of development support at their backs. debug has three people, each of which maintain a laundry list of other packages.

Can you provide real and current reasons not to use any caches on CI (even npm or composer cache) and actual issues of this?

Yes, but I'll leave that as an exercise to the reader - lurk around npm/npm for the slew of issues they had when releasing npm@5 and all of the cache/lock problems people were facing. They lost trust within the node.js community.
Further, whether or not they've caused a slew of errors or not is moot - it breaks the correctness of builds. Period.

Lockfiles are meant to be committed but well, ok.

Yes, and I explained my point above why that's bad design. It's code smell. Lockfiles are a bandaid patch for a deeper failure of the dependency systems in place.

And if a package changes then also the build cache gets invalidated. It will install over loaded cache.

Unless something's changed, that's not true with lockfiles. They bypass hitting the server to shave off HTTP request times. If the package is there, meets the hashing requirements and is within the requested semver range they are considered a cache hit.
Which, again, completely invalidates the "complete" and "correct" points made earlier.


cf curl /v2/users error out

We need some guidance on this error we are experiencing. We created a new org/space as test1/test1 and assigned admin user with all org/space roles, e.g.
$ cf set-org-role admin test1 OrgManager
Assigning role OrgManager to user admin in org test1 as admin...
OK
$ cf set-org-role admin test1 BillingManager
Assigning role BillingManager to user admin in org test1 as admin...
OK
$ cf set-org-role admin test1 OrgAuditor;
Assigning role OrgAuditor to user admin in org test1 as admin...
OK

We even confirmed in the postgres DB
ccdb=> select * from organizations_managers where organization_id = 3;
 organization_id | user_id
-----------------+---------
               3 |       1
(1 row)

ccdb=> select * from organizations_auditors where organization_id = 3;
 organization_id | user_id
-----------------+---------
               3 |       1
(1 row)

ccdb=> select * from organizations_billing_managers where organization_id = 3;
 organization_id | user_id
-----------------+---------
               3 |       1
(1 row)

However, we can not list the users:
$ cf org-users test1
Getting users in org test1 as admin...

ORG MANAGER
FAILED
Failed fetching org-users for role ORG MANAGER.
Server error, status code: 500, error code: 10001, message: An unknown error occurred.

nor I can do
cf curl /v2/users

What I can find in cloud_controller_ng.log
{"timestamp":1441910781.0750287,"message":"(0.001326s) SELECT \"users\".* FROM \"users\" INNER JOIN \"organizations_managers\" ON (\"organizations_managers\".\"user_id\" = \"users\".\"id\") WHERE (\"organizations_managers\".\"organization_id\" = 3) ORDER BY \"id\" ASC LIMIT 50 OFFSET 0","log_level":"debug2","source":"cc.db","data":{"request_guid":"e7980497-acad-45b7-4fbb-5abbf045c8f1::b318e17c-16fe-4527-9bce-920b2aea7da5"},"thread_id":70254554491620,"fiber_id":70254556832220,"process_id":8200,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/logging.rb","lineno":70,"method":"block in log_each"}

Not very useful as far as I can tell.
Any suggestion as where is the root cause is?
Thanks a lot!

From the gorouter's access.log, I can see that
api.<IP_ADDRESS>.xip.io - [10/09/2015:18:44:16 +0000] "PUT /v2/organizations/8bec7b20-7fba-4fd5-b8e7-0704e39a563e/users/c69d73e2-e09e-4967-bdaa-dd5c3b94ad71 HTTP/1.1" 201 0 1296 "-" "go-cli 6.12.2-24abed3 / linux" <IP_ADDRESS>:33639 x_forwarded_for:"<IP_ADDRESS>" vcap_request_id:e98a0362-246d-4411-6130-e7045a845565 response_time:0.035904436 app_id:
api.<IP_ADDRESS>.xip.io - [10/09/2015:18:45:13 +0000] "PUT /v2/organizations/8bec7b20-7fba-4fd5-b8e7-0704e39a563e/users/c69d73e2-e09e-4967-bdaa-dd5c3b94ad71 HTTP/1.1" 201 0 1296 "-" "go-cli 6.12.2-24abed3 / linux" <IP_ADDRESS>:33731 x_forwarded_for:"<IP_ADDRESS>" vcap_request_id:85ae544e-b27c-41e2-4468-1e48e0a973fd response_time:0.034540500 app_id:
api.<IP_ADDRESS>.xip.io - [10/09/2015:18:45:31 +0000] "PUT /v2/organizations/8bec7b20-7fba-4fd5-b8e7-0704e39a563e/users/c69d73e2-e09e-4967-bdaa-dd5c3b94ad71 HTTP/1.1" 201 0 1296 "-" "go-cli 6.12.2-24abed3 / linux" <IP_ADDRESS>:33761 x_forwarded_for:"<IP_ADDRESS>" vcap_request_id:1bf17708-a269-4e30-5303-189549257469 response_time:0.037248098 app_id:
api.<IP_ADDRESS>.xip.io - [10/09/2015:19:00:48 +0000] "GET /v2/users HTTP/1.1" 500 0 99 "-" "go-cli 6.12.2-24abed3 / linux" <IP_ADDRESS>:35161 x_forwarded_for:"<IP_ADDRESS>" vcap_request_id:c69878d0-3bc0-44c6-4420-4a94df9b5525 response_time:0.039884475 app_id:

/v2/users request has a 500 error, but still not sure about the root cause and fix.

From cloud controller node, I can see cloud_controller_ng.log has
{"timestamp":1441921893.8388622,"message":"dispatch VCAP::CloudController::UsersController get /v2/users","log_level":"debug","source":"cc.api","data":{"request_guid":"83881108-a1a0-4aef-6816-7e63b13e0718::657be690-868c-421b-bc66-e962e67ac05d"},"thread_id":70178338039940,"fiber_id":70178337010980,"process_id":8733,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb","lineno":12,"method":"block in define_route"}

and nginx_cc/nginx.access.log has
api.<IP_ADDRESS>.xip.io - [10/Sep/2015:21:51:33 +0000] "GET /v2/users HTTP/1.1" 500 431 "-" "go-cli 6.12.2-24abed3 / linux" <IP_ADDRESS>, <IP_ADDRESS> vcap_request_id:83881108-a1a0-4aef-6816-7e63b13e0718::657be690-868c-421b-bc66-e962e67ac05d response_time:0.039

CC's debug level is set to default debug2. But I can not find any log line that give me any idea as where the problem is.

hi @jianghaitao
there should be more information in your cloud_controller_ng.log.  Can you try searching for unknown error and see if there is a backtrace that is related to your request?
Thanks,
@zrob & @jberkhahn

Hi @jianghaitao,
We haven't heard from you in a while. Going to wait a week, and close the issue if we haven't heard back from you.

Closing due to inactivity.


Beef up services doc a little

Convert examples to v1beta3, flesh out some details, mention L7.

Looks good, thanks Tim; I was reading through this doc just yesterday and appreciate the clarifications.


Integrated Terminal Running the Notebook Accessible in Terminal Panel

Issue
It would be nice to have access to the terminal that is running the jupyter notebook when using the virtual environment approach. An example usecase is that I want to log in to some third party service by executing some shell commands.
Current Approach
My current approach is to start a jupyter server with jupyter lab and then connect to it with the vscode-jupyter feature but I would prefer to use the approach with using a virtual environment directly because the url changes every time i start the local jupyter server.

It would be nice to have access to the terminal that is running the jupyter notebook when using the virtual environment approach

The Jupyter extension doesn't start Jupyter servers 99.9% of the time, its very rare that its starts a server (if thats the case, its only due to some missing dependencies)

example usecase is that I want to log in to some third party service by executing some shell commands.

So, I'm guessing you need to initialize some environment variables, as thats the only thing that will be carried over to the Jupyter Servers (& kernels).
If thats the case, then the solution is to use .env files.
Just create a .env file in your workspace folder and add the necessary environment variables to that and the kernel will have access to those variables.
Or you might want to run some startup commands in the kernel that will ensure you always sign into the 3rd party service as part of the startup of the kernels.
Let me know if either one of these work for you.

Thanks you gave me some good hints.
I see the extension doesn't start Jupyter servers but there must be some child process that executes the specific notebook. And in my opinion it would be nice to have an integrated terminal tab to run commands in that affect this. Because of course I can set the environment variables manually but if there are session related and require authentication it is more effective to automate this approach.

I see the extension doesn't start Jupyter servers but there must be some child process that executes the specific notebook.

The only process is the kernel, and there is no terminal session associated with the process . As we don’t use terminals to start the kernels
The only way to pass env variables to the kernel is to use .env files
given that’s the only solution I can offer I’m closing this issue
Please do try to setup the env variables in the .env file
Also I’m not sure how a terminal session would work either, as that’s not how they work, the env variables setup in a terminal will not be propagated to an already running process (unless you want a terminal before the kernel is started, again that’s not possible as we don’t use terminals )


MTL-2000 Enable zypper cloud-init modules

Summary and Scope

Fixes: MTl-2000

Issue Type

RFE Pull Request

Enables repository setup and package installation from cloud-init, using the zypper and packages cloud-init modules.
This deprecates and disables the package install hack (install_csm_rpms).
This change depends on the following cloud-init user-data existing:

ncn-m001:~ # cray bss bootparameters list --format json --hosts $(cat /etc/cray/xname) | jq '.[]."cloud-init"."user-data".packages'
[
    "cani",
    "canu",
    "cray-cmstools-crayctldeploy",
    "csm-testing",
    "goss-servers",
    "iuf-cli",
    "libcsm",
    "platform-utils"
]

ncn-m001:~ # cray bss bootparameters list --format json --hosts $(cat /etc/cray/xname) | jq '.[]."cloud-init"."user-data".zypper'
{
  "repos": [
    {
      "autorefresh": 1,
      "baseurl": "https://packages.local/repository/csm-noos?ssl_verify=no",
      "enabled": 1,
      "gpgcheck": 1,
      "id": "csm-noos",
      "name": "csm-noos",
      "repo_gpgcheck": 0
    },
    {
      "autorefresh": 1,
      "baseurl": "https://packages.local/repository/csm-sle-${releasever_major}sp${releasever_minor}?ssl_verify=no",
      "enabled": 1,
      "gpgcheck": 1,
      "id": "csm-sle",
      "name": "csm-sle-${releasever_major}sp${releasever_minor}",
      "repo_gpgcheck": 0
    }
  ]
}

The above snippet was confirmed on a csm-1.5.0-beta.64 upgrade, and was confirmed on a CSM 1.5 fresh install at an earlier date.
The Zypper repo information in the snippet was used manually and resulted in successfully adding the repository.
Prerequisites

[ ] I have included documentation in my PR (or it is not required)
[ ] I have tested this by building an image using this branch HEAD, or this is does not pertain to the node-images pipeline.
[ ] I tested this on internal system or this pertains to the node-images pipeline (if yes and not build related, please include results or a description of the test)
[ ] I tested this on a vshasta system or this pertains to the node-images pipeline (if yes and not build related, please include results or a description of the test)

Idempotency

Zypper Module Test
On fanta, after confirming the user-data was available I ran the zypper_add_repo module by itself. This yielded working repositories.
ncn-s001:~ # cray bss bootparameters list --format json --hosts $(cat /etc/cray/xname) | jq '.[]."cloud-init"."user-data".zypper'
{
  "repos": [
    {
      "autorefresh": 1,
      "baseurl": "https://packages.local/repository/csm-noos?ssl_verify=no",
      "enabled": 1,
      "gpgcheck": 1,
      "id": "csm-noos",
      "name": "csm-noos",
      "repo_gpgcheck": 0
    },
    {
      "autorefresh": 1,
      "baseurl": "https://packages.local/repository/csm-sle-${releasever_major}sp${releasever_minor}?ssl_verify=no",
      "enabled": 1,
      "gpgcheck": 1,
      "id": "csm-sle",
      "name": "csm-sle-${releasever_major}sp${releasever_minor}",
      "repo_gpgcheck": 0
    }
  ]
}
ncn-s001:~ # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias         | Name                                         | Enabled | GPG Check | Refresh
--+---------------+----------------------------------------------+---------+-----------+--------
1 | csm-embedded  | CSM Embedded NCN Packages (added by Ansible) | Yes     | ( p) Yes  | Yes
2 | csm-sle-15sp2 | CSM SLE 15 SP2 Packages (added by Ansible)   | Yes     | ( p) Yes  | Yes
3 | csm-sle-15sp3 | CSM SLE 15 SP3 Packages (added by Ansible)   | Yes     | ( p) Yes  | Yes
4 | csm-sle-15sp4 | CSM SLE 15 SP4 Packages (added by Ansible)   | Yes     | ( p) Yes  | Yes

I edited the local cache, merging in what was in BSS. I did this to avoid sprawling my testing.
ncn-s001:~ # vim /var/lib/cloud/instance/cloud-config.txt

Then I added the zypper_add_repo module to cloud.cfg for good measure.
ncn-s001:~ # vim /etc/cloud/cloud.cfg

Finally, I ran the new module standalone.
cloud-init -d single --name zypper_add_repo --frequency always

The cloud-init.log showed the creation of the .repo files:
2023-10-13 16:08:28,129 - helpers.py[DEBUG]: Running config-zypper_add_repo using lock (<cloudinit.helpers.DummyLock object at 0x7fe2b543a390>)
2023-10-13 16:08:28,130 - util.py[DEBUG]: Writing to /etc/zypp/repos.d/csm-noos.repo - wb: [644] 152 bytes
2023-10-13 16:08:28,130 - util.py[DEBUG]: Writing to /etc/zypp/repos.d/csm-sle.repo - wb: [644] 231 bytes

I confirmed Zypper was aware of the new repos, and that they could be refreshed/scanned.
ncn-s001:/var/lib/cloud/instance # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias         | Name                                         | Enabled | GPG Check | Refresh
--+---------------+----------------------------------------------+---------+-----------+--------
1 | csm-embedded  | CSM Embedded NCN Packages (added by Ansible) | Yes     | ( p) Yes  | Yes
2 | csm-noos      | csm-noos                                     | Yes     | ( p) Yes  | Yes
3 | csm-sle       | csm-sle-15sp3                                | Yes     | ( p) Yes  | Yes
4 | csm-sle-15sp2 | CSM SLE 15 SP2 Packages (added by Ansible)   | Yes     | ( p) Yes  | Yes
5 | csm-sle-15sp3 | CSM SLE 15 SP3 Packages (added by Ansible)   | Yes     | ( p) Yes  | Yes
6 | csm-sle-15sp4 | CSM SLE 15 SP4 Packages (added by Ansible)   | Yes     | ( p) Yes  | Yes
ncn-s001:/var/lib/cloud/instance # zypper ref
Retrieving repository 'CSM Embedded NCN Packages (added by Ansible)' metadata ......................................................................................................................................................................................................[done]
Building repository 'CSM Embedded NCN Packages (added by Ansible)' cache ...........................................................................................................................................................................................................[done]
Retrieving repository 'csm-noos' metadata ..........................................................................................................................................................................................................................................[done]
Building repository 'csm-noos' cache ...............................................................................................................................................................................................................................................[done]
Retrieving repository 'csm-sle-15sp3' metadata .....................................................................................................................................................................................................................................[done]
Building repository 'csm-sle-15sp3' cache ..........................................................................................................................................................................................................................................[done]
Retrieving repository 'CSM SLE 15 SP2 Packages (added by Ansible)' metadata ........................................................................................................................................................................................................[done]
Building repository 'CSM SLE 15 SP2 Packages (added by Ansible)' cache .............................................................................................................................................................................................................[done]
Retrieving repository 'CSM SLE 15 SP3 Packages (added by Ansible)' metadata ........................................................................................................................................................................................................[done]
Building repository 'CSM SLE 15 SP3 Packages (added by Ansible)' cache .............................................................................................................................................................................................................[done]
Retrieving repository 'CSM SLE 15 SP4 Packages (added by Ansible)' metadata ........................................................................................................................................................................................................[done]
Building repository 'CSM SLE 15 SP4 Packages (added by Ansible)' cache .............................................................................................................................................................................................................[done]
All repositories have been refreshed.

Lastly, the .repo files looked as I expected them to.
ncn-s001:/var/lib/cloud/instance # cat /etc/zypp/repos.d/csm-noos.repo
[csm-noos]
autorefresh = 1
baseurl = https://packages.local/repository/csm-noos?ssl_verify=no
enabled = 1
gpgcheck = 1
name = csm-noos
repo_gpgcheck = 0ncn-s001:/var/lib/cloud/instance # cat /etc/zypp/repos.d/csm-
csm-embedded.repo   csm-noos.repo       csm-sle-15sp2.repo  csm-sle-15sp3.repo  csm-sle-15sp4.repo  csm-sle.repo
ncn-s001:/var/lib/cloud/instance # cat /etc/zypp/repos.d/csm-sle.repo
[csm-sle]
autorefresh = 1
baseurl = https://packages.local/repository/csm-sle-${releasever_major}sp${releasever_minor}?ssl_verify=no
enabled = 1
gpgcheck = 1
name = csm-sle-${releasever_major}sp${releasever_minor}
repo_gpgcheck = 0ncn-s001:/var/lib/cloud/instance #

Package Module Test
ncn-s001:~ # cloud-init -d single --name package_update_upgrade_install --frequency always
... // truncated to relevant portion by Russell Bunch
2023-10-13 16:23:44,442 - main.py[DEBUG]: Logging being reset, this logger may no longer be active shortly
Cloud-init v. 21.4-1 running 'single' at Fri, 13 Oct 2023 16:23:44 +0000. Up 123723.14 seconds.
Repository 'CSM Embedded NCN Packages (added by Ansible)' is up to date.
Repository 'csm-noos' is up to date.
Repository 'csm-sle-15sp3' is up to date.
Repository 'CSM SLE 15 SP2 Packages (added by Ansible)' is up to date.
Repository 'CSM SLE 15 SP3 Packages (added by Ansible)' is up to date.
Repository 'CSM SLE 15 SP4 Packages (added by Ansible)' is up to date.
All repositories have been refreshed.
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 6 packages are going to be upgraded:
  canu cray-cmstools-crayctldeploy csm-testing goss-servers iuf-cli platform-utils

The following 2 NEW packages are going to be installed:
  cani libcsm

The following 8 packages have no support information from their vendor:
  cani canu cray-cmstools-crayctldeploy csm-testing goss-servers iuf-cli libcsm platform-utils

6 packages to upgrade, 2 new.
Overall download size: 130.8 MiB. Already cached: 0 B. After the operation, additional 127.5 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving package cani-0.3.0-1.x86_64 (1/8),   6.5 MiB ( 14.6 MiB unpacked)
Retrieving: cani-0.3.0-1.x86_64.rpm [done]
Retrieving package canu-1.7.6-1.x86_64 (2/8),  87.0 MiB ( 88.9 MiB unpacked)
Retrieving: canu-1.7.6-1.x86_64.rpm [.done (66.9 MiB/s)]
Retrieving package cray-cmstools-crayctldeploy-1.14.1-1.x86_64 (3/8),  15.1 MiB ( 40.9 MiB unpacked)
Retrieving: cray-cmstools-crayctldeploy-1.14.1-1.x86_64.rpm [done]
Retrieving package csm-testing-1.16.59-1.noarch (4/8), 155.0 KiB (  1.1 MiB unpacked)
Retrieving: csm-testing-1.16.59-1.noarch.rpm [done]
Retrieving package goss-servers-1.16.59-1.noarch (5/8),  12.4 KiB (  6.1 KiB unpacked)
Retrieving: goss-servers-1.16.59-1.noarch.rpm [done]
Retrieving package iuf-cli-1.5.6-1.x86_64 (6/8),  11.4 MiB ( 11.7 MiB unpacked)
Retrieving: iuf-cli-1.5.6-1.x86_64.rpm [done]
Retrieving package platform-utils-1.6.7-1.noarch (7/8),  24.0 KiB ( 64.0 KiB unpacked)
Retrieving: platform-utils-1.6.7-1.noarch.rpm [done]
Retrieving package libcsm-0.0.5-1.noarch (8/8),  10.5 MiB (111.4 MiB unpacked)
Retrieving: libcsm-0.0.5-1.noarch.rpm [done]

Checking for file conflicts: [......done]
(1/8) Installing: cani-0.3.0-1.x86_64 [............done]
(2/8) Installing: canu-1.7.6-1.x86_64 [...............done]
(3/8) Installing: cray-cmstools-crayctldeploy-1.14.1-1.x86_64 [.............done]
(4/8) Installing: csm-testing-1.16.59-1.noarch [...................done]
(5/8) Installing: goss-servers-1.16.59-1.noarch [........done]
(6/8) Installing: iuf-cli-1.5.6-1.x86_64 [............done]
(7/8) Installing: platform-utils-1.6.7-1.noarch [...............done]
(8/8) Installing: libcsm-0.0.5-1.noarch [............done]
There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs.

ncn-s001:~ #

Risks and Mitigations

This ceases calling the install_csm_scripts function, but leaves the function in place with a deprecation notice in case it is needed as a workaround.

/backport main


2018.3 compatibility fixes only

this was already approved and merged into the RC, right?

Yes - I merged the results into RC2, and this PR is to merge the changes from RC2 into dev.


CLOUDSTACK-8443: Support CentOS 7 for 4.5

This is based on two PRs:

731
757

This commit is based on the 4.5 branch for a future 4.5 release.

LGTM - Built agent RPMs for CentOS 7 from this PR branch and installed those on the KVM hypervisors. Run the management server also from this branch and was able to add a CentOS 7 host both through Marvin and UI without manual intervention. Just like you can do on master.
Thanks for back porting to 4.5 @wido !

@bhaisaab Could you look into this? If this gets a LGTM we might want to spin out 4.5.3 shortly with proper CentOS 7 support.
A short e-mail to the dev@ list might attract more small hotfixes we might want to put in 4.5.3

@wido: thanks, LGTM. Sure, I think for now we should be focusing on master/4.6 and meanwhile keep fixing/merging any 4.5.x issues and perhaps attempt to do a 4.5.3 release later in October or early November.


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v2.6.27 to before v4.4.298",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=61a7e26028b94805fd686a6dc9dbd9941f8f19b0",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=15579e1301f856ad9385d720c9267c11032a5022"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "61a7e26028b94805fd686a6dc9dbd9941f8f19b0",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "15579e1301f856ad9385d720c9267c11032a5022",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "net: fix use-after-free in tw_timer_handler\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v4.4.298 by commit 15579e1301f856ad9385d720c9267c11032a5022, it was introduced in version v2.6.27 by commit 61a7e26028b94805fd686a6dc9dbd9941f8f19b0. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2022-1000009


setItems notification of changes

I've realized that the setItems of the adapters is just replacing the already items list without doing any notification (added-removed-updated).
Maybe a DiffUtils (https://developer.android.com/reference/android/support/v7/util/DiffUtil.html) could be used to just know what changed and allow the adapter to launch visual animations.
This is needed when using HeaderHelper for example, as the only way to rearrange the data is by using the setitems that would redraw the entire adapter.

@gpulido you can use the DiffUtil but it depends on your item, and is something the FastAdapter shouldn't depend on. You can try the DiffUtilHelper or how I called that class from the extensions.
The set does by the way notifications, but only on section basis and not on per item basis.
https://github.com/mikepenz/FastAdapter/blob/develop/library-core/src/main/java/com/mikepenz/fastadapter/adapters/ItemAdapter.java#L257


Loosen kubeclient to >=2.4 <3.0

The goal is picking up kubeclient 2.5.2.  This PR can be merged alone, but kubeclient version won't change until https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/232 and https://github.com/ManageIQ/manageiq-providers-kubevirt/pull/26 land.
This brings 2 fixes we need:

Prevent EBADF exception escaping when closing a watch worker
https://bugzilla.redhat.com/show_bug.cgi?id=1507528
Watch return RecursiveOpenStruct inside arrays too.
We were already effectively running the new code via a monkey patch, better to run the new code from kubeclient.

See https://github.com/abonas/kubeclient/blob/master/CHANGELOG.md for full changelog.
@miq-bot add-label bug, gaprindashvili/yes
(On master, we'll later upgrade to kubeclient 3.0.0, need to resolve a version conflict first.  On gaprindashvili, we'll stay with 2.5.)
@pkliczewski @masayag @jhernand please review.

Travis can't pass, testing locally:

[ ] core running...
[x] kubernetes repo passed locally
[x] openshift repo passed locally
[x] kubevirt repo passed locally

@cben if you loosen the dependency for now, (~>2.4) then this should go green and we can merge it.
Then the provider repos should also be able to go green.
After we get the initial PRs in then we can come back and bump the minimum. What do you think?
p.s.
I would really like to get to version 3 for the cascading delete feature.

@carbonin I loosened it for you :-)
This is now green, but that's a meaningless test as it's still testing 2.4! When the last PRs land, we'll get 2.5 but core will not be re-tested then.
What we need is a test of core against these PRs together:
https://travis-ci.org/cben/manageiq/builds/347042754
(using a tool I'm working on, stay tuned...).
Hmm, I see failures there :-(  Will investigate when I'm back from PTO.
This PR is still safe to merge as it doesn't change anything.  I'll make sure all repos are good, both locally and on travis, before proceeding with actual bump.

Agree @cben but I think given the minimal usage the gem gets in the core repo, it's safe to have a loose dependency if it makes upgrades easier.
And on that note, based on the changelog, I think upgrading to 3.0 should be safe from core's perspective, but we will want to change our exception handling and also utilize the dependent delete features.

Gaprindashvili backport details:
$ git log -1
commit 932e5b7e00e90c16f506a2c089f2c4223d6c1db3
Author: Nick Carboni<EMAIL_ADDRESS>Date:   Wed Feb 28 10:17:09 2018 -0500

    Merge pull request #16957 from cben/kubeclient-2.5

    Loosen kubeclient to >=2.4 <3.0
    (cherry picked from commit 8d1899fb8b8c06e960e4519c551dd9dc8789444e)

    https://bugzilla.redhat.com/show_bug.cgi?id=1558025


fix: update to eye v3.15.2

fix: update to eye v3.15.2

:tada: This PR is included in version 4.14.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v4.14.1

Your semantic-release bot :package::rocket:


Error fetch database when CSV added to doltlab instance via command-line

Hi. Thanks for your work on Doltlab, which I've been experimenting with.
I hit an issue when testing the import of a relatively small CSV file (307 rows, 12 columns) to doltlab. I'm on version 0.7 (having upgraded from 0.6 ... ie. docker volumes date back to v. 0.6).
I ran:
dolt table import -c --pk=id test_table ~/dev/rstudio/test_table.csv

... and got acknowledgement that the import worked.  However, back on the doltlab UI, I was getting this "error fetching database"

If I access the database from the command-line, it seems it has imported OK.  I tried to run a revert on the commit (select dolt_revert('<commit-id>) ... which succeeded ... to see if that might fix things, but to no avail.
STATUS                 PORTS
                                                                           NAMES
af95adf0833b   public.ecr.aws/dolthub/doltlab/dolthub-server:v0.7.0              "docker-entrypoint.s…"   2 weeks ago   Up 36 minutes          3000/tcp
                                                                           doltlab_doltlabui_1
96838ffea2ce   public.ecr.aws/dolthub/doltlab/dolthubapi-graphql-server:v0.7.0   "docker-entrypoint.s…"   2 weeks ago   Up 36 minutes          9000/tcp
                                                                           doltlab_doltlabgraphql_1
3eb3b04dc08c   public.ecr.aws/dolthub/doltlab/dolthubapi-server:v0.7.0           "/app/go/services/do…"   2 weeks ago   Up 36 minutes
                                                                           doltlab_doltlabapi_1
c2ae0f01be23   public.ecr.aws/dolthub/doltlab/doltremoteapi-server:v0.7.0        "/app/go/services/do…"   2 weeks ago   Up 36 minutes          <IP_ADDRESS>:50051->50051/tcp, :::50051->50051/tcp
                                                                           doltlab_doltlabremoteapi_1
e7abe2ace69c   public.ecr.aws/dolthub/doltlab/fileserviceapi-server:v0.7.0       "/app/go/services/fi…"   2 weeks ago   Up 36 minutes
                                                                           doltlab_doltlabfileserviceapi_1
dc748eb44b0e   envoyproxy/envoy-alpine:v1.18-latest                              "/docker-entrypoint.…"   2 weeks ago   Up 36 minutes          <IP_ADDRESS>:80->80/tcp, :::80->80/tcp, <IP_ADDRESS>:100->100/tcp, :::100->100/tcp, <IP_ADDRESS>:4321->4321/tcp, :::4321->4321/tcp, <IP_ADDRESS>:7770->7770/tcp, :::7770->7770/tcp, 10000/tcp   doltlab_doltlabenvoy_1
a0f592db2f1a   public.ecr.aws/dolthub/doltlab/postgres-server:v0.7.0             "docker-entrypoint.s…"   2 weeks ago   Up 36 minutes          5432/tcp
                                                                           doltlab_doltlabdb_1

I notice on inspecting doltlab_doltlabfileserviceapi_1 and see it complaining about not being able to access doltlabenvoy:9480.  On inspecting the docker-compose in 0.7 it seems there is no port 9480 being exposed.  ~/dev/doltlab$ cat docker-compose.yaml | grep 9480.  Could that be the source of my problem?
docker logs doltlab_doltlabfileserviceapi_1
2022-11-12T10:27:50.887Z        INFO    server/main.go:132      server is shutting down
2022-11-12T10:27:51.198Z        INFO    server/main.go:151      Server stopped.
2022-11-12T10:28:04.539Z        INFO    zap/grpclogger.go:73    [core][Channel #3] Channel created      {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.540Z        INFO    zap/grpclogger.go:73    [core][Channel #3] original dial target is: "doltlabenvoy:9480" {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.540Z        INFO    zap/grpclogger.go:73    [core][Channel #3] parsed dial target is: {Scheme:doltlabenvoy Authority: Endpoint:9480 URL:{Scheme:doltlabenvoy Opaque:9480 User: Host: Path: RawPath: OmitHost:false ForceQuery:false RawQuery: Fragment: RawFragment:}}      {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.540Z        INFO    zap/grpclogger.go:73    [core][Channel #3] fallback to scheme "passthrough"    {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.540Z        INFO    zap/grpclogger.go:73    [core][Channel #3] parsed dial target is: {Scheme:passthrough Authority: Endpoint:doltlabenvoy:9480 URL:{Scheme:passthrough Opaque: User: Host: Path:/doltlabenvoy:9480 RawPath: OmitHost:false ForceQuery:false RawQuery: Fragment: RawFragment:}}     {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.541Z        INFO    zap/grpclogger.go:73    [core][Channel #3] Channel authority set to "dolthubapi{"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.541Z        INFO    zap/grpclogger.go:73    [core][Channel #3] Resolver state updated: {
  "Addresses": [
    {
      "Addr": "doltlabenvoy:9480",
      "ServerName": "",
      "Attributes": null,
      "BalancerAttributes": null,
      "Type": 0,
      "Metadata": null
    }
  ],
  "ServiceConfig": null,
  "Attributes": null
} (resolver returned new addresses)     {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.541Z        INFO    zap/grpclogger.go:73    [core][Channel #3] Channel switches to new LB policy "pick_first"       {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.541Z        INFO    zap/grpclogger.go:73    [core][Channel #3 SubChannel #4] Subchannel created    {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.546Z        INFO    zap/grpclogger.go:73    [core][Channel #1 SubChannel #2] Subchannel Connectivity change to CONNECTING   {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.546Z        INFO    zap/grpclogger.go:73    [core][Channel #1 SubChannel #2] Subchannel picks a new address "doltlabenvoy:9480" to connect  {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.562Z        INFO    zap/grpclogger.go:73    [core][Channel #3 SubChannel #4] Subchannel Connectivity change to CONNECTING   {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.562Z        INFO    zap/grpclogger.go:73    [core][Channel #3 SubChannel #4] Subchannel picks a new address "doltlabenvoy:9480" to connect  {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.562Z        INFO    zap/grpclogger.go:73    [core]pickfirstBalancer: UpdateSubConnState: 0xc0003fa670, {CONNECTING <nil>}   {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.562Z        INFO    zap/grpclogger.go:73    [core][Channel #3] Channel Connectivity change to CONNECTING    {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.562Z        INFO    server/main.go:144      Serving fileserviceapi server.  {"addr": ":60055"}
2022-11-12T10:28:04.562Z        INFO    zap/grpclogger.go:73    [core]pickfirstBalancer: UpdateSubConnState: 0xc0003ec390, {CONNECTING <nil>}   {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:04.562Z        INFO    zap/grpclogger.go:73    [core][Channel #1] Channel Connectivity change to CONNECTING    {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:06.593Z        WARN    zap/grpclogger.go:85    [core][Channel #1 SubChannel #2] grpc: addrConn.createTransport failed to connect to {
  "Addr": "doltlabenvoy:9480",
  "ServerName": "eventsapi",
  "Attributes": null,
  "BalancerAttributes": null,
  "Type": 0,
  "Metadata": null
}. Err: connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:9480: connect: connection refused"{"system": "grpc", "grpc_log": true}
github.com/grpc-ecosystem/go-grpc-middleware/logging/zap.(*zapGrpcLoggerV2).Warningln
        external/com_github_grpc_ecosystem_go_grpc_middleware/logging/zap/grpclogger.go:85
google.golang.org/grpc/internal/grpclog.WarningDepth
        external/org_golang_google_grpc/internal/grpclog/grpclog.go:46
google.golang.org/grpc/grpclog.(*componentData).WarningDepth
        external/org_golang_google_grpc/grpclog/component.go:41
google.golang.org/grpc/internal/channelz.AddTraceEvent
        external/org_golang_google_grpc/internal/channelz/funcs.go:342
google.golang.org/grpc/internal/channelz.Warningf
        external/org_golang_google_grpc/internal/channelz/logging.go:59
google.golang.org/grpc.(*addrConn).createTransport
        external/org_golang_google_grpc/clientconn.go:1278
google.golang.org/grpc.(*addrConn).tryAllAddrs
        external/org_golang_google_grpc/clientconn.go:1213
google.golang.org/grpc.(*addrConn).resetTransport
        external/org_golang_google_grpc/clientconn.go:1148
google.golang.org/grpc.(*addrConn).connect
        external/org_golang_google_grpc/clientconn.go:803
2022-11-12T10:28:06.594Z        INFO    zap/grpclogger.go:73    [core][Channel #1 SubChannel #2] Subchannel Connectivity change to TRANSIENT_FAILURE    {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:06.595Z        INFO    zap/grpclogger.go:73    [core]pickfirstBalancer: UpdateSubConnState: 0xc0003ec390, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:9480: connect: connection refused"}  {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:06.595Z        INFO    zap/grpclogger.go:73    [core][Channel #1] Channel Connectivity change to TRANSIENT_FAILURE     {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:06.595Z        WARN    zap/grpclogger.go:85    [core][Channel #3 SubChannel #4] grpc: addrConn.createTransport failed to connect to {
  "Addr": "doltlabenvoy:9480",
  "ServerName": "dolthubapi",
  "Attributes": null,
  "BalancerAttributes": null,
  "Type": 0,
  "Metadata": null
}. Err: connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:9480: connect: connection refused"{"system": "grpc", "grpc_log": true}
github.com/grpc-ecosystem/go-grpc-middleware/logging/zap.(*zapGrpcLoggerV2).Warningln
        external/com_github_grpc_ecosystem_go_grpc_middleware/logging/zap/grpclogger.go:85
google.golang.org/grpc/internal/grpclog.WarningDepth
        external/org_golang_google_grpc/internal/grpclog/grpclog.go:46
google.golang.org/grpc/grpclog.(*componentData).WarningDepth
        external/org_golang_google_grpc/grpclog/component.go:41
google.golang.org/grpc/internal/channelz.AddTraceEvent
        external/org_golang_google_grpc/internal/channelz/funcs.go:342
google.golang.org/grpc/internal/channelz.Warningf
        external/org_golang_google_grpc/internal/channelz/logging.go:59
google.golang.org/grpc.(*addrConn).createTransport
        external/org_golang_google_grpc/clientconn.go:1278
google.golang.org/grpc.(*addrConn).tryAllAddrs
        external/org_golang_google_grpc/clientconn.go:1213
google.golang.org/grpc.(*addrConn).resetTransport
        external/org_golang_google_grpc/clientconn.go:1148
google.golang.org/grpc.(*addrConn).connect
        external/org_golang_google_grpc/clientconn.go:803
2022-11-12T10:28:06.595Z        INFO    zap/grpclogger.go:73    [core][Channel #3 SubChannel #4] Subchannel Connectivity change to TRANSIENT_FAILURE    {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:06.596Z        INFO    zap/grpclogger.go:73    [core]pickfirstBalancer: UpdateSubConnState: 0xc0003fa670, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:9480: connect: connection refused"}  {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:06.596Z        INFO    zap/grpclogger.go:73    [core][Channel #3] Channel Connectivity change to TRANSIENT_FAILURE     {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:07.595Z        INFO    zap/grpclogger.go:73    [core][Channel #1 SubChannel #2] Subchannel Connectivity change to IDLE {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:07.595Z        INFO    zap/grpclogger.go:73    [core]pickfirstBalancer: UpdateSubConnState: 0xc0003ec390, {IDLE connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:9480: connect: connection refused"}       {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:07.595Z        INFO    zap/grpclogger.go:73    [core][Channel #1] Channel Connectivity change to IDLE {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:07.597Z        INFO    zap/grpclogger.go:73    [core][Channel #3 SubChannel #4] Subchannel Connectivity change to IDLE {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:07.597Z        INFO    zap/grpclogger.go:73    [core]pickfirstBalancer: UpdateSubConnState: 0xc0003fa670, {IDLE connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:9480: connect: connection refused"}       {"system": "grpc", "grpc_log": true}
2022-11-12T10:28:07.597Z        INFO    zap/grpclogger.go:73    [core][Channel #3] Channel Connectivity change to IDLE {"system": "grpc", "grpc_log": true}

Hey @Analect, thanks for the issue!
So the doltlabfileserviceapi should be able to connect to doltlabenvoy:9480, but the port isn't listed in the docker-compose.yaml, it's in the envoy.yaml as outbound_grpc_listener. The services also use this port for outbound communication by default.
It's strange that you're seeing these connection failures. You can try an attempt to reach that endpoint with:
docker run -it --rm --network doltlab curlimages/curl:latest http://doltlabenvoy:9480

Then in the logs of doltlabenvoy, you should see something like:
[2022-11-12T14:05:30.647Z] "GET / HTTP/1.1" 404 Unimplemented NR 0 0 0 - "xxx.xxx.xxx.x" "curl/7.86.0-DEV" "02817954-6781-448e-b07c-4c1620f579c2" "doltlabenvoy:9480" "-" "-"

which would indicate the port is reachable inside the doltlab network, meaning doltlabfileserviceapi should be able to reach it as well.
Can you also try stopping DoltLab, removing all of the containers and the docker network (do not remove the docker volumes), then restarting it with the ./start-doltlab.sh script? If there are non-precious docker images/containers on the doltlab host you can do this with docker system prune -a.
I'm gonna follow up with you in Discord with some requests as well.

@coffeegoddd ... thanks. I was able to stop, rm and prune v0.7.0 setup and upgrade to v0.7.1 and the problems described above appear to have been resolved.  The only thing I noticed when pruning was that two docker networks existed (see below).  When I previously upgraded from v0.6 of DoltLab to v0.7, while I stopped and removed the containers of the old, I didn't prune images/networks. It could have been that the ./start-doltlab.sh might have created a new network doltlab_doltlab, if doltlab pre-existed ... eventhough I see in your docs that it shouldn't try to recreate a new one if one already exists.  That's the only explanation I have for the two networks being there.
doltlab
doltlab_doltlab


livenessProbe in kube-dashboard is configurable

Adds configurable livenessProbe.initialDelaySeconds and
livenessProbe.timeoutSeconds

Signed-off-by: Lyle Franklin<EMAIL_ADDRESS>What this PR does / why we need it:
The k8s Dashboard takes over a minute to startup on a Raspberry Pi k8s cluster.
My understanding is that the hardcoded 30 livenessProbe delay is restarting the pod before the startup can complete.
This PR makes livenessProbe.initialDelaySeconds and livenessProbe.timeoutSeconds configurable.
Which issue this PR fixes
N/A
Special notes for your reviewer:
N/A
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/ok-to-test

/lgtm

@davidkarlsen updated version number as suggested above

/lgtm


Syntax highlighting issue with java

Using Wordpress prism plugin I get TypeError:
TypeError: pattern.exec is not a function
var match = pattern.exec(str);
The code in not properly highlighted and line numbers don't show up.
In my wordpress post I put:
[prism field=WebMvcConfig language=java class=line-numbers data_line=3]

I think this can be closed now since #360 is merged.
@dkanicki can you confirm this is fixed?

I consider this fixed.


redmatrix.me server not found

The main redmatrix.me website is not responding.
Relatedly, is this project being actively maintained?

Nevermind, found Hubzilla. However, it might be good to link to Hubzilla in the project description at the top of the GitHub profile :-)


[error-reporting] Support httpRequest and user context

It is currently not possible to provide httpRequest or user context without extending the Boostrap class.
Could we have an option to provide those at initialization or using a callback? Perhaps a default implementation for httpRequest could be included with variables from $_SERVER.
Source: https://cloud.google.com/error-reporting/docs/formatting-error-messages#json_representation

archive.zip

I'm also interested in such feature.


Investigate RetryPolicy#recovering API

RetryPolicy#recovering is a bit weird in that the Count for each error is across all errors. For instance, if we have A mapped to 2.times and B mapped to 1.time and the action fails with A twice and then with B, one might expect it to be retried one more time since B is mapped to 1.time, but the current behavior shows that in total we've already tried 2 times which is greater than 1, and it stops.
Bit of code responsible is here, specifically the handler(e) > n bit.

Some code:
import rebind._
import rebind.Rebind._

import scala.concurrent.duration._

import scalaz.DisjunctionT
import scalaz.effect.{ IO, SafeApp }

object Example extends SafeApp {
  sealed abstract class UhOh
  final case object A extends UhOh
  final case object B extends UhOh

  private var count = 0 // yeah i know
  def ew: DisjunctionT[IO, UhOh, Unit] =
    DisjunctionT.right(IO.putStrLn("Running action")).flatMap { _ =>
      if (count < 2) DisjunctionT.left(IO { count += 1; println(" A"); A }) // fail with A first 2 times
      else DisjunctionT.left(IO { count += 1; println(" B"); B }) // afterwards fail with B
    }

  override def runc: IO[Unit] = {
    val policy = exponentialBackoff(1.second) && limitRetries(3)

    policy.recovering(ew) {
      case A => 2.time
      case B => 1.time
    }.run.flatMap(_.fold(_ => IO.putStrLn("Ended with error"), _ => IO.putStrLn("Ended with success")))
  }
}

Output is:
Running action A
Running action A // result of first retry for error A - total retries = 1
Running action B // result of second retry for error A - total retries = 2
Ended with error

Computation stops because total retries = 2 < 1 (B's), but maybe should've retried again because we haven't retried on B yet.

cc me

https://github.com/adelbertc/rebind/issues/6 may be able to rectify this


exclude jasmine stack traces on windows

@facebook-github-bot shipit

thank you!

Thanks for importing. If you are an FB employee go to Phabricator to review.

@facebook-github-bot shipit

Thanks for importing. If you are an FB employee go to Phabricator to review.


Add support for canonical k8s

This PR adds an input use-canonical-k8s to the integration-test workflow to allow deploying juju applications on canonical-k8s.
For now, this parameter must be used in conjuction with provider: k8s so that action-operator bootstraps canonical-k8s as a generic cluster when creating the juju controller.
action-operator will add support for canonical-k8s in the future. Until then, this will be used as a workaround since it's needed to test workflows running on canonical-k8s.
Checklist

[x] The contributing guide was applied
[x] The PR is tagged with appropriate label (urgent, trivial, complex)

@Thanhphan1147 what is the status here, please?


Issue 12: Extract assert_executes into its own assertions file

Resolves https://github.com/apsislabs/slayer/issues/12

Can you address the Hound style issues? I don't agree with all of them, but we should start updating the .rubocop.yml file with relevant changes, if we don't want to keep getting the comments.

@ncallaway Note that I have a branch which addresses some of the rubocop changes.

Rubocop fixes have been moved to a separate branch. This will be moved on top of that branch.


Funimation login is broken

Since November 10th, login on Funimation page is broken.
Once it's fixed, adjust code again to try logins.
For now, login is not used.

Reverted the change. For the situations where it works, it continues to work, but it's no longer tested by automated testing. That's because the automated testing bot behind a VPN (for consistency) is not allowed to login whatsoever. Therefore issues with Funimation logins will rely on user submitted issues. Please open a ticket if Funimation login doesn't work anymore.


Images are not working?

Could you be more specifik in what parameters I have to tweak? Setting type to image and passing an url to a svg is not cutting it ...

Make sure you change the shape mode to image, in index.js
"shape": {
      "type": "image",
},

This does not seem to work with correctly with some .svg files

Not sure if recent development or coincidence, same problem as Eric. PNGs work fine, but not SVGs.

Its possible to increase the image size?

@BrunoSoclick you can edit the size on line 39 of package.json

I have tried png, svg, even jpeg but nothing is working for me

This repository is abandoned, try here https://github.com/matteobruni/tsparticles


Create command line flag

Instead of asking the user to open the django shell you can create command line flags which allows the user to do
python manage.py run db-migrator

keep up the good work 🍻

Good suggestion. I will definitely look into it. 👍


accounting: custom reporting categories

The current accounting report splits transactions into lightning-relevant categories (channels, circular payments etc).
This reporting system would be more extensible if we allowed creation of custom categories based on user-set label:category combinations.
For example, if a node performs loop-out swaps, they could label their on-chain sweeps with "swap" and run the accounting report with "swap":"lightning-loop" to produce a new reporting category which places all the labelled on chain swap sweeps lightning-loop category.

The label of an on chain transaction
The memo for an invoice
Off chain payments don't currently have labeling functions, would likely need lnd changes

This label could also be a regex, to allow more complex matching.

Custom reporting implemented with the exception of forwards and off-chain payments (where lnd has no labelling).


[Doc] Add ENABLE_WRITE_HIVE_EXTERNAL_TABLE to Hive catalog and System variable docs

… variable docs
Signed-off-by: amber-create<EMAIL_ADDRESS>Why I'm doing:
What I'm doing: Add ENABLE_WRITE_HIVE_EXTERNAL_TABLE related info to Hive catalog and System variable docs; Add drop table support info to Hive catalog doc.
Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

@mergify backport branch-3.2


fix A B pin mix up

Hi @MiczFlor, @Yordan1976 and @dvalob noted that I confused A and B pins of the rotary encoder in the code.
I fixed that now in code and documentation in a way that the pin out stays the same and no current installations are broken. Verified on my hardware.

Hi @martinclausen2
I read the thread with @Yordan1976 and @dvalob. I didn't chip in - what do I know about rotary dials :) (other than having a box of three sitting on my desk and waiting for the time to whip out my soldering iron)
I will merge this with develop and push it to master with the next changes.
Thanks to you guys for sorting this out all by yourself. Experts helping each other.

In a schematic you do not use the physical location of the pins. The proposed changes cannot be made, because a and b have fixed meanings, esstially that change would make all users of standard encoders connect their pin incorrectly. If you like you can swap the lines without altering them.
Am 15. März 2019 16:02:18 MEZ schrieb dvalob<EMAIL_ADDRESS>
dvalob commented on this pull request.
It is a pity to have a diagram that does not fit anymore the HW with
the change you propose (CLK is the top pin, DT the second in the
KY-040). You could simply Call CLK = B and DT =A, and then exchange
pins 5 and 6 on the right of the image?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/MiczFlor/RPi-Jukebox-RFID/pull/509#pullrequestreview-215083919

OK OK, just a proposal no worries ;)


Specific sender restriction (authOrig) not synced

After checking the results of my first sync batch  I noticed that there may be a bug.
We have distribution lists where sending mails should only permitted for specific users. This is stored in the authOrig attribute on premise. The script seems to read this information correctly. In originalDLConfigurationADXML.xml I can see:
    <Obj N="authOrig" RefId="1">
        <TN RefId="1">
          <T>Microsoft.ActiveDirectory.Management.ADPropertyValueCollection</T>
          <T>System.Collections.CollectionBase</T>
          <T>System.Object</T>
        </TN>
        <LST>
          <S>CN=Some User1,OU=Normal,OU=Users,DC=ad,DC=company,DC=com</S>
          <S>CN=Some User2,OU=Normal,OU=Users,DC=ad,DC=company,DC=com</S>
          <S>CN=Some User3,OU=Normal,OU=Users,DC=ad,DC=company,DC=com</S>
         </LST>
      </Obj>

After migration to the cloud this setting is lost. Anybody is allowed to send to the group.
I went a little bit through the source code. Could this be the area that leads to the error?
File: DLConversionV2.psm1
    Out-LogFile -string "Invoke get-NormalizedDN to normalize the accept members DN to Office 365 identifier."

    Out-LogFile -string "ACCEPT USERS"

    if ($originalDLConfiguration.($onPremADAttributes.onPremRejectMessagesFromDLMembers.value) -ne $NULL)
    {
        foreach ($DN in $originalDLConfiguration.($onPremADAttributes.onPremAcceptMessagesFromSenders.value))
        {
            if ($forLoopCounter -eq $forLoopTrigger)
            {
                start-sleepProgress -sleepString "Throttling for 5 seconds..." -sleepSeconds 5

Should it be instead like this?
   if ($originalDLConfiguration.($onPremADAttributes.onPremAcceptMessagesFromSenders.value) -ne $NULL)

Can you send me the full log.  Dlconversionv2 @ service  dot Microsoft dot com
==============================
Timothy J. McMichael
Senior Support Escalation Engineer
<EMAIL_ADDRESS>(980)-776-7465
Hours:  Sunday – Wednesday 08:00 – 16:00 eastern time zone.
Manager:  Tom Roughley<EMAIL_ADDRESS>Premier Support -<PHONE_NUMBER>
Broad Commercial Support -<PHONE_NUMBER>
==============================

From: TPok1707 @.>
Sent: Thursday, February 2, 2023 4:40 PM
To: timmcmic/DLConversionV2 @.>
Cc: Subscribed @.***>
Subject: [timmcmic/DLConversionV2] Specific sender restriction (authOrig) not synced (Issue #108)
After checking the results of my first sync batch I noticed that there may be a bug.
We have distribution lists where sending mails should only permitted for specific users. This is stored in the authOrig attribute on premise. The script seems to read this information correctly. In originalDLConfigurationADXML.xml I can see:
  Microsoft.ActiveDirectory.Management.ADPropertyValueCollection System.Collections.CollectionBase System.Object   CN=Some User1,OU=Normal,OU=Users,DC=ad,DC=company,DC=com CN=Some User2,OU=Normal,OU=Users,DC=ad,DC=company,DC=com CN=Some User3,OU=Normal,OU=Users,DC=ad,DC=company,DC=com
After migration to the cloud this setting is lost. Anybody is allowed to send to the group.
I could not find any log entry about this indicating that this setting is processed somehow.
—
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftimmcmic%2FDLConversionV2%2Fissues%2F108&data=05|01|timmcmic%40microsoft.com|fd004d8e0f064499144608db05660c66|72f988bf86f141af91ab2d7cd011db47|1|0|638109708087998776|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=ObyQsfbAD0ZzjhtLtpvvUabrfKUI5%2FsnY98BIAxGmYk%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKGTN6IJTRJKJRFAWFPJNETWVQSTLANCNFSM6AAAAAAUPRILJA&data=05|01|timmcmic%40microsoft.com|fd004d8e0f064499144608db05660c66|72f988bf86f141af91ab2d7cd011db47|1|0|638109708088155462|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=F6b6Z5VZpKTt4m1NzZ0D8GdtrPA%2Bxy9DlRpoqrIeXhM%3D&reserved=0.
   Also looks like a test case error.  The case scripts have both accept and reject - so it created a false positive in that the rights were maintained solely becuase something else had reject rights in the groups attribute.  I've fixed the source and am rerunning some isolated tests now.

FIxed <IP_ADDRESS> published today.