Infloop13

Another attempt to fix #14242, #14443
This PR is part of the picture deprecating containerPort by isolate inbound listener and outbound listeners. More specifically, sidecar proxy need to avoid inf loop in the below conditions

inbound listeners and outbound listeners are split and not accessible from each other
iptables redirect all incoming traffic to inbound listener

This is done by bind magical local address when redirecting unmatched inbound listeners. Notes it's common when we allow user not specify containerPort. See istio design doc Better Default Networking
Meanwhile this PR should break any functionality when in/out listener is not split.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: silentdai
To complete the pull request process, please assign rshriram
You can assign the PR to them by writing /assign @rshriram in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

pilot/pkg/networking/OWNERS
tools/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Close for now as it is not ready to be reviewed

@silentdai: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-lint-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-lint-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-lint-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-lint-master

istio_auth_sds_e2e-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio_auth_sds_e2e-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-lint-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-lint-master

istio_auth_sds_e2e-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio_auth_sds_e2e-master

istio-unit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-unit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: silentdai
To complete the pull request process, please assign nmittler
You can assign the PR to them by writing /assign @nmittler in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

pilot/OWNERS
tools/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: silentdai
To complete the pull request process, please assign nmittler
You can assign the PR to them by writing /assign @nmittler in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

pilot/OWNERS
tools/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio_auth_sds_e2e-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio_auth_sds_e2e-master

istio-unit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-unit-tests-master

istio-codecov-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-codecov-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio_auth_sds_e2e-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio_auth_sds_e2e-master

istio-codecov-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-codecov-master

istio-unit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-unit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-codecov-master

istio-unit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-unit-tests-master

integ-mixer-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-mixer-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Meanwhile this PR should break any functionality when in/out listener is not split.

do you mean should or should not?

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-codecov-master

istio-unit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-unit-tests-master

integ-mixer-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-mixer-k8s-presubmit-tests-master

integ-new-install-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-new-install-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-codecov-master

istio-unit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test istio-unit-tests-master

integ-mixer-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-mixer-k8s-presubmit-tests-master

integ-new-install-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-new-install-k8s-presubmit-tests-master

istio-racetest-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-racetest-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: silentdai
To complete the pull request process, please assign nmittler
You can assign the PR to them by writing /assign @nmittler in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

pilot/OWNERS
tests/OWNERS
tools/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-codecov-master

integ-mixer-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-mixer-k8s-presubmit-tests-master

integ-new-install-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-new-install-k8s-presubmit-tests-master

istio-racetest-master
9444926fcaabef02020371eb3d282eed96269dd9
link
/test istio-racetest-master

istio-unit-tests-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test istio-unit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-mixer-k8s-presubmit-tests-master

integ-new-install-k8s-presubmit-tests-master
3c9b3a537a18a9dccd7caa8602543f4042a2a5c8
link
/test integ-new-install-k8s-presubmit-tests-master

istio-unit-tests-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test istio-unit-tests-master

istio-racetest-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test istio-racetest-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-unit-tests-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test istio-unit-tests-master

istio-racetest-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test istio-racetest-master

integ-new-install-k8s-presubmit-tests-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test integ-new-install-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@silentdai: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-new-install-k8s-presubmit-tests-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test integ-new-install-k8s-presubmit-tests-master

istio-racetest-master
1c78807f8dd5b0019245abfba13925a67ac6bc85
link
/test istio-racetest-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

--- FAIL: TestStreamSecretsPush (5.02s)
    sdsservice_test.go:382: failed to send push notificiation to proxy "sidecar~<IP_ADDRESS>~id2~local-1"

I don't think I crash this one
/retest

@costinm Could you take look? The bottom line of this PR is not to break anything and I think it is reached

Looks good otherwise - and I don't mind adding the extra control and docs in a separate PR so we can shard the testing. Approving - but please don't forget the requirements on alpha features.
/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: costinm, silentdai
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [costinm]
tests/OWNERS [costinm]
tools/OWNERS [costinm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

As usual my primary concern is safety/reliability. How do we turn it off ? How do we deploy it gradually to reduce risks ? Getting a messed up iptables or something broken when a user upgrades from 1.2 to 1.3 is not acceptable IMO.

Safety
iptables, ip, clusters are safe as long as no one use the magical ipv4 and ipv6 address. There is risk that user used <IP_ADDRESS> or people use ::6, or istio somehow refers the new "InboundPassthroughClusterIpv4/6" cluster already. That's almost impossible.
If people don't use it these rules and cluster add very little burden to istio.

The general rule is that any new (or alpha) feature should be off by default and require some user action
to enable. I think we still have the metadata to control the generation of the config - can we use it to control the new iptable config ? And please confirm that by default ( with the capture option off) we keep generating the same config as in 1.2, the new code should only be triggered when we enable the new mode.
( separate discussion - we need a global way to turn this on via values.yaml, once users have tested
it with individual workloads )

I will leave the killswitch to when pilot start to utilize the clusters or the iptables rule in following PRs. That PR would assume the iptables/clusters are provided.


Custom tags meta information are not converted to JsonSchema

Feature Request
First of all, awesome library. Using it for my side project
Custom tags are not generated in schema. It would be great if we get those meta information
when we could get that?
also which ajv version you are outputting?
interface IMember {
    customString: string & Dollar & Postfix<'!!!'>;

    customNumber: number & tags.Maximum<100> & IsEven<number>;

    nested?: IAddress;
}

{
  schemas: [ { '$ref': '#/components/schemas/IMember' } ],
  components: {
    schemas: {
      IMember: {
        '$id': '#/components/schemas/IMember',
        type: 'object',
        properties: {
          customString: {
            'x-typia-required': true,
            'x-typia-optional': false,
            type: 'string'
          },
          customNumber: {
            'x-typia-required': true,
            'x-typia-optional': false,
            type: 'number',
            maximum: 100
          },
          nested: { '$ref': '#/components/schemas/IAddress' }
        },
        required: [ 'customString', 'customNumber' ],
        'x-typia-jsDocTags': []
      },
      IAddress: {
        '$id': '#/components/schemas/IAddress',
        type: 'object',
        properties: {
          country: {
            'x-typia-required': true,
            'x-typia-optional': false,
            type: 'string'
          }
        },
        required: [ 'country' ],
        'x-typia-jsDocTags': []
      }
    }
  },
  purpose: 'ajv'
}

I don't know exact version of ajv, but working on the latest ajv.
When generating swagger mode, its version is open-api v3.0.
By the way, type tags info would be newly added. Wait for an hour, then I'll publish the next version.


[nocommit] LUCENE-9948: Automatically detect multi- vs. single-valued cases in LongValueFacetCounts

Description
Automatically detect single- vs. multi-value cases instead of asking the user to specify.
Solution
Use DocValues helper methods to automatically determine the underlying field type.
Tests
No new tests but modified existing to no longer require the multiValued ctor parameter, and ensured they cover both the single- and multi-valued cases.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Lucene maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.
[x] I have added tests for my changes.

one TODO i want to try for fun, is to look at output from gradlew -p lucene/facet coverage and see if all the e.g. optimized cases here are really tested (https://github.com/apache/lucene/pull/119). Will look into it later!

Looks good:


travis: run ciao-controller/internal/datastore tests

adding ciao-controller/internal/datastore tests to be run by travis

Good catch.
You should be able to just add the wild card to the github.com/01org/ciao/ciao-controller, e.g.,
test-cases -text github.com/01org/ciao/ciao-launcher github.com/01org/ciao/ciao-scheduler github.com/01org/ciao/ciao-controller/... github.com/01org/ciao/payloads

Hi,
Added the wild card.

@chavafg  Could you squash the two commits and rebase?  Then I'll merge.  The build problems are not related to this patch.


[SR-2999] Unable to import as member using NS_SWIFT_NAME

Previous ID
SR-2999

Radar
rdar://problem/31877728

Original Reporter
LeoNatan (JIRA User)

Type
Bug

Environment
Xcode 8.1 beta 4, Swift 3.1

Additional Detail from JIRA

Votes
0

Component/s
Compiler

Labels
Bug, ClangImporter

Assignee
@belkadan

Priority
Medium

md5: 67781ffd80e7cdf4a642e49b1a382055

Issue Description:
I have two C functions:
UIColor* LNRandomDarkColor();
UIColor* LNRandomLightColor();

Trying to import them into Swift as member methods of a `UIColor` extension:
UIColor* LNRandomDarkColor() NS_SWIFT_NAME(UIColor.randomDarkColor());
UIColor* LNRandomLightColor() NS_SWIFT_NAME(UIColor.randomLightColor());

However I am receiving the following warning:

imported declaration 'LNRandomDarkColor' could not be mapped to 'UIColor.randomDarkColor()'

I think this is a bug. In the 402 "What's New in Swift" talk, a similar concept was presented with Core Graphics APIs:
void CGContextFillPath(CGContextRef) NS_SWIFT_NAME(CGContext.fillPath(self:));

extension CGContext {
  func fillPath()
}

Also relevant, see this SO question:
http://stackoverflow.com/questions/40133453/ns-swift-name-for-importing-c-function-as-a-class-extension

Could it be the CF_BOXABLE attribute is messing with the typedef?


Would you guys be interested in moving to shippable instead of travis?

Shippable is extremely optimized for building docker images.

Hi I think we're good with Travis CI for now, unless there are compelling reasons to consider Shippable?  Travis's Docker support has been fine for us.


In Python, we should always try to solve the problem with string methods – such as endswith, startswith, lstrip, rstrip, etc. – before resorting to regular expressions, which are slower most of times.
So, I'll add a few line comments in order to suggest some changes to your PR regarding the above.

Thanks for the feedback! I've made the changes you requested and I'll push once tox finishes running. Let me know if you see anything else.
I've tested the output of cat on macOS, Debian, and Arch. If someone out there is running a more esoteric system, it'd be interesting to check if all cat's respond the same way.

Thanks!

Or maybe we're better off with just ... endswith(': Is a directory\n') and those who use a cat that doesn't follow “default”
implementation are ”in a state of sin and deserve whatever happens to
them.” We can still have  ... or endswith(': Is a directory') if we
ever need to, after all.

My sin is on an other kind of state :
romain@dulix:~/Musique/White_Cowbell_Oklahoma$ cat ..
cat: ..: est un dossier

One more time, I miss a test (-:

I wonder what your thoughts on this are.

++
Romain
Ceux qui ne savent pas où ils vont sont surpris d'arriver ailleurs.
-+- Pierre Dac -+-

I’m not super familiar with internationalization, but a bit of digging brought me to gettext. The closest I can find to the string we’re seeing in English is “Is a directory” (note the leading capital) in glibc’s sysdeps/gnu/errlist.c, which is translated to “est un dossier” on the translation project. I suppose we could parse out the messages from the files there or perhaps the python gettext library is what we want.

I’m on mobile so can’t try it right now, and I probably should be asleep, but from a quick look at the docs, it might be as simple as gettext.translation(domain=‘libc’).gettext(‘Is a directory’)

@Rom1deTroyes could you post the output of locale and the values of the environment variables LANGAUGE, LC_ALL, LC_MESSAGES, and LANG from your system?

I've opened #826 to add localization to this rule.

@Rom1deTroyes are you using experimental instant mode or shell logger? Otherwise thefuck should rerun the command with LANG=C and get error message in English.

Le mardi 10 juil. 2018 à 11:40:38 (-0700), Scott Colby a écrit :

@Rom1deTroyes could you post the output of locale and the values of
the environment variables LANGAUGE, LC_ALL, LC_MESSAGES, and
LANG from your system?

$ locale
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
BTW, there is no C or C.utf8 locales on this system (I don't know why :
this is an old eepc used as a personal assistant) :
$ locale -a
fr_FR.utf8
POSIX
++
Romain
Ce qu'on fait n'est jamais compris mais seulement loué ou blâmé.
-+- Friedrich Nietzsche, Le gai savoir -+-


Additional search function and upgrade to 2021 BISAC

This is my first public commit so I am really sorry if I messed something up.
Added function to return an array of subjects by query and documented it in README.md.

I also upgrade data/bisac.json according to the BISG website.


Use better quality challenge platform logos

Find SVG logo (preferred) or PNG with transparent background
In order for the ROCC to work with PNG and SVG image, consider moving the path to the logo to the Challenge Platform object stored in the backend, instead of inferring a path to the logo like assets/{platformName}.svg.

@rrchai Proposed steps

Identify a suitable size for the challenge platform logo (1:1 ratio preferred)
Start with finding or creating a PNG logo for Synapse and 1-2 challenge platforms.
Add a folder named images to the root of this repository and place the images there (like done in this repo).
In the challenge platform seeds, use link to the "Raw" image on GitHub.


docs(documentation-website):Add npm run local to Contributor Guidelines

The Pull Request is ready

[x] fixes #736
[x] all actions are passing
[x] only fixes a single issue

Overview
This pull request addresses the issue by updating the contributor guidelines to include instructions for running Continuous Integration (CI) tasks locally using the npm run local command.
Documentation-Website

[ ] mobile view is usable
[ ] desktop view is usable
[x] no a-tags are used directly (NavLink, MailLink, ExternalLink instead)
[ ] all new texts are added to the translation files (at least the english one)
[ ] tests have been added (if required)
[ ] shared code has been extracted in a different file

@akhil0203 thank you for helping! Do you want to add the website changes as well? If not I'll merge the doc changes.
Files:
/documentation-website/language/en.yml
/documentation-website/src/pages/contributing/index.tsx

@akhil0203 thank you for helping! Do you want to add the website changes as well? If not I'll merge the doc changes.
Files: /documentation-website/language/en.yml /documentation-website/src/pages/contributing/index.tsx

i would love to do it ,as this is my first contribution to this awesome project i may take some time to sort it out but i will complete the task

@akhil0203 thank you for helping! Do you want to add the website changes as well? If not I'll merge the doc changes.
Files: /documentation-website/language/en.yml /documentation-website/src/pages/contributing/index.tsx

i would love to do it ,as this is my first contribution to this awesome project i may take some time to sort it out but i will complete the task

thanks, if you need any help, just ask - you can find at least me on our slack :) There is a guide to the language files on our youtube, that may actually help a bit: https://www.youtube.com/watch?v=FEYIeMCrrbk

@akhil0203 will merge the current change already, so we have you among the contributors already :) not taking the task away from you, just create a fresh branch for it please!


Custom integration documentation is out of date

Expected Behavior
Docs are up to date.
Observed Behavior
This page says

This page is based on Ktlint 0.49.x which has to be released.

Which is no longer correct. I'm assuming the message can just be removed now that 0.49 & 0.50 have been released.
Steps to Reproduce
N/A
Your Environment
N/A

Indeed, this warning is outdated. I think that is a relic from the time that I did not have versioned documentation yet. Did you encounter any information on the page that was not correct or is it jus tthe warning that misleads you?

Just the warning, I didn't need to use the actual docs in the end so I'm not sure if anything else is inaccurate or out of date.


Enhancing date/time input by allowing direct typing

To enhance data input speed and user experience, it can be interesting to also allow the user to type the desired date directly as shown here below. This is interesting for old dates especially, like birthdates.

Unfortunately currently best we can do (without a bigger rework is adding a button to go back 10 years.
We're bound by bootstrap UI.
https://github.com/cortezaproject/corteza/commit/f5e6c45d07763c2d899944752826ff3442455870


Add custom matcher support to vcr_config object.

I need a custom request matcher supported in my tests, but pytest-vcr doesn't expose the register_matcher function to pytest in any way.  I don't know how usable this approach is at the moment, but I thought I would document it here in case it's interesting to anybody.

Thank you for pointing this out. I've looked at the VCR class, and there will be a similar issue with serializers and persisters.
I'm not sure about the proposed approach: I want to keep vcr_config compatible with VCR kwargs, and adding custom names there might clash with future changes to vcrpy. Would extracting a vcr fixture out of vcr_cassette make sense for your usecase? Then you'd register custom matchers with:
@pytest.fixture
def vcr(vcr):
    vcr.register_matcher('my_matcher', my_matcher)
    vcr.match_on = ['my_matcher']  # This can also go into vcr_config or marker kwargs
    return vcr

This approach is similar to the one vcrpy-unittest takes, and I think it's more future-proof.

Yes, that would work perfectly for my use case.  Though it's deeper waters
than I'm comfortable swimming in.  Feel free to close this PR if that
change is on your roadmap somewhere.
On May 25, 2017 12:57 AM, "Tomasz Kontusz"<EMAIL_ADDRESS>wrote:

Thank you for pointing this out. I've looked at the VCR class, and there
will be a similar issue with serializers and persisters.
I'm not sure about the proposed approach: I want to keep vcr_config
compatible with VCR kwargs, and adding custom names there might clash
with future changes to vcrpy. Would extracting a vcr fixture out of
vcr_cassette make sense for your usecase? Then you'd register custom
matchers with:
@pytest.fixture
def vcr(vcr):
vcr.register_matcher('my_matcher', my_matcher)
vcr.match_on = ['my_matcher']  # This can also go into vcr_config or marker kwargs
return vcr
This approach is similar to the one vcrpy-unittest takes, and I think it's
more future-proof.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ktosiek/pytest-vcr/pull/1#issuecomment-303929945, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAeYSVkacqvdA5U2dyBbso3R3icWPyyks5r9RhTgaJpZM4Nlp-x
.

Can you test with current master? I've only run the tests so far, haven't checked in the real world. The documentation already mentions the new fixture: http://pytest-vcr.readthedocs.io/en/latest/configuration/#vcr


Do cloud billing upto end of Q3 2023

I'll work with @colliand in doing cloud billing, upto Q3 of 2023 (until end of September 2023).
This entails:

[ ] Cloud costs for AWS clusters we need to pass through
[ ] Cloud costs for GCP clusters we need to pass through
[ ] Cloud costs for hubs on 'shared' clusters

[ ] For 2i2c GCP cluster
[ ] For 2i2c-aws-us AWS cluster
[ ] For 2i2c-gcp-uk GCP cluster

I'll start working on this sometime early November.
Process improvements

https://github.com/2i2c-org/infrastructure/issues/3386

If it's a useful datapoint, it looks like we have about $70,000 of un-billed cloud costs right now, based on our AirTable graph. I don't know if that's an exact number, but maybe is a ballpark.

ooof that is a lot of money.

Copy-pasting some thoughts I shared from Slack (that I think it would be useful to record here as well):

Can we make sure we (at least briefly) document the process in that very issue so other engineers (besides @yuvipanda) can help with this recurring process in the future? Thanks!

Another goal is to build out some more infrastructure to make this easier next time.
https://github.com/2i2c-org/infrastructure/pull/3397 tags nodes appropriately so we can easily differentiate between core and user and dask worker nodes.

Moved to https://github.com/2i2c-org/meta/issues/742

Closing this as the issue is otherwise duplicated with https://github.com/2i2c-org/meta/issues/742, and I think the intent was to close this.


🍒 Cherry pick PR #5524 to staging 🍒

🍒 Cherry pick https://github.com/Expensify/App/pull/5524 to staging 🍒

🚀 Deployed to production by @timszot in version: 1.1.2-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Keyboard Navigation

Hey, it's Nolan from TR! Hope you've been doing well!
We've been asked to add keyboard navigation to our nav to meet some a11y requirements coming up in UK. I'd like to keep using navmore for now, so our package consumers there can get the keyboard navigation without making changes on their end.
I was thinking I'd do some work on it this week and then make a pull request here. Please let me know if you have any input!

Hey Nolan! Sounds good. This is an important and needed improvement.

Is there any way I can help here? What are the major sticking points that you are wanting to address?

I'm actually working on a change now, but I'm hoping to have it up today or tomorrow if you don't mind taking a look then.
We want users to be able to tab through the nav and interact with the "enter" key. I'm thinking we can just add top-level nav items to the tabindex, and handle the "enter" keypress with the existing handleTap function.
Right now, I'm working on setting it up so nested list items (dropdown items) aren't tab-able until the user has opened that dropdown menu.
I'll be on slack today if you have any feedback on that approach!

Hey Nolan. Thanks for the PR. I had a few thoughts, but didn't get a chance to share them. Been a busy day. I'll have a look at the PR as soon as I can.

Released in 3.0.0


Mint and/or update a DOI for WorkVersions and Works

This is a service object that ties together the DataCite client that Adam and I wrote, along with the DataCite metadata mapper class.
In order to pull this off, I needed to add a few things besides just make a service:

Verify that DataCite::Client#publish is idempotent on DataCite's side. That is, we can call it multiple times and it'll do the right thing (i.e. update the metadata on the second call, without having a freakout that it's already been published.)
Add a method DataCite::Client#get to retrieve the metadata of a particular DOI. This is used for testing
Add a public URL to the Datacite::Metadata mapper. Please note that I did not know what a particular resource's public URL should actually be, and I remember there being some discussion around this. So in the mean time I put in a bogus value, and then put in a (currently failing) pending spec to ensure that it's something reasonable once we figure that out.

Currently the integration test hits the real DataCite API, and only runs on CI. Dann and I had thought of a few ways we could make this fancier, but ultimately skip: !ci_build? is simple and effective.
Fixes #103

@whereismyjetpack ☝

Cool beans!


Setting column level filters programatically in client-side model

Request for enhancement
Expected behaviour:
Need functionality(APIs) to be able to set column level filters programatically, currently the only way is via user input in filter textbox
Steps to reproduce the problem:
Enable filtering attribute and type into filter text box, No API methods to set filter on the dataset.
Bower version:v 5.1.7

Is this a possibility in the near future? if any one can confirm, comment....

We are not currently investing much effort in the existing px-data-table, as we will be replacing it completely with the Vaadin-based grid in the coming weeks. Their grid already has an API for filtering, so I assume the Predix version will contain something similar, but am not 100% sure.

Any expected date?

Delivery from Vaadin should happen by the end of the year, but we may need additional time for code review and testing before making the code public.

Closing due to age and release of https://www.predix-ui.com/#/elements/data-grid/px-data-grid


"Ciocești" is listed in the drop-down menu

Description:
"Ciocești" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Ciocești" in the search bar.

Expected results
The location is listed in the drop-down menu as "Ciocești, Argeș (Bârla)".


drag and drop multiple node connected

Hi @jerosoler,
how to create multiple connected node in a canvas  while drag and dropping a single node
like need the below example while draging and droping a node from the list

Thanks @jerosoler  It works

can we group the above nodes. move all the group nodes while dragging and delete all the grouped nodes while delete

You will need to implement a layout similar to this.

https://github.com/jerosoler/Drawflow/issues/322


tkinter-tooltip-3.1.0 - "Disappear bug "

tkinter-tooltip-3.1.0 - "Disappearbug "
sometimes when you hover over the tooltip(button or label ) , and move the mouse out , the full GUI goes to back (lost focus )
demo of bug :  ToolTip(userinfo, msg="Actual User",delay=0.5,fg="black",follow=False, bg=tooltip_bg_color)  # dissparaid bug
i have found the solution to this :
root.after(250, lambda: ToolTip(userinfo, msg="Actual User", delay=0.5, fg="black", follow=True, bg=tooltip_bg_color)) # fix for desaparition of main gui
maybe you can add these options directly to  " tkinter-tooltip"

Can you please provide a minimal example that reproduces your issue. I can't reproduce.

here you can see this  :
`import tkinter as tk
from tktooltip import ToolTip
Create the root window with a fixed size
root = tk.Tk()
root.title("Right-Click Menu Example")
root.geometry("400x300")  # Set the size of the root window
User info label example
userinfo = tk.Label(root, text="User Info")
userinfo.pack(pady=10)
Define the tooltip background color
tooltip_bg_color = "yellow"
Add the tooltip to the userinfo label with a slight delay
ToolTip(userinfo, msg="Actual User", delay=0.5, fg="black", follow=True, bg=tooltip_bg_color)
Run the Tkinter event loop
root.mainloop()

@dimmv2 I cannot reproduce the behaviour you described with the provided MWE. I tried on Linux and MacOS, with Python versions 3.10 to 3.12.
That likely means that either there is something wrong with your tk installation/machine or there is a bug in your code.
From what I saw in your uploaded animation, you might be overriding your widget's bindings somewhere else.
If you have a MWE that can reproduce this in an another machine or a containerised (controlled) environment, let me know, but I suspect the problem is coming from elsewhere.

@gnikit
i have test it right now on other pc
with this config :
tkinter-tooltip-3.1.0
Python 3.10.4
win11
and i confirm that with my last mini example,the windows lost focus, when you move out the mouse from tooltip

check the second part of that GIF, the problem is recorder right here .


Jetty Vulnerability CVE-2023-36478 and CVE-2023-40167

Jetty 11.0.15 has two vulnerabilities open against it. This is the version that Javalin 5.6.2 depends on.

CVE-2023-36478
CVE-2023-40167

Jetty has fixed both of these vulnerabilities in version 11.0.16.  Can we release a new Javalin 5 version that uses at least version 11.0.16 of Jetty?

Sure, would you like to submit a PR? As far as I remember, @zugazagoitia checked that we were not affected by this, but it's good to keep Jetty up-to-date anyway :)

Oh sure, happy to!  I notice that master branch already has 11.0.16 in it (albeit 11.0.17 has been released), but javalin-5x branch is still using 11.0.15.  Not sure what it takes to get that updated moved over to the javalin-5x branch, if I should open a PR directly against the javalin-5x branch, or what the general branching strategy is.

Yup, just open the new PR for 5.x :) We don't really care about syncing 5.x with 6.x at this point, especially that we'll probably replace Jetty 11 with 12 before the 6.x release.

Perfect, will do!

Done.  I created a PR against the javalin-5x branch.

Thanks, now we have to wait for @tipsy :) He's currently slightly busy due to business trip, but it should be merged in the upcoming days.

Sure, would you like to submit a PR? As far as I remember, @zugazagoitia checked that we were not affected by this, but it's good to keep Jetty up-to-date anyway :)
Edit: By the way, there's already an v11.0.17, so I guess we should use that one.

These are both new CVEs, we're affected by both of them, and should update to 11.0.17 to address them. I was just about to PR this now 😅


supported_features is hard-coded to 1

First off, thanks for this integration - it's working really well.
The one issue I've found is that there seems to be some inconsistency with the "pullstring support"  state and the supported_features attribute.
In my case, the lock does not have pullstring enabled, and the attribute correctly reports that. However, in this section of the code, the supported_features is hard-coded to report the value 1:
    @property
    def supported_features(self):
        return SUPPORT_OPEN

Unless I misunderstood the documentation, the SUPPORT_OPEN means, opening the latch, which is the same thing... so this value is wrong (it should be 0 in my case, and not 1).
The impact of this is that some lovelace cards will show an "Open" button if they see that value as 1 - for example, the Mushroom Lock card does this (the button obviously does nothing, but it should not be there in the first place...)

I know I do a late response...
In the code it is like that:
    @property
    def supported_features(self):
        """Flag supported features."""
        if parse_version('0.0.2') <= parse_version(pkg_resources.get_distribution('pytedee').version):
            if self._sensor.get_is_enabled_pullspring():
                return SUPPORT_OPEN
            else:
                return None
        else:
            return SUPPORT_OPEN

It seems you are referring to an old version.


imp(fee): capital efficient fee middleware

Description
The TimeoutFee has been deprecated, and is automatically set to 0. The timeout relayer receives recv_fee + ack_fee instead.
If the timeout fee is non-zero (due to it being written to storage before this upgrade), then it is handled with legacy logic. We can potentially improve this by simply refunding Timeout fee it to sender instead and handling it with the new logic. More discussion is needed
closes: #5509
Commit Message / Changelog Entry
imp(fee): capital efficient fee middleware

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against the correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

We have decided to go with a different design, see https://github.com/cosmos/ibc-go/issues/5509


Update 05-long-term-storage.md

Updating commentary on storage options.  Some of the notes on table storage are not accurate.  Please add more content around big data analytics via blob storage.  Please do not contrast technology directly 0- please contrast applicability of workloads/scenario (online access, historical retention, etc).

Hi @mabsimms, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

 If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


python setup.py test now works by default

You don't need to have pytest-runner before-hand.

Hello @horta! Thanks for submitting the PR.

There are no PEP8 issues in the file setup.py !

works for me -- thanks!


Title too small

@baconC can you re-check and close this if the issue has been addressed?  The CSS was updated in the 3.0 release http://ciena-frost.github.io/ember-frost-modal/

Please update with this CSS
.frost-modal-dialog-header {
display: flex;
position: relative;
align-items: center;
min-height: 70px;
padding: 20px 30px 20px;
/* border-bottom: 1px solid #E8E8EF; */
}
.frost-modal-dialog-header-title {
font-size: 23px;
font-weight: 700;
}

@baconC sneaky ;)
I want to discuss the border-bottom before removing it #12, we'll do the rest

JIRA: https://agile-jira.ciena.com/browse/FROST-1364


Documentation of PlaceandFaceValue, PythagorasTheorem, ProfitLoss

Kindly assign to me.

Hey @DanishGBU,
Assigned.
Issue completion deadline - 16th Oct 11:00:00 am IST
NOTE - In case the issue completion deadline is not met, the issue will be assigned to a new participant


use goreleaser for build

Codecov Report
Base: 76.17% // Head: 76.17% // No change to project coverage :thumbsup:

Coverage data is based on head (79d8f6e) compared to base (b80881c).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #51   +/-   ##
=======================================
  Coverage   76.17%   76.17%
=======================================
  Files          12       12
  Lines         298      298
=======================================
  Hits          227      227
  Misses         63       63
  Partials        8        8

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

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


CLion build failure

Describe the bug
CLion 2021.3.3 derivation fails to build.
Steps To Reproduce
Steps to reproduce the behavior:

Add jetbrains.clion to system/user packages
nixos-rebuild

Expected behavior
The system rebuilds.
Screenshots
/nix/store/rpk8vd0habrxqfj7mg29yk56gsyvg1b1-clion-2021.3.3/clion/bin/format.sh: interpreter directive changed from "#!/bin/sh" to "/nix/store/dndi916j6yxzfzzj2sma2llhrlwahq06-bash-5.1-p16/bin/sh"
/nix/store/rpk8vd0habrxqfj7mg29yk56gsyvg1b1-clion-2021.3.3/clion/bin/restart.py: interpreter directive changed from "#!/usr/bin/env python" to "/nix/store/hb1lzaisgx2m9n29hqhh6yp6hasplq1v-python3-3.9.10/bin/python"
/nix/store/rpk8vd0habrxqfj7mg29yk56gsyvg1b1-clion-2021.3.3/clion/bin/clion.sh: interpreter directive changed from "#!/bin/sh" to "/nix/store/dndi916j6yxzfzzj2sma2llhrlwahq06-bash-5.1-p16/bin/sh"
/nix/store/rpk8vd0habrxqfj7mg29yk56gsyvg1b1-clion-2021.3.3/clion/plugins/remote-dev-server/bin/launcher.sh: interpreter directive changed from "#!/bin/sh" to "/nix/store/dndi916j6yxzfzzj2sma2llhrlwahq06-bash-5.1-p16/bin/sh"
checking for references to /build/ in /nix/store/rpk8vd0habrxqfj7mg29yk56gsyvg1b1-clion-2021.3.3...
patchelf: cannot find section '.dynamic'. The input file is most likely statically linked
/nix/store/lkk0hf9h4x85mb4lrsf2sh25qm2i4n18-stdenv-linux/setup: line 87: cd: /nix/store/rpk8vd0habrxqfj7mg29yk56gsyvg1b1-clion-2021.3.3/clion-2021.3.3: No such file or directory
error: builder for '/nix/store/ywqpaza1v0wpgvfhvp8a54y8j24kvnbw-clion-2021.3.3.drv' failed with exit code 1
error: 1 dependencies of derivation '/nix/store/ihmd0x2870f94lcqiwf8aah1bdczbgys-user-environment.drv' failed to build
error: 1 dependencies of derivation '/nix/store/jdcs14nj0ysz1rh4y7alxkx1avdy40fm-etc.drv' failed to build
error: 1 dependencies of derivation '/nix/store/5114s9478y1a1rsna05pn2cdk47pma2v-nixos-system-CAPRICA-22.05pre364329.ce8cbe3c01f.drv' failed to build

Additional context
Seems the clion-$VERSION folder has been renamed to just clion:
$ ls -la /nix/store/rpk8vd0habrxqfj7mg29yk56gsyvg1b1-clion-2021.3.3
total 11588
drwxr-xr-x    6 nixbld1 nixbld     4096 Mar 29 19:37 .
drwxrwxr-t 5615 root    nixbld 11833344 Mar 29 19:38 ..
drwxr-xr-x    2 nixbld1 nixbld     4096 Mar 29 19:37 bin
drwxr-xr-x    8 nixbld1 nixbld     4096 Mar 29 19:37 clion
drwxr-xr-x    3 nixbld1 nixbld     4096 Mar 29 19:37 libexec
drwxr-xr-x    3 nixbld1 nixbld     4096 Mar 29 19:37 share

Notify maintainers
@Mic92 @edwtjo
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

system: "x86_64-linux"
host os: Linux 5.15.29, NixOS, 22.05 (Quokka), 22.05pre363214.1d08ea2bd83
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.7.0
channels(zane): ""
channels(root): "nixos"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

cc @Stunkymonkey @siraben


eos_config_deploy_cvp: Missing documentation of apply_mode

There is no documentation for the apply_mode: strict/loose in the URL: https://avd.sh/en/devel/roles/eos_config_deploy_cvp/index.html
This is a new feature applicable only for the cv_collection: v3

Thank you @tgodaA, I'll get on this!

This apply_mode option had no function here. It would always be loose. So this is an error in the guide. I am adding support for container_apply_mode and device_apply_mode (among others) in #2561. I will update the example as part of that as well.

Addressed by #2718


Add padding support for progressbar drawtype

This is a basic implementation of padding for progressbar, based loosely on the implementation for label.
I also looked at animation and ramp, but it appears they should get padding support automatically due to the use of load_optional_label() and copy_undefined() in their load methods.
This was targeting at resolving issue #809 .

We could probably make bar-NAME-format a label itself so we don't have to duplicate all the code to load and apply the padding right?

Good point.  I'll take a crack at that later tonight.

Yeah, that was a good clean-up.  progressbar::m_format has been replaced with a label.  This cleaned up the pre-existing output() code by letting it re-use label::replace_token rather than using string_util::replace_all directly.   Margins and padding work for free.  You can reverse the direction of a bar by setting format="%empty%%indicator%%fill%" in the config, etc.

Looking back at your comment, I made bar-NAME a label, rather than bar-NAME-format.  This seemed cleaner as it also makes bar-NAME-foreground, etc. all work as I would expect.  I can push it down to the -forrmat sub-element, but using bar-NAME-format-foreground is less intuitive.  What would you prefer?

Yeah, I didn't like the string_util::replace_all in there either. If we are literally replacing tokens we can use the functions we wrote for that ;)
This now no longer uses bar-NAME-format for the actual format, right? We should deprecate it then and tell the user to switch.
Also bar_label->get() will give you the label content after it has been truncated (minlen, maxlen). You should try to get the raw label contents.

@patrick96, that spiraled a bit.  Handling deprecation was non-trivial as load_label is where all the config access was occurring.  Additionally, label previously had no method for allowing access to the raw format string.
I ended up extending the load_label and conf.deprecated machinery to handle this.  There's now a variation of conf.deprecated to handle required parameters (before, it only handled optional ones).  load_label now handles there being a deprecated_name, uses the new deprecation machinery, and the right deprecation messages are produced.
It only handles the actual format-string being deprecated in the label, and not all the other possible label fields (padding, margin, etc.).  This is clearly something that can be improved, but it is all that is needed to enable this change to progressbar as there was no name-BAR-format-LABELCONF before.
Honestly, I'd prefer to rework the deprecation machinery entirely in a future PR.  It would seem cleaner to do a deprecation pass through the config, issuing warnings, and effectively doing a new in-memory-only conf::set to place the deprecated fields in their new homes, then the users of conf can just assume everything is where it's supposed to be.  This would allow multi-hop (chained) deprecation, and avoid the need for different deprecate methods for different types as well as the optional/required variants.
Something like:
// move older_key (if found) to old_key and issue warning if found
conf.deprecate(section, older_key, old_key);
// ditto for old_key to new_key
conf.deprecate(section, old_key, new_key);

... code continues and uses conf.get(section, new_key) only ...

Let me know what you want to do regarding this specific progressbar, padding feature.  I don't want to spiral this too far.


[SPARK-20877][SPARKR][WIP] add timestamps to test runs

What changes were proposed in this pull request?
to investigate how long they run
How was this patch tested?
Jenkins, AppVeyor

Test build #77330 has started for PR 18104 at commit dab72a6.

Test build #77330 has finished for PR 18104 at commit dab72a6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77330/
Test PASSed.

Test build #77336 has started for PR 18104 at commit 313dcbc.

Test build #77336 has finished for PR 18104 at commit 313dcbc.

This patch fails R style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77336/
Test FAILed.

Test build #77339 has started for PR 18104 at commit a72ab8c.

Test build #77339 has finished for PR 18104 at commit a72ab8c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77339/
Test PASSed.

Test build #77403 has started for PR 18104 at commit 3273a0d.

Test build #77403 has finished for PR 18104 at commit 3273a0d.

This patch fails SparkR unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #77405 has started for PR 18104 at commit 1d18d7b.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77403/
Test FAILed.

Test build #77405 has finished for PR 18104 at commit 1d18d7b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77405/
Test PASSed.

Test build #77406 has started for PR 18104 at commit 21ca8f0.

Test build #77406 has finished for PR 18104 at commit 21ca8f0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77406/
Test PASSed.

Test build #77474 has started for PR 18104 at commit 9056b75.

Test build #77474 has finished for PR 18104 at commit 9056b75.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77474/
Test PASSed.

Test build #77481 has started for PR 18104 at commit 9e848a1.

Test build #77481 has finished for PR 18104 at commit 9e848a1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77481/
Test PASSed.

AppVeyor test portion took about 5 min https://ci.appveyor.com/project/ApacheSoftwareFoundation/spark/build/1361-master

perhaps we could cut down a lot more tests though http://r-pkgs.had.co.nz/tests.html#test-cran
if the target is under 1 min...

@felixcheung This is very cool. Let me try this on a windows VM and winbuilder and get back to you.

Ping?  I'd like to cut the next RC.

We were talking about another more drastic approach but what we have here would be improvement.
I'm reverting as-cran so this can go in (after another round of tests), and I think then should unblock RC.

Test build #77566 has started for PR 18104 at commit 1392392.

Test build #77566 has finished for PR 18104 at commit 1392392.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77566/
Test PASSed.

ok passes. @shivaram what do you think about this?

LGTM. Thanks @felixcheung for the update and @marmbrus for the ping

@shivaram did you get the chance to look at refactoring tests we discussed?


[WIP] Feat/dtynn/jsonrpc2

Hi @howardwu
I would like to get feedback from the team about if you will accept a pr like this, while it is still in the early stage.
Motivation

avoid handwritten rpc implementaions
rpc client constructor

Test Plan
WIP
Related PRs
no

The issue with jsonrpc crates is that they are effectively deprecated at this point, with jsonrpsee being the in-progress successor; at one point in time the handwritten implementation was introduced to remove all the outdated dependencies including the then-incompatible tokio below 1.0, and I think it would be best to switch to jsonrpsee once it's ready.


These Safe address are all created by 0xCA33B0EDFB55C99d99B1d8F76f07fFe88036083D

Related Safe Addresses
0x0167efcf8779540c0c663988223c8af1c987dd27
0x02308b53273ab3494d482d5fb3d1f0710acb0890
0x0664e2399d15e744893a51f45aa2e855bffa5e34
0x0968989a87b6fec3140ae2ff19eaac049e48a1d8
0x0e0d46d1eb35faaf40ec9d6b1ebb20ed4ebaa6c3
0x217553912f41594e6e1db45530833e9518f80608
0x21ff718da8f01fdbba456d85035b9b3529d787ad
0x2916965cb25030cea3045833e36743badef32aed
0x2949353eb259a91bfb17398da5451a5dd8747729
0x299b68ac4725f5be3063f4cd33c627a3b12cdce0
0x2a032e7a4575d067953fa85b02a934916b519571
0x2c681dfaeb767b0d2566e60c0f78bfb7c59c72db
0x2e192fe2f1d3b41a6c2ef870414701e6154444da
0x30664df7d38b104dc7a29aeda3d8ee75afbab131
0x3437977766fe4e39d5ade5206470ae9aef15f7ac
0x35e7e80eedb82e57a89a1e461e53389631f500d0
0x3bdd8472e1d18a89cd5016789fd1a66bbe352cf2
0x3bed69632a03a987cdea408788845bd4818844d4
0x4a8c28b424bbd58799b766edeced5b29f86cf8ff
0x58c43c94f6e85a1a21d8850d273548c2640b7211
0x58e940d446c0899179275b53f9ecf77e1c4c65e9
0x5d37ee15c43fa22e303ebfa94fe7a19941e65fbd
0x65c5d27ff7facbd993aeec2ccddc91174e05c80f
0x68e77a8145579416f3eda9aed049d5cf91a53282
0x7c9e2a508d93398b65fa2aece3f256e3320fb065
0x85115b8210be88f28ca35ac38bf272a0e1b8a0af
0x872d65baa9e8feca7d6dd65796b2855c18c30a54
0x8b302d87794f62fce8e8ee1fd1e2ad7a815d35a8
0x8c5b88dc02919177452515114a9000e37510cc7c
0x8d0c0de7b9f6533329ab65658578e607425a9f9f
0x956e68cecc3096ca1c1a1a234b8c64404e094446
0x9d2457f5eb132415b8f3c7582791bdaef0ae77ad
0x9e77a2839f572f2bf42b294083cae9bb4c875264
0xa0c33d89c9f8782275b4302f0b37818df4acc506
0xa1867846ad5a22af54e0fb30d718a7dd53fcabbb
0xa75ee0366af36572c46e2b672dff918e7a624284
0xa8246172595716fa28d62e0e5e26719a87ba67d1
0xab345d31c805dfbc6983734010da19d5ee920058
0xabb966b8be466a63ce3b1c5c1cb84c8d923439d5
0xadd69f901baff4da16eda2c1ca0e966918d33502
0xaf67fa1e357a550e78fb94831ed230500d775020
0xb3268b45aadc4cc57cd6e723e481520ba9b43a39
0xbfa823f5f7c9a13c0bbf362596fda6a2b0284ec8
0xc18924a3e29045b76327ac6683bbf30df1c4ef28
0xc6db09a301bfb0991458074199a905245f13d043
0xcb809e0951054742b1b86761d23b51a56ddab26f
0xd28c72c40b6ee8a9b29432ba884e0e2d73295f4d
0xd78ae938f0f6df5156eab14d60da23aa3a4aa6e1
0xdd4dec45868677d990f98e6ca823c681a3b0b632
0xe828fb89dcfdf3f17200acadc81610ca6b3bd105
0xe8d6e069811a736301ce5ec08ef30a5ead2efc6c
0xf23a6093e31eb5ab913c8c459ed97c4d2085824b
0xf5ea4f180458817a597eef593ae296514a0008e6
0xf7a116312c6cc8af4e7e1d31e89642b681c14829
0xfce853eaf6e6256033c2de33a0e850838ab0dd4d
Reasoning
1、These Safe address are all created by 0xCA33B0EDFB55C99d99B1d8F76f07fFe88036083D
2、 Almost all of the transactions from this address is to create Safe address and do nothing else.
3、Most Safe address only use two or three times.
4、Five or ten Safe address as a bundle were created at  the same time.
5、Let us analyse the owner of All Safe address!
There are 6 owners.
owner 1: 0xCA33B0EDFB55C99d99B1d8F76f07fFe88036083D
Safe address creator
All 56 Safe address were created by this wallet.
owner 2: 0x290e556cae1d0d17c550edc8f9ed9208e268ed5b
Safe address executor
All 56 Safe address were executed transcations by this wallet.
owner 3: 0x7684370Cd8755C4Ac5Bef0Bb29bB787130df6818
Only have two transations,one is for Safe execution,another one is owner 1 transferred 0.5eth to owner 3, Is it fun?
owner 4: 0xC2a8264a49be2Fc5BCa778B7A61B1e5129169b80
Empty wallet,have no transaction
owner 5: 0x43c9B6D9ca494c5E87ECBD524fA7381C4F4ae3F4
Empty wallet,have no transaction
owner 6: 0xA9062F9367987970b6c17128b9eE0cD07C3cE920
Empty wallet,have no transaction
All 56 Safe address are controlled by the same creator、executor and empty wallets.
The creator address is to create Safe wallet and do nothing else.The executor address is to execute Safe transactions and do nothing else.The Other address are empty wallet. No owner address looks like a normal wallet.
From all analysis above, we can conclude that all owner and Safe address are actually controlled by one person, i means,
airdrop farmer.
Methodology
Download all the transactions of Safe wallet factory and find the address created many Safe wallets.
Analyse all the transacitons and behavior of the Safe wallets and finally find the suspicious airdrop farmer address.
After finding suspicious airdrop farmer address , find the evidence how they do sybil-attack.
Safe Address
My Safe Address
0x75c5d4B456b697C9CCa3DAAf4c4a2392b3E1Ddbb

Checking the first 4 Safes:
https://gnosis-safe.io/app/eth:0x0167efcf8779540c0c663988223c8af1c987dd27/transactions/history
https://gnosis-safe.io/app/eth:0x02308b53273ab3494d482d5fb3d1f0710acb0890/transactions/history
https://gnosis-safe.io/app/eth:0x0664e2399d15e744893a51f45aa2e855bffa5e34/transactions/history
https://gnosis-safe.io/app/eth:0x0e0d46d1eb35faaf40ec9d6b1ebb20ed4ebaa6c3/transactions/history
Those have been used to store >1M USD for different time periods. Safe as store of value is legitimate use.

The creator address is to create Safe wallet and do nothing else.The executor address is to execute Safe transactions and do nothing else.The Other address are empty wallet. No owner address looks like a normal wallet.

Having 1 account for creation, another for execution is not uncommon.
Also having accounts that arte empty for off chain signing is also quite common for Safe owners.

From all analysis above, we can conclude that all owner and Safe address are actually controlled by one person, i means, airdrop farmer.

Owning multiple Safes is not airdrop farming per se. Storing and moving funds in Safes, especially when they are of quite big value looks like quite legitimate use to me.
Please elaborate on how this is airdrop farming.

We haven't received any further information on this ticket and therefore deemed this submission invalid.
Unfortunately just the pure fact that Safes...

were created by the same address
have the same owner
conducted the same transactions
received assets from the same address

... is not enough reasoning for a valid submission, as there are legit user behaviour leading to such as well (relayer, scripts, power users, exchanges)
This submission didn't provide sufficient indicators to convince the team that there is some targeted airdrop farming behind the provided addresses. As per the rules, when in doubt we will default in favor of the airdrop recipients in order to not risk any false positives when sorting out airdrop hunters.


Only standard AWS S3 endpoints are currently supported

As-is, django-pglone supports AWS S3 services at standard AWS endpoints, but does not allow for other S3 provider endpoints (DigitalOcean Spaces, self-hosted S3, etc).
While AWS CLI does not provide an environmental variable to adjust the endpoint url, the CLI itself offers the --endpoint-url option which can update the endpoint url (https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html).
Recommend adding an additional setting which will then be used to set the endpoint url, if provided.
An example usage of this option in the AWS CLI can be found in the "Solution" section of this document: https://repost.aws/knowledge-center/s3-could-not-connect-endpoint-url.

Thanks for the fix! This was deployed in v2.5.0


fix: (`ts/padding-line-between-statements` removing blank line between functions in interface not working #71)

 Submitted with StackBlitz.

Could you add some tests for it? Thanks


Release Google.Cloud.CertificateManager.V1 version 2.4.0

Changes in this release:
No API surface changes; just dependency updates.

Created release for Google.Cloud.CertificateManager.V1-2.4.0


Helm chart for k8s deployment

Feature: Helm chart for Kubernetes deployment
Description
Context
Helm is a popular package manager for Kubernetes. It basically templates the to-be-deployed configuration yaml's of the kubernetes resources. This would be a good approach to deploy the community server on Kubernetes. It spares the server deployer of writing boiler yaml's.
Use case/problem
This helm chart would be used to manage the deployment to k8s. Problem is that no such chart exists yet.
Existing solutions
Efforts have been made to ease the deployment using Kustomize (the other k8s package manager): https://github.com/gobengo/node-solid-server-k8s, but lack community support.
Proposal
Create a Helm chart repo for the Solid Community server that follows best practices (https://helm.sh/docs/chart_best_practices/conventions/ and https://helm.sh/docs/chart_template_guide/getting_started/).

No I'm not. I used Nomad in the past (alternative for Kubernetes) but it was overkill for my setup.
Currently, I run everything on plain Alpine Linux boxes.

@Falx (or @MisterTimn) can you do a PR adding a single line to the README pointing to the chart (somewhere near the Docker entry)? We can close this afterwards.


init-project

General Checklist:

[ ] Tests added for this feature/bug

[ ] All tests are passed

[ ] No lint error

Review

[ ] Has been reviewed

[ ] Conform by the [merge request performance guides]

[ ] Conform by the [style guides]

[ ] Squashed related commits together

Tasks Checklist

[ ] Study requirement
[x] Add labels
[x] Add github template
[ ] travis: switch to coverall service
[ ] README: add badge

What are the relevant issue numbers?

Codecov Report

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

@@           Coverage Diff           @@
##             master     #1   +/-   ##
=======================================
  Coverage          ?   100%
=======================================
  Files             ?      1
  Lines             ?      1
  Branches          ?      1
=======================================
  Hits              ?      1
  Misses            ?      0
  Partials          ?      0

Impacted Files
Coverage Δ

src/index.js
100% <100%> (ø)

Continue to review full report at Codecov.

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


Does jest support proxy external script like <script src='http://localhost:8080/foo.js'></script>

💬 Questions and Help
I'm trying to write test for a utils that load external js by <script>, but I don't want this test case is rely on a real remote js file.
What I want to do is proxy <script> 's load behavior but didn't find a way do it.
Could anyone give some tips about it?

Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.


Will there ever be a time when ./scripts/build.sh will pass and cargo build --release will fail?

Wondering if both the build script and cargo build are needed simply to verify that the module is correct. If the wasm build is successful than the llvm build should be successful too. The reason this matters is that the build script has close-enough-to-instant results that it doesn't delay the tutorial. However building with cargo takes considerably longer since it requires a good deal more packages, and thus ruins the flow of working through this tutorial.
So long as the next step isn't using Polkadot, users should be able to just use the build script to verify that the module is compiling properly and than move onto the next section. cargo should only be needed if the next step is to actually run substrate.

@pard68 It is possible one passes while the other does not since cargo build --release depends on the STD libraries while ./scripts/build.sh will not. But you are right, any issues at that level are kind of outside the scope of the tutorial, and really you should expect that if the Wasm builds, you are good to move on.
In general, bother build.sh and cargo build --release should be pretty fast once you get over the hump of building it the first time. You are right cargo build --release is only needed when you actually run your node (and in some cases you may not even need to rebuild it, you could just do a WASM upgrade).
I think your point is valid though, minutes can be saved by having users skip over the cargo build --release step, I could probably make that whole thing more clear in the tutorial by really going into detail about what each thing does, and why.
Do you have a suggestion where you would like to see a change made to make this more clear?

This seems like a good place to me https://shawntabrizi.com/substrate-collectables-workshop/#/0/common-patterns-moving-forward

I have encountered cases where ./scripts/build.sh will give me a rust compiler error and say that 'std' does not exist, but then I run cargo build --release, and it works fine. What does this mean?

Yea the spot @JoshOrndorff mentioned is where I was thinking of making this point.


fix dropback to empty tree

after DragStart, checking "isEmpty" on source tree should exclude the currently dragging node.
#885

Related #908

This doesn't seem to work for me. The empty placeholder is still removed from the DOM when hovering an item from another tree over it. But removing line 1140 targetNode.place(placeElm); seems to do the trick.


4.7, 4.8 , 4.9

@saswatpp would be happy to review. But first please follow file naming conventions. i.e the full names of each section. These are minor things to keep in mind.
So,
backprop.ipynb will become "Forward_Propagation_Backward_Propagation_and_Computational Graphs.ipynb"
and similarly "Numerical_Stability_and_Initialization.ipynb"
and "Environment.ipynb"

Files renamed 👍

@saswatpp There are a lot of faults in the text and converting them to PyTorch is to be done. I am closing this. Ask @rsinghal757 to review your work on your own fork before opening a PR again. Please don't make a PR before it is clean and is PyTorch ready. Thanks for your efforts, I hope changes will be accommodated.


fix: @types/jsdom error coming up through stenciljs build

Most likely we can't make this run after installing node packages via npm i automatically, as this event / hook has been disabled by npm and you would need to run it manually in case of experiencing the same problem described in the related ticket https://github.com/db-ui/elements/issues/2094.
This is most likely not related to StencilJS itself, but the jest-preset-angular that includes an older @types/jsdom version through its jest-environment-jsdom dependency.
Resolves https://github.com/db-ui/elements/issues/2094

You need to fix the package.json conflict

You need to fix the package.json conflict @mfranzke

done


fix: Ignore invalid textureId in captureOutput

This PR checks textureId in beginning of captureOutput to avoid Unexpected exception in macOS.
In my demo app, it seems to work as expected.

I think this fix may also need to be applied in the corresponding place in ios/Classes/MobileScanner.swift.   Thanks.


Add plugin source code and build.sh to create zip file

The following 5 images aren't properly optimized

view/img/valitor.svg should probably be deleted


Bump Docker in CircleCI to 1.10

Fixes #2182

The change is causing integration tests to fail. I am going to revert to Net 1.8.2 instead  until I figure this out.

Superseded by https://github.com/weaveworks/scope/pull/2190


build: add CSI_IMAGE_VERSION to build.env

CSI_IMAGE_VERSION is needed by the centos CI to push the image to the minikube VM.
Signed-off-by: Madhu Rajanna<EMAIL_ADDRESS>

/test ci/centos/mini-e2e/k8s-1.19

E1209 08:52:05.819166       1 controller.go:966] error syncing claim "d9555879-a3c8-4363-9c4d-eae283087beb": failed to provision volume with StorageClass "csi-rbd-sc": rpc error: code = InvalidArgument desc = invalid encryption kms configuration: missing encryption passphrase in secrets

Failed with encryption

/test ci/centos/mini-e2e-helm/k8s-1.18


Fix build when nvtools is missing

Rather than adding all the TORCH_LIBRARIES to a target explicitly, we add a dependency on the torch target and torch_python_LIBRARY.  This should allow cmake to pick up the dependencies of torch and torch_python_LIBRARY without the need to explicitly enumerate them.  Since nvtools is not required, it should not throw an error since it is not listed explicitly.
I was able to reproduce the issue from #3673 using a fresh conda environment and made sure that the build was successful after making these changes.
Also fixed a typo in the comment for define_gpu_extension_target.

I did a quick search over the built library _C.cpython-39-x86_64-linux-gnu.so and _moe_C.cpython-39-x86_64-linux-gnu.so , it seems they are dependent on:

libtorch.so
libc10.so
libc10_cuda.so
libtorch_python.so
libtorch_cpu.so
libtorch_cuda.so

This PR seems to only add libtorch , right? What about libc10 stuff?

I did a quick search over the built library _C.cpython-39-x86_64-linux-gnu.so and _moe_C.cpython-39-x86_64-linux-gnu.so , it seems they are dependent on:

libtorch.so
libc10.so
libc10_cuda.so
libtorch_python.so
libtorch_cpu.so
libtorch_cuda.so

This PR seems to only add libtorch , right? What about libc10 stuff?

The torch used here refers to the cmake target and not just the libtorch.so library.  AFAICT, it pulls in all the required dependencies.  I could see all the expected libraries in the linker command when I built.

seems like tests are failing :(

seems like tests are failing :(

I think it's fixed now.


[Bug]: Cart IDs for anonymous users do not get persisted in any way

Expected Behavior
I expect that when I add something to the basket as an anonymous user to have the cart id persisted as a cookie.
Actual Behavior
No ID gets persisted, which on refresh causes the basket to get lost. Upon adding a new item, an entirely new cart id is returned
Possible Solution
No response
Steps to reproduce
I have cloned this repo and run everything from the current latest code on the "develop" branch. I have also run Vendure locally using an SQLite database. The way I've scaffolded Vendure is as their "Getting Started" documentation page recommends, through the CLI.
It's worth noting that before I tried to run Vue Storefront from the development branch here, I also tried with a scaffolded version from the VSF CLI (v2.4.1).
What version of vendure integration are you using?
1.0.0
What version of Node.js are you using?
16.14.2
What browser (and version) are you using?
Chrome
What operating system (and version) are you using?
macOS Monterey 12.3 on Vanilla M1
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi, just to check - did you set the authOptions.tokenMethod to 'bearer' in your Vendure config as instructed here?

Hi, just to check - did you set the authOptions.tokenMethod to 'bearer' in your Vendure config as instructed here?

Seems like I've missed reading this part... Added it and seems to be working like a charm now.

Resolved. Closing


InteractiveView error

Launching lib\main.dart on SM G920F in debug mode...
Running Gradle task 'assembleDebug'...
Compiler message:
/C:/flutter/.pub-cache/hosted/pub.dartlang.org/graphite-0.2.3/lib/graphite_edges.dart:99:18: Error: The method 'InteractiveViewer' isn't defined for the class '_GraphiteEdgesState'.

'_GraphiteEdgesState' is from 'package:graphite/graphite_edges.dart' ('/C:/flutter/.pub-cache/hosted/pub.dartlang.org/graphite-0.2.3/lib/graphite_edges.dart').
Try correcting the name to the name of an existing method, or defining a method named 'InteractiveViewer'.
child: InteractiveViewer(
^^^^^^^^^^^^^^^^^

Compiler message:
/C:/flutter/.pub-cache/hosted/pub.dartlang.org/graphite-0.2.3/lib/graphite_edges.dart:99:18: Error: The method 'InteractiveViewer' isn't defined for the class '_GraphiteEdgesState'.

'_GraphiteEdgesState' is from 'package:graphite/graphite_edges.dart' ('/C:/flutter/.pub-cache/hosted/pub.dartlang.org/graphite-0.2.3/lib/graphite_edges.dart').
Try correcting the name to the name of an existing method, or defining a method named 'InteractiveViewer'.
child: InteractiveViewer(
^^^^^^^^^^^^^^^^^
Target kernel_snapshot failed: Exception: Errors during snapshot creation: null
build failed.

gradle-6.7

@sante85 what flutter version are you using?


Re-factor the EventBus and isInAutomation handling (PR 11655 follow-up)

Rather than forcing the "regular" EventBus to check and handle isInAutomation for every dispatch call, we can take advantage of subclassing instead.
Hence this PR introduces a new AutomationEventBus class, which extends EventBus, and is used by the default viewer when isInAutomation === true.

/botio unittest

/botio integrationtest

Thank you for simplifying this!


TypeError in /clan/tu-fei-xiao-lian-meng-pypcv2cq

Error in ClashLeaders
TypeError in /clan/tu-fei-xiao-lian-meng-pypcv2cq
Cannot read property 'iconUrls' of undefined
View on Bugsnag
Stacktrace
https://www.clashleaders.com/static/js/details-page.3ea4fdc3340752e70581.js:1 - u

View full stacktrace
Created automatically via Bugsnag

An error linked to this issue has been marked as fixed in Bugsnag
TypeError in /clan/tu-fei-xiao-lian-meng-pypcv2cq

An error linked to this issue has been reopened in Bugsnag
TypeError in /clan/tu-fei-xiao-lian-meng-pypcv2cq

An error linked to this issue has been marked as fixed in Bugsnag
TypeError in /clan/tu-fei-xiao-lian-meng-pypcv2cq


Release job to publish tower-cli to homebrew

This PR will add the release job to publish tower-cli to homebrew

add jreleaser PAT to build.yml
add brew packager to jreleaser.yml

@jordeu Please review, you can refer to the same working config in wave-cli
https://github.com/seqeralabs/wave-cli/blob/d72d2c580cc1ce25ab61d7ed5a1474d0f6c31467/jreleaser.yml#L110-L119

@pditommaso  ready for you

I'm not the one reviewing this

@jordeu  ready for merge then, I reckon :-)

Thanks @jordeu !  @munishchouhan , the Brew formulas will be generated at the next release, right?
Jordi, would this be a good reason to actually release a new version, and promote that it is now available via Homebrew?

Jordi, would this be a good reason to actually release a new version, and promote that it is now available via Homebrew?

I am not in charge of this project

oh thank you Jordi!   @JaimeSeqLabs   for you then 💥🚀

would this be a good reason to actually release a new version, and promote that it is now available via Homebrew?


Finding local kubectl version either requires timeout or deprecated option (?)

What happened:

I wanted to find out the version of kubectl I have installed, even though I have no selected context.
I wanted to find out the version of kubectl I have installed, even though I have a current context that is offline.

Sample console sessions:
laptop:~$ kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.24.0
Kustomize Version: v4.5.4
Unable to connect to the server: dial tcp <IP_ADDRESS>:443: connect: no route to host

$ kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.24.0
Kustomize Version: v4.5.4
The connection to the server localhost:8080 was refused - did you specify the right host or port?

$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"4ce5a8954017644c5420bae81d72b09b735c21f0", GitTreeState:"clean", BuildDate:"2022-05-03T13:46:05Z", GoVersion:"go1.18.1", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.4
The connection to the server localhost:8080 was refused - did you specify the right host or port?

What you expected to happen:
Something like:

kubectl version shows the client version only.
kubectl version --client does not show any warning.

For example:
$ kubectl version
Client Version: v1.24.0
Kustomize Version: v4.5.4

$ kubectl version --client
Client Version: v1.24.0
Kustomize Version: v4.5.4

It's OK to have kubectl version --include-cluster-info or kubectl version --remote show the remote version too.
I would also be OK if kubectl version only checked the remote version when a current context is explicitly set (no fallback to an implicit server URL).
How to reproduce it (as minimally and precisely as possible):

Visit https://kubernetes.io/docs/tasks/tools/#kubectl
Install kubectl as instructed and, on a vanilla system, check the kubectl version.

Anything else we need to know?:
As a project, we need a way for people who are setting up a brand new kubectl to confirm that they have a working and current kubectl.
It's very helpful if this confirmation step doesn't require explaining that there is a warning: it's good practice not to have people become accustomed to seeing and then skipping warning messages.
Environment:

Kubernetes client and server versions (use kubectl version): v1.24.0
Cloud provider or hardware configuration: n/a
OS (e.g: cat /etc/os-release): Linux, but relevant to all OSs

Prompted by https://github.com/kubernetes/website/issues/33764

Is is reasonable to get the client version by running kubectl version -oyaml --client? The example output is:
{
  "clientVersion": {
    "major": "1",
    "minor": "24",
    "gitVersion": "v1.24.0",
    "gitCommit": "4ce5a8954017644c5420bae81d72b09b735c21f0",
    "gitTreeState": "clean",
    "buildDate": "2022-05-03T13:36:49Z",
    "goVersion": "go1.18.1",
    "compiler": "gc",
    "platform": "darwin/amd64"
  },
  "kustomizeVersion": "v4.5.4"
}

We could extract the kubectl version like the following:
$ kubectl version -oyaml --client|awk '/gitVersion/{print $2;}'
v1.24.0

Actually, we could mention that both

It sounds like this is expected behavior, and that we should document the warning as something for readers to be aware of and ignore if they are deploying v1.24 kubectl.

I believed that kubectl version -oyaml --client is deprecated because --client is deprecated.

Nope, the deprecated flag is actuall --short as the output of kubectl version --short would become the default in the future, the flag --client is not deprecated.

we should document the warning as something for readers to be aware of and ignore if they are deploying v1.24 kubectl.

Yeah that would be great.

the flag --client is not deprecated

$ kubectl version --client
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"4ce5a8954017644c5420bae81d72b09b735c21f0", GitTreeState:"clean", BuildDate:"2022-05-03T13:46:05Z", GoVersion:"go1.18.1", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.4

I think people will see that and think that kubectl version --client is deprecated: they run it, and they see a deprecation warning.

I think people will see that and think that kubectl version --client is deprecated

Ah that's because --short is set by default and is deprecated now, so users would see this warning.

As discussed on slack, and earlier today during bug scrub, we need to:

document that the deprecation warning is expected
document for first timers not having cluster to use --client.

@sftim I looked into when you hit 30s timeout, that's when you have invalid kubeconfig pointing to a valid host but wrong port, in all other cases (missing host, missing kubeconfig, invalid host) you should get instant response.
/triage accepted
/help-wanted

/reopen
This issue was accepted
/remove-lifecycle rotten


I couldn't build 0.7 alpha3

Hello
Thank you for improving so much.
I tried to build this version on windows 10 and VS2015. but I couldn't.
Error Messages like below

C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets(140,5): error : Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win": { } }' to your project.json and then re-run NuGet restore.

I googled and found msbuild issue.
https://github.com/Microsoft/msbuild/issues/394
How should I solve this?
Thank you
Nao

@yfakariya
After adding "runtimes" , I can build with some warnings.
Is it right solution?

Which project do you see above error?

msgpack(4.6) it is

OK, this is caused by trushes for previous .NET Core build items(project.json and xproj).
Actually, I've not opened from VS2015 for that project.
Try pull latest branch, unload msgpack project, reload it, and then build.
Thank you for reporting!

Thank you for fixing.
I've just confirmed.


When bulk signing, sign all versions' files, don't bump unsigned files (bug 1156768)

Fixes bug 1156768

r+


[ISSUE #6321] optimize yaml parse code

Make sure set the target branch to develop
What is the purpose of the change

fix #6321
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Codecov Report

Merging #6322 (7e7b35f) into develop (9a7d095) will increase coverage by 0.02%.
The diff coverage is 91.01%.

@@              Coverage Diff              @@
##             develop    #6322      +/-   ##
=============================================
+ Coverage      43.11%   43.13%   +0.02%
- Complexity      8857     8865       +8
=============================================
  Files           1094     1095       +1
  Lines          77284    77301      +17
  Branches       10085    10085
=============================================
+ Hits           33319    33346      +27
+ Misses         39796    39793       -3
+ Partials        4169     4162       -7

Impacted Files
Coverage Δ

.../java/org/apache/rocketmq/acl/common/AclUtils.java
70.92% <ø> (ø)

...che/rocketmq/acl/plain/PlainPermissionManager.java
78.31% <88.40%> (+0.09%)
:arrow_up:

...org/apache/rocketmq/acl/plain/PlainAccessData.java
100.00% <100.00%> (ø)

... and 23 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@yuz10 Pls fix spotbug error:
[INFO] --- spotbugs-maven-plugin:4.2.2:check (check) @ rocketmq-acl ---
[INFO] BugInstance size is 1
[INFO] Error size is 0
[INFO] Total bugs: 1
Error:  High: Class org.apache.rocketmq.acl.plain.PlainAccessData defines non-transient non-serializable instance field accounts [org.apache.rocketmq.acl.plain.PlainAccessData] In PlainAccessData.java SE_BAD_FIELD


Radio commands

you can now pass to Radio a LabelCommand and InputCommand insted an only componetCommand

Coverage decreased (-0.06%) to 98.447% when pulling 932cb0bfe0edae7007a46e78ed36cc36416ef9af on nacho into 70a2f389578d347848f59d41a72998e3c78879af on master.

Coverage decreased (-0.06%) to 98.447% when pulling 932cb0bfe0edae7007a46e78ed36cc36416ef9af on nacho into 70a2f389578d347848f59d41a72998e3c78879af on master.


persist log since time && dynamic routes adding

1、Logspout collects container log with sincetime. Once the process exits and starts again, there will be log loss before logspout restarts. So I wonder that logspout can persist the sincetime, then the process can restart with the persistent sincetime and will avoid losing logs.
2、Dynamic routes adding. When a new container start, logspout can get the specific env which describes the route wanted. And then the route can be added by itself.
If someone think these features are useful, I will work on it.

+1


Use the Alternate entry, if it exists, in ICCBased Colour Space dictionaries (issue 5836, issue 5939, issue 6055)

Fixes #5836.
Fixes #5939.
Fixes #6055.
The relevant part of the specification: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G7.3804856.

/botio-windows preview

Nice work! I couldn't quite figure out what was wrong, but I'm glad you did! One question though: the spec says, for the Alternate entry, that "non-conforming readers may use this colour space". It sounds like we should check if the color space is unsupported and then fall back to the alternate color space, whereas in your patch we directly use the alternate color space without further checking. Personally I think that is fine, as it fixes the problems and the alternate entry is not specified for nothing, but do you think we need to do more checking, if even possible?

Good questions! I don't have very convincing answers, but this is my take on it:

[...], whereas in your patch we directly use the alternate color space without further checking.

I also thought about that when trying to make sense of the specification, but I don't know what that should look like while also fixing the referenced issues.
Without actual test-cases it seems difficult to be sure how this should be implemented, since just trying to adhere to the specification has shown to be a bit of a problem in practice :-)

[...], but do you think we need to do more checking, if even possible?

Ideally we probably should, but again without actual test-cases (i.e. PDF files found in the wild), that seems difficult to me.
Given that we currently have three example files that this patch fixes, and unfortunately quite poor test-coverage for this part of the code-base, I think I'd rather risk breaking some other PDF files with this change. At least that way, we might actually get test-cases to work with :-P

Agreed, and since mupdf and poppler also work exactly this way (see the ninja edit in my previous comment), this should be fine. I'll review and test this once the Windows bot is alive again.

Actually, based both on the specification and the implementation in mupdf, we should perhaps try to check that the number of components match? I'll check to see if that is simple to implement.

I've just uploaded a new version, which checks that the components match and (indirectly) that it's not a Pattern colour space. Unfortunately this requires, as far as I can see, that we parse the CS which is somewhat unfortunate. However, in the referenced PDF files, this doesn't seem to affect the rendering times in any noticeable way.
/botio-linux preview

One question though: the spec says, for the Alternate entry, that "non-conforming readers may use this colour space" [...]

Actually, the complete quote is:

(Optional) An alternate colour space that shall be used in case the one specified in the stream data is not supported. Non-conforming readers may use this colour space. [...]

Since we currently completely ignore the contents of the stream data, I think that just using the /Alternate CS, if it exists, is exactly the right thing to do here!
Having re-read the paragraph a few times, I think that we're now doing what the specification says here.

/botio-linux preview

/botio test

/botio-test windows

/botio-windows test

/botio makeref

Thank you!

@timvandermeij Thank you too!
Your questions prompted me to go back and really read the specification, which in my opinion significantly helped improve the quality of the final patch :-)

@timvandermeij Thank you too!
Your questions prompted me to go back and really read the specification; so you helped to significantly improve the quality of the final patch :-)


ip-reconciler: do not reconcile pods in Pending phase

Fixes: #162
Would you review / check if this works for you @xagent003 ?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 2 (50.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 40.734%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/reconciler/iploop.go
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.05%

Covered Lines:
444

Relevant Lines:
1090

💛  - Coveralls

/assign @xagent003

@maiqueb I tested with the slight change to logic as above, it is working. I added a temporary log in the new if clause to verify it is being hit. You can see the JSON parsing fails earlier due to missing network status, then we hit the new condition for Pending phase, and the IP is not removed.
2021-11-16T23:06:02Z [debug] NewReconcileLooper - Kubernetes config file located at: /host/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig
2021-11-16T23:06:03Z [debug] successfully read the kubernetes configuration file located at: /host/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig
2021-11-16T23:06:04Z [debug] listing IP pools
2021-11-16T23:06:04Z [debug] Added IP <IP_ADDRESS> for pod default/web-0
2021-11-16T23:06:04Z [debug] Added IP <IP_ADDRESS> for pod default/web-0
2021-11-16T23:06:04Z [error] could not parse network annotation  for pod: default/web-1; error: unexpected end of JSON input
2021-11-16T23:06:04Z [debug] the IP reservation: IP: <IP_ADDRESS> is reserved for pod: default/web-1
2021-11-16T23:06:04Z [debug] PF9: Skipping Pod IP check for Pending Pod: default/web-1 IP: <IP_ADDRESS>
2021-11-16T23:06:04Z [debug] the IP reservation: IP: <IP_ADDRESS> is reserved for pod: default/web-0
2021-11-16T23:06:04Z [debug] pod reference default/web-0 matches allocation; Allocation IP: <IP_ADDRESS>; PodIPs: map[<IP_ADDRESS>:{} <IP_ADDRESS>:{}]
2021-11-16T23:06:04Z [debug] the IP reservation: IP: <IP_ADDRESS> is reserved for pod: default/web-0
2021-11-16T23:06:04Z [debug] pod reference default/web-0 matches allocation; Allocation IP: <IP_ADDRESS>; PodIPs: map[<IP_ADDRESS>:{} <IP_ADDRESS>:{}]
2021-11-16T23:06:04Z [debug] the IP reservation: IP: <IP_ADDRESS> is reserved for pod: default/web-1
2021-11-16T23:06:04Z [debug] PF9: Skipping Pod IP check for Pending Pod: default/web-1 IP: <IP_ADDRESS>
2021-11-16T23:06:04Z [debug] pod reference default/web-0 matches allocation; Allocation IP: <IP_ADDRESS>; PodIPs: map[<IP_ADDRESS>:{} <IP_ADDRESS>:{}]
2021-11-16T23:06:04Z [debug] PF9: Skipping Pod IP check for Pending Pod: default/web-1 IP: <IP_ADDRESS>
2021-11-16T23:06:04Z [debug] pod reference default/web-0 matches allocation; Allocation IP: <IP_ADDRESS>; PodIPs: map[<IP_ADDRESS>:{} <IP_ADDRESS>:{}]
2021-11-16T23:06:04Z [debug] PF9: Skipping Pod IP check for Pending Pod: default/web-1 IP: <IP_ADDRESS>
2021-11-16T23:06:04Z [debug] no IP addresses to cleanup


Update build

The build xml is still the old phing build and the new Jenkinsfile and build folder are missing and should be added.

Also the generated build folders should be added to .gitignore


Different behaviour between BC and Java on X509v3 extensions value

I've notice a different behaviour between java.security.cert.CertificateFactory and org.bouncycastle.jcajce.provider.asymmetric.x509.CertificateFactory when resolving X509v3 extensions.
byte[] certificate = load("certificate.crt.pem")

X509Certificate jdkCertificate =
  (X509Certificate)
    java.security.cert.CertificateFactory.getInstance("X.509")
      .generateCertificate(new ByteArrayInputStream(certificate));
X509Certificate bouncyCastleCertificate =
  (X509Certificate)
    new org.bouncycastle.jcajce.provider.asymmetric.x509.CertificateFactory()
      .engineGenerateCertificate(new ByteArrayInputStream(certificate));

byte[] jdkResult =
  jdkCertificate.getExtensionValue(OCSPObjectIdentifiers.id_pkix_ocsp_nocheck.getId());
byte[] bouncyCastleResult =
  bouncyCastleCertificate.getExtensionValue(
  OCSPObjectIdentifiers.id_pkix_ocsp_nocheck.getId());

Assertions.assertThat(jdkResult).isEqualTo(new byte[] {4, 0});
Assertions.assertThat(bouncyCastleResult).isEqualTo(new byte[] {4, 2, 5, 0});

Analysing the certificate with openssl return the following extensions section:
X509v3 extensions:
    X509v3 Extended Key Usage: critical
        OCSP Signing
    OCSP No Check:

Java version: java version "15.0.2" 2021-01-19
openssl version: OpenSSL 1.1.1f  31 Mar 2020
Bouncy castle versions: org.bouncycastle:bcpkix-jdk15on:1.68 and org.bouncycastle:bcprov-jdk15on:1.68

I'm not able to understand what's happening there. Is it a "normal" diff ? Is it a bug in BC or in the JDK ?

Can you provide the certificate?

Yes: certificate.txt

Okay, so a dump shows:
703:d=5  hl=2 l=   9 prim: OBJECT            :OCSP No Check
714:d=5  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:0500
which is what you would expect from RFC 6960 section <IP_ADDRESS>.1. So the BC provider is giving you the most accurate description of what is going on. I'm not really sure what the JVM version is doing here, I'd guess it's doing some special handling, possibly treating ASN.1 NULL as a Java null rather than an actual value (we've found it's best to keep Java null to mean absent, but I can see how people would think they were equivalent). They have changed the extension value though, the octet string being returned is clearly not what is in the certificate.

Closed as not a BC bug.