Release v1.5.1

name: 'Release Checklist Template'
about: 'Checklist to create and publish a Zebra release'
title: 'Release Zebra (version)'
labels: 'A-release, C-trivial, P-Critical :ambulance:'
assignees: ''

Prepare for the Release

[x] Make sure there has been at least one successful full sync test since the last state change, or start a manual full sync.
[x] Make sure the PRs with the new checkpoint hashes and missed dependencies are already merged.
(See the release ticket checklist for details)

Summarise Release Changes
These steps can be done a few days before the release, in the same PR:
Change Log
Important: Any merge into main deletes any edits to the draft changelog.
Once you are ready to tag a release, copy the draft changelog into CHANGELOG.md.
We use the Release Drafter workflow to automatically create a draft changelog. We follow the Keep a Changelog format.
To create the final change log:

[x] Copy the latest draft changelog into CHANGELOG.md (there can be multiple draft releases)
[x] Delete any trivial changes

[x] Put the list of deleted changelog entries in a PR comment to make reviewing easier

[x] Combine duplicate changes
[x] Edit change descriptions so they will make sense to Zebra users
[x] Check the category for each change

Prefer the "Fix" category if you're not sure

README
README updates can be skipped for urgent releases.
Update the README to:

[x] Remove any "Known Issues" that have been fixed since the last release.
[x] Update the "Build and Run Instructions" with any new dependencies.
Check for changes in the Dockerfile since the last tag: git diff <previous-release-tag> docker/Dockerfile.
[x] If Zebra has started using newer Rust language features or standard library APIs, update the known working Rust version in the README, book, and Cargo.tomls

You can use a command like:
fastmod --fixed-strings '1.58' '1.65'

Create the Release PR

[x] Push the updated changelog and README into a new branch
for example: bump-v1.0.0 - this needs to be different to the tag name
[x] Create a release PR by adding &template=release-checklist.md to the comparing url (Example).
[x] Freeze the batched queue using Mergify.
[x] Mark all the release PRs as Critical priority, so they go in the urgent Mergify queue.
[x] Mark all non-release PRs with do-not-merge, because Mergify checks approved PRs against every commit, even when a queue is frozen.

Update Versions and End of Support
Update Zebra Version
Choose a Release Level
Zebra follows semantic versioning. Semantic versions look like: MAJOR.MINOR.PATCH[-TAG.PRE-RELEASE]
Choose a release level for zebrad. Release levels are based on user-visible changes from the changelog:

Mainnet Network Upgrades are major releases
significant new features or behaviour changes; changes to RPCs, command-line, or configs; and deprecations or removals are minor releases
otherwise, it is a patch release

Zebra's Rust API doesn't have any support or stability guarantees, so we keep all the zebra-* and tower-* crates on a beta pre-release version.
Update Crate Versions
If you're publishing crates for the first time, log in to crates.io,
and make sure you're a member of owners group.
Check that the release will work:

[x] Update crate versions, commit the changes to the release branch, and do a release dry-run:

cargo release version --verbose --execute --allow-branch '*' --workspace --exclude zebrad --exclude zebra-scan beta
# Due to a bug in cargo-release, we need to pass an exact version here
cargo release version --verbose --execute --allow-branch '*' --package zebra-scan 0.1.0-alpha.1
cargo release version --verbose --execute --allow-branch '*' --package zebrad patch # [ major | minor | patch ]
cargo release replace --verbose --execute --allow-branch '*' --package zebrad
cargo release commit --verbose --execute --allow-branch '*'

Crate publishing is automatically checked in CI using "dry run" mode.
Update End of Support
The end of support height is calculated from the current blockchain height:

[x] Find where the Zcash blockchain tip is now by using a Zcash explorer or other tool.
[x] Replace ESTIMATED_RELEASE_HEIGHT in end_of_support.rs with the height you estimate the release will be tagged.

Optional: calculate the release tagging height

Add 1152 blocks for each day until the release
For example, if the release is in 3 days, add 1152 * 3 to the current Mainnet block height

Update the Release PR

[x] Push the version increments and the release constants to the release branch.

Publish the Zebra Release
Create the GitHub Pre-Release

[x] Wait for all the release PRs to be merged
[x] Create a new release using the draft release as a base, by clicking the Edit icon in the draft release
[x] Set the tag name to the version tag,
for example: v1.0.0
[x] Set the release to target the main branch
[x] Set the release title to Zebra  followed by the version tag,
for example: Zebra 1.0.0
[x] Replace the prepopulated draft changelog in the release description with the final changelog you created;
starting just after the title ## [Zebra ... of the current version being released,
and ending just before the title of the previous release.
[x] Mark the release as 'pre-release', until it has been built and tested
[x] Publish the pre-release to GitHub using "Publish Release"
[x] Delete all the draft releases from the list of releases

Test the Pre-Release

[x] Wait until the Docker binaries have been built on main, and the quick tests have passed:

[x] ci-unit-tests-docker.yml
[x] ci-integration-tests-gcp.yml

[x] Wait until the pre-release deployment machines have successfully launched

Publish Release

[x] Publish the release to GitHub by disabling 'pre-release', then clicking "Set as the latest release"

Publish Crates

[x] Run cargo login
[x] Run cargo clean in the zebra repo (optional)
[ ] Publish the crates to crates.io: cargo release publish --verbose --workspace --execute
[ ] Check that Zebra can be installed from crates.io:
cargo install --locked --force --version 1.minor.patch zebrad && ~/.cargo/bin/zebrad
and put the output in a comment on the PR.

Publish Docker Images

[ ] Wait for the the Docker images to be published successfully.
[ ] Un-freeze the batched queue using Mergify.
[ ] Remove do-not-merge from the PRs you added it to

Release Failures
If building or running fails after tagging:

Tag a new release, following these instructions...

Fix the bug that caused the failure
Start a new patch release
Skip the Release Preparation, and start at the Release Changes step
Update CHANGELOG.md with details about the fix
Follow the release checklist for the new Zebra version

Removed from changelog:
Trivial TODO: put this in a PR comment, not the CHANGELOG

Make sure scanner database is accessed using the correct types (#8112)
Move history tree and value balance to typed column families (#8115)
Update copyright year to 2024 (#8134)
build(deps): bump jsonrpc from 0.16.0 to 0.17.0 (#8139)
build(deps): bump the devops group with 2 updates (#8147)
build(deps): bump the devops group with 2 updates (#8126)
build(deps): bump the devops group with 2 updates (#8100)
build(deps): bump the devops group with 3 updates (#8120)
build(deps): bump the prod group with 3 updates (#8158)
build(deps): bump the prod group with 4 updates (#8117)
build(deps): bump the prod group with 5 updates (#8138)
build(deps): bump the prod group with 6 updates (#8125)
build(deps): bump zerocopy from 0.7.30 to 0.7.31 (#8111)
change(doc): Document how to add a column family (#8149)
change(doc): Refactor user & dev docs (#8145)
cleanup: Fix unused code lints (#8148)
fix(ci): revert script changes causing workflow failures (#8133)
fix(doc): Add shielded-scan.md to the index (#8095)
fix(elasticsearch): Make bulk size the same for testnet and mainnet (#8127)
fix(test): Ignore segmentation fault errors when shutting down Docker in tests (#8107)
fix(workflows): mass rename worflows to fix readme badges (#8116)
ref(workflow): move most scripts to their own executables (#8005)
refactor: remove obsolete clippy allows in non_finalized_state (#8140)
test(scan): Add raw database format snapshots to the scanner (#8075)
test(scan): Add typed database format snapshots to the scanner (#8083)
test: Add progress markers to the snapshot tests (#8106)
tests(sinsemilla): Minor changes to sinsemilla tests (#8128)

Also removed:
Breaking Changes
This release has the following breaking changes:

Add a scanning results reader (#8104)
add(docs): Note default path to config in docs (#8143)
change(scan): Refactor the user documentation for scanning  (#8124)
fix(scan): Fix the RPC tx fetching in the scanning results reader (#8157)

Security

build(deps): bump zerocopy from 0.7.30 to 0.7.31 (#8111)

Temporal failure, retrying: https://github.com/ZcashFoundation/zebra/actions/runs/7574761722/job/20630635394?pr=8165#step:15:96

I noticed we mention in the release notes that this release adds the reader of the scanning results, but the PR is excluded from the changelog.

I edited the lists of PRs not included in the changelog in the comment above to reflect the changes we made in the review.

There is a problem with the publication of the zebra-chain crate and i am not sure how to proceed.
Only the zebra-test crate was upgraded by now because the command cargo release publish --verbose --workspace --execute fails publishing zebra-chain:
  Publishing zebra-chain
    Updating crates.io index
   Packaging zebra-chain v1.0.0-beta.33 (/home/oxarbitrage/zebra/release-1.5.1/main_with_release/zebra/zebra-chain)
   Verifying zebra-chain v1.0.0-beta.33 (/home/oxarbitrage/zebra/release-1.5.1/main_with_release/zebra/zebra-chain)
    Updating crates.io index
error: failed to verify package tarball

Caused by:
  failed to select a version for `equihash`.
      ... required by package `zebra-chain v1.0.0-beta.33 (/home/oxarbitrage/zebra/release-1.5.1/main_with_release/zebra/target/package/zebra-chain-1.0.0-beta.33)`
  versions that meet the requirements `^0.2.0` are: 0.2.0

  the package `zebra-chain` depends on `equihash`, with features: `solver` but `equihash` does not have these features.

  failed to select a version for `equihash` which could resolve this conflict

This seems to be a problem introduced with the internal miner.
I can try to publish the rest of the crates but i think we will have to make a hotfix(1.5.2) anyway.

An easier way could be to use the --no-verify flag described in https://crates.io/crates/cargo-release.
If that works we can publish as it is and fix for the next release.


Fix connect README links

Noticed that a few of the links in the web5.connect([options]) section didn't work. Updating to fix!

Hey @amika-sq -- thanks for the updates.
There was a massive refactor in 0.7.0 that includes so many changes that a lot of the docs will have to be updated.


Improve default failed equality match output to more clearly show diffs

Hi, maintainers!  I would like to express my sincere gratitude for your efforts in maintaining gomock.
Requested feature
Is the issue https://github.com/golang/mock/issues/616 resolved? If not, i hope improvement the diffs when tests fails.
I didn't find out whether the problem resolved or not as the original repository has the issue archived and cannot ask there.
Why the feature is needed
As showing the original issue, it is often hard to understand and interpret the diffs.
(Optional) Proposed solution
i think we can solve this problem by using the method indicated in the following comments:

https://github.com/golang/mock/issues/616#issuecomment-1081616088
https://github.com/golang/mock/issues/616#issuecomment-1081616088

Alternatively, adding an option to change the default matcher may resolve this, as it would allow for the use of this way.

The current diff output is pretty low readability. Would love to see the https://github.com/golang/mock/issues/616#issuecomment-1081616088 or something similar implemented.


Error using docker-compose + carina

I'm using Carina, which means I'm calling docker-compose remotely and I can't seem to get the companion to work. I'm getting errors similar to the following:
https_container | Error: can't get nginx-proxy container id !
https_container | Check that you use the --volumes-from option to mount volumes from the nginx-proxy.
https_container | Error response from daemon: no such id: a8a0fb896a6fc06c7315900011020d6b632b6779139f8a48f71fc8c941079910:rw

Any ideas? What's odd is that the hash value matches. So if I run docker ps, I see a8a0fb896a6f.
I'm going to try without docker-compose next. I'll keep you posted.

Well, it appears to work when I use just the docker command :-/ Hmmm.

@DanTheColoradan I'm having the exact same issue with docker-compose. Have you been able to resolve it?

@DanTheColoradan @JrCs Tracked down the issue. This pull request fixes it!

:clap: awesome.


setup the playlist model serializers for the playlist endpoint of the plugin

setup the playlist model serializers for the playlist endpoint of the plugin

Created Playlist Serializers that allows complex data such as querysets and model instances to be converted to native Python datatypes that can then be easily rendered into JSON , or other content types.


how to define species observation from non-free-ranging animals

Tracking data often represent deployments from homing and navigation experiments that should not be assumed to be movements of free-ranging animals or used to interpret species distributions. Is there a clear way to identify this in DwC or on GBIF?

Answer by @albenson-usgs:

AB: This is a good question and I don’t have a definitive answer. I would say this could go in extended measurement or fact but I’m wondering if others have an opinion.

Just like outliers (#1) it would be neat to identify this at the occurrence level, so aggregators and users can easily filter those. Ideas (but probably not very good ones):

basisOfRecord: LivingSpecimen
establishmentMeans: managed

@tucotuco, I'd like to have your opinion on this.

@peterdesmet   Your proposal seems quite reasonable. Those are the values I would expect for a zoo animal, for example.

Seems like the best option to me too.

@timrobertson100 @tucotuco Just to be clear, the proposal to use LivingSpecimen, to use establishmentMeans: managed or both?
The definition for establishmentMeans: managed is:

Subclass of introduced: The organism maintains its presence through intentional cultivation or husbandry.

Imo, using establishmentMeans for occurrences has had mixed results and "subclass of introduced" might not be what people expect for all use cases (e.g. tracked wolf in captivity close to national park where it naturally occurs).

LivingSpecimen seems like a better (and easier) way to label those occurrences (i.e. known category to exclude when looking for natural occurrences) but those records are also MachineObservations, so how do you indicate that? For reference, this is how we propose to populate basisOfRecord for tracking data:

Kind of event
free range
in captivity

capture
HumanObservation
HumanObs or LivingSpecimen ?

tagging & release
HumanObservation
HumanObs or LivingSpecimen ?

position recorded by device
MachineObservation (lots of them)
MachineObs or LivingSpecimen (lots of them) ?

recapture
HumanObservation
HumanObs or LivingSpecimen ?

I see better now where you are going with this. I would keep basisOfRecord completely independent of the establishmentMeans. Observations should be used for records that have no physical evidence - so everything on your list would be Observations for basisOfRecord, unless a sample was taken, or unless it was the "end of the line" (specimen collected).  The rest sounds like the vocabularies being discussed are insufficient. I think I would focus energy there to see if you can define values that differentiate the cases that are important.

The intent of establishmentMeans was, "Why was the thing there?", so that, to me, is the right term. The bothersome part of the definition is "established". Is an individual involved in a homing experiment "established"? If we can get beyond that, I think this is the right term. I think we can get beyond that with a modified definition for establishmentMeans, examples, and a solid vocabulary that addressed the use cases you are facing.

@tucotuco: 👌
@timrobertson/@pieterprovoost, given a new term in the controlled vocab, would GBIF/OBIS be fine in processing this field to detect unnaturally occurring occurrences?


[hi] Localize content/hi/docs/reference/glossary/job.md

Signed-off-by: amolmote<EMAIL_ADDRESS>Fixes #35600 [hi] Localize content/hi/docs/reference/glossary/job.md

/assign @anubha-v-ardhan  , @divya-mohan0209

#38132 opened  new PR for this issue due to some issues.


Fix unconfirmed coins when sending via RPC

What current issue(s) does this address, or what feature is it adding?
In the #python channel on Discord, @serefbulbul found an issue where transactions were failing on "Insufficient Funds" without funds actually being insufficient.
Upon testing, I found that the first transaction was successful but every transaction after failed. So, I checked getbalance and found the following:
{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "Balance": "32045.99999999",
        "Confirmed": "0.0"
    }
}

When reading the description of SaveTransaction:
https://github.com/CityOfZion/neo-python/blob/e3780126f9cf8175f9f3c7ad27f36f2baae20508/neo/Wallets/Wallet.py#L1104-L1118
How did you solve this problem?
I moved self.wallet.SaveTransaction(tx) so the coins can be confirmed.
How did you make sure your solution works?
Manual Testing
Are there any special changes in the code that we should be aware of?
No
Please check the following, if applicable:

[ ] Did you add any tests?
[x] Did you run make lint?
[x] Did you run make test?
[x] Are you making a PR to a feature branch or development rather than master?
[x] Did you add an entry to CHANGELOG.rst? (if not, please do)

Coverage remained the same at 83.935% when pulling e86e9afd77a86302a9280e8abaca59d2376b9a22 on jseagrave21:fix-unconfirmed-coins into f9543fa7f104d8316c1d0c9c73ff39446002d178 on CityOfZion:development.

It is not clear to me why moving this fixes the issue from the Discord user. Can you elaborate why you think that is the case. The description says, confirming doesn't happen until after the block has been processed on the network. So whether we save the is transaction before or after we relay it to the network doesn't look like it would matter for the described issue, or am I missing something?
What I do realise while writing this is that we'd probably want to save the transaction if relaying fails. So that's a fix we could do regardless if it fixes the discord issue.

When sending from CLI we have it set up to only save if the transaction relays successfully. https://github.com/CityOfZion/neo-python/blob/master/neo/Prompt/Commands/Send.py#L208-L209
But we decided not to do this because it doesn't match neo-cli implementation of the RPC method
https://github.com/neo-project/neo/blob/master/neo/Network/RPC/RpcServer.cs#L479-L484
See https://github.com/CityOfZion/neo-python/pull/680#issuecomment-437636680
To test, I built a RPC server using privnet and send a transaction using "sendmany" similar to the way the Discord user described. I sent 1 GAS to two separate addresses. The first transaction was successful as I documented in Discord; however, every transaction after failed on "Insufficient Funds" like the user described.
After moving the line of code, I was able to make transactions normally again.

@ixje how do I open a wallet and query one of the C# nodes on privnet?
On Sun, Dec 9, 2018, 11:22 Erik van den Brink<EMAIL_ADDRESS>wrote:

To test, I built a RPC server using privnet and sent a transaction using
"sendmany" similar to the way the Discord user described. I sent 1 GAS to
two separate addresses.
Can you please confirm that if you do the same with sendmany against the
RPC server of one of the C# nodes that it gives the same result?
I'm still confused why it would make a difference given the comment in the
code, but I'll go for it if you can confirm the above.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/CityOfZion/neo-python/pull/745#issuecomment-445563838,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Am-tVS-khBupDFM5M5fGFPTKjExPCTVLks5u3WMSgaJpZM4ZJvMk
.

@ixje how do I open a wallet and query one of the C# nodes on privnet?
the privnet consists of 4 consensus nodes. Each consensus node must have a wallet open to work, so you don't have to do anything there. The CoZ privnet also enables RPC by default, thus all that you'll have to do is change the ip/port in your experiment to point to one of the privnet hosts.

@ixje Well, I tried all of the consensus ports and got the error "Insufficient Funds" for all of them. But, I don't know if they actually have wallets open with a balance. Moreover, I tried changing my test a little and switched the order back to the original. Just like you thought, it didn't make a difference, so you were right.
So, I continued testing. I tried increasing the speed of transaction requests and this seemed to trigger the insufficient funds error. Here are the last few transactions please notice change for the last transaction prior to "Insufficient Funds".
{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "txid": "0x39241a3dd7b65f190a17d2bdd21c0439ef3feed2923be55e06324ddd29909789",
        "size": 343,
        "type": "ContractTransaction",
        "version": 0,
        "attributes": [
            {
                "usage": 32,
                "data": "23ba2703c53263e8d6e522dc32203339dcd8eee9"
            }
        ],
        "vout": [
            {
                "n": 0,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "1",
                "address": "AVSENo13gRPaVbXJKyPTqe1kREG9tAvu4E"
            },
            {
                "n": 1,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "1",
                "address": "AGzk6f5UrcpbQ3gZvaYvbx49GGscpMH1HP"
            },
            {
                "n": 2,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "30",
                "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
            }
        ],
        "vin": [
            {
                "txid": "0xeeb8c5072dc580d166d78edc935a687df65003e9ae535d5f1479e769bf6a55e5",
                "vout": 2
            }
        ],
        "sys_fee": "0",
        "net_fee": "0",
        "scripts": [
            {
                "invocation": "40118688adce98559dd0bae4b292542de6596583f7f3427165a9e72e64b39c268b2e0e5869ebd453af1fb7545c78e96ecefe78e25bdcd7683509623a4b5f13bea3",
                "verification": "21031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4aac"
            }
        ]
    }
}
{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "txid": "0x16f25a2f0ca71ff739dae4d48fe4b1a39915adc81642fa06c4858122e8db8c7b",
        "size": 343,
        "type": "ContractTransaction",
        "version": 0,
        "attributes": [
            {
                "usage": 32,
                "data": "23ba2703c53263e8d6e522dc32203339dcd8eee9"
            }
        ],
        "vout": [
            {
                "n": 0,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "1",
                "address": "AVSENo13gRPaVbXJKyPTqe1kREG9tAvu4E"
            },
            {
                "n": 1,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "1",
                "address": "AGzk6f5UrcpbQ3gZvaYvbx49GGscpMH1HP"
            },
            {
                "n": 2,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "15982",
                "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
            }
        ],
        "vin": [
            {
                "txid": "0xc2f7fac79531d94d406367c7feafe425f893a580fa703c7b4df9572f5944df5a",
                "vout": 0
            }
        ],
        "sys_fee": "0",
        "net_fee": "0",
        "scripts": [
            {
                "invocation": "4069a5266440e577fb97262e7272de68c3a9c6cdf5db6e4df12c43998b217b5d176fb310184372de3a4c0efdf0aa2c55f2eab50ba655ade754eb68cd1adff8fc3f",
                "verification": "21031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4aac"
            }
        ]
    }
}
{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "code": -300,
        "message": "Insufficient funds"
    }
}

I have no idea where the 15982 GAS comes from but I think this is what causes the issue. Thoughts?

I think that's just a different coinreference in takes the funds from. Inspect tx 0xc2f7fac79531d94d406367c7feafe425f893a580fa703c7b4df9572f5944df5a and look at the vout with n == 2. The value should be 15984 (15982+1+1). If not then that might be the issue.

Nope, you are right:
{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "txid": "0xc2f7fac79531d94d406367c7feafe425f893a580fa703c7b4df9572f5944df5a",
        "size": 203,
        "type": "ClaimTransaction",
        "version": 0,
        "attributes": [],
        "vout": [
            {
                "n": 0,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "15984",
                "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
            }
        ],
        "vin": [],
        "sys_fee": "0",
        "net_fee": "0",
        "scripts": [
            {
                "invocation": "4004d2fe570d5f752d3ddaec1b1330b1e2433c8af4eefaa07b664a3de833fc32892fc7a0acadca7b939a5077bcfc3ebf1379763bf5f7d5a57a2f4279580cf68ec8",
                "verification": "21031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4aac"
            }
        ],
        "claims": [
            {
                "txid": "0x83df8bd085fcb60b2789f7d0a9f876e5f3908567f7877fcba835e899b9dea0b5",
                "vout": 0
            }
        ],
        "blockhash": "0x83973124067c2814b5b979bf259f4a038cc6b5c42f10473902b9a0e262ca8d07",
        "confirmations": 349,
        "blocktime":<PHONE_NUMBER>
    }
}

Okay, I just tested it some more. It seems like the only problem is waiting for the transactions to be confirmed. The first transaction calls a small coinreference (~30) and the second transaction calls the larger coinreference (~15980). The third shows Insufficient Funds because, I am assuming, there are no confirmed coins in the wallet. Once the previous transactions are confirmed, then transactions may resume. Thoughts?

The third shows "Insufficient Funds" because, I am assuming, there are no confirmed coins in the wallet
we should be able to confirm this by querying the DB for all coinreferences for the address/wallet.

Should we update the user feedback to give better understanding why there is no tx? 👇
I wouldn't know what else to say that's not going to confuse them more. The coinreferences is just 1 explanation (which we haven't fully confirmed yet), another is just not being fully synced.

By analyzing the verbose wallet we can find the coinreferences:
Wallet {
    "path": "neo-privnet.wallet",
    "addresses": [
        {
            "version": 0,
            "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y",
            "script_hash": "e9eed8dc39332032dc22e5d6e86332c50327ba23",
            "frozen": false,
            "votes": [],
            "balances": {
                "0xc56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b": "100000000.0",
                "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7": "16024.0"
            },
            "is_watch_only": false
        }
    ],
    "height": 2034,
    "percent_synced": 100,
    "synced_balances": [
        "[NEO]: 100000000.0 ",
        "[NEOGas]: 16024.0 "
    ],
    "public_keys": [
        {
            "Address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y",
            "Public Key": "031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4a"
        }
    ],
    "tokens": [],
    "claims": {
        "available": "0.0",
        "unavailable": "216.0"
    },
    "coins": [
        {
            "Reference": {
                "txid": "0x803ec81b9ddb7dec5c914793a9e61bf556deafb561216473ad7a8ee7a91979cc",
                "vout": 0
            },
            "Output": {
                "n": 0,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "40",
                "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
            }
        },
        {
            "Reference": {
                "txid": "0x4ba4d1f1acf7c6648ced8824aa2cd3e8f836f59e7071340e0c440d099a508cff",
                "vout": 0
            },
            "Output": {
                "n": 0,
                "asset": "0xc56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b",
                "value": "100000000",
                "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
            }
        },
        {
            "Reference": {
                "txid": "0xc2f7fac79531d94d406367c7feafe425f893a580fa703c7b4df9572f5944df5a",
                "vout": 0
            },
            "Output": {
                "n": 0,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "15984",
                "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
            }
        }
    ],
    "transactions": [
        {
            "txid": "0xdc44739e2f97743f2ed258988327560e2185ed13eec0097938eef4aea584bf04",
            "size": 436,
            "type": "ContractTransaction",
            "version": 0,
            "attributes": [],
            "vout": [
                {
                    "n": 0,
                    "asset": "0xc56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b",
                    "value": "100000000",
                    "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
                }
            ],
            "vin": [
                {
                    "txid": "0x7aadf91ca8ac1e2c323c025a7e492bee2dd90c783b86ebfc3b18db66b530a76d",
                    "vout": 0
                }
            ],
            "sys_fee": "0",
            "net_fee": "0",
            "scripts": [
                {
                    "invocation": "406c0e529d43daba69d8daaea954f697e17b4c1e2ff596c82eeb0c8a8d1d0dea2268e37b1e653d8fb488e74396f478067c18d0741d956ab8935a67f40eb67c93d940a9684c5497bd06d59e88bbedb75666c2b7f92a8304c8e280c94a495fa4c2d90436caa0c651c3f816f37e0add5623594bc782af38a461d77b548f1ab5de3a2bbe402cfbabd5ac2bd5e6bd69c7a61ba79bf1b37c4e8c1b20f23a48d4896e67a6f25016d39ed4c417fd00d9af455638c9d3fbacc049b2e467d2622827da41a0508881",
                    "verification": "532102103a7f7dd016558597f7960d27c516a4394fd968b9e65155eb4b013e4040406e2102a7bc55fe8684e0119768d104ba30795bdcc86619e864add26156723ed185cd622102b3622bf4017bdfe317c58aed5f4c753f206b7db896046fa7d774bbc4bf7f8dc22103d90c07df63e690ce77912e10ab51acc944b66860237b608c4f8f8309e71ee69954ae"
                }
            ]
        },
        {
            "txid": "0x83df8bd085fcb60b2789f7d0a9f876e5f3908567f7877fcba835e899b9dea0b5",
            "size": 223,
            "type": "ContractTransaction",
            "version": 0,
            "attributes": [
                {
                    "usage": 32,
                    "data": "23ba2703c53263e8d6e522dc32203339dcd8eee9"
                }
            ],
            "vout": [
                {
                    "n": 0,
                    "asset": "0xc56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b",
                    "value": "100000000",
                    "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
                }
            ],
            "vin": [
                {
                    "txid": "0xdc44739e2f97743f2ed258988327560e2185ed13eec0097938eef4aea584bf04",
                    "vout": 0
                }
            ],
            "sys_fee": "0",
            "net_fee": "0",
            "scripts": [
                {
                    "invocation": "401b51c85fb9f6eaabdba5bcc257b00de28ed717534dc0ae8401fac54c0f438c1a3068bb4027f3f06100a4899e3cd11e126260e67fad0048be78901cca1b7a22c4",
                    "verification": "21031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4aac"
                }
            ]
        },
        {
            "txid": "0x803ec81b9ddb7dec5c914793a9e61bf556deafb561216473ad7a8ee7a91979cc",
            "size": 203,
            "type": "ClaimTransaction",
            "version": 0,
            "attributes": [],
            "vout": [
                {
                    "n": 0,
                    "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                    "value": "40",
                    "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
                }
            ],
            "vin": [],
            "sys_fee": "0",
            "net_fee": "0",
            "scripts": [
                {
                    "invocation": "40bcd1fe766f8b3702f26a7b1161bc6dccaf45afe7b46ee679fcd09a46becb25580fc2f2cb85a2d97052369b9f53d35038785be1cf21f7e421946c51bab06579b8",
                    "verification": "21031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4aac"
                }
            ],
            "claims": [
                {
                    "txid": "0xdc44739e2f97743f2ed258988327560e2185ed13eec0097938eef4aea584bf04",
                    "vout": 0
                }
            ]
        },
        {
            "txid": "0x4ba4d1f1acf7c6648ced8824aa2cd3e8f836f59e7071340e0c440d099a508cff",
            "size": 223,
            "type": "ContractTransaction",
            "version": 0,
            "attributes": [
                {
                    "usage": 32,
                    "data": "23ba2703c53263e8d6e522dc32203339dcd8eee9"
                }
            ],
            "vout": [
                {
                    "n": 0,
                    "asset": "0xc56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b",
                    "value": "100000000",
                    "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
                }
            ],
            "vin": [
                {
                    "txid": "0x83df8bd085fcb60b2789f7d0a9f876e5f3908567f7877fcba835e899b9dea0b5",
                    "vout": 0
                }
            ],
            "sys_fee": "0",
            "net_fee": "0",
            "scripts": [
                {
                    "invocation": "40a3799c78dec17823fde75233793a7039bf2b1dbca4383a6eef1ac829460ba14c1e6a50ab1f2174e689bebfc0bb7accc965a6fe3e46d517b317bba1325b7fdaca",
                    "verification": "21031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4aac"
                }
            ]
        },
        {
            "txid": "0xc2f7fac79531d94d406367c7feafe425f893a580fa703c7b4df9572f5944df5a",
            "size": 203,
            "type": "ClaimTransaction",
            "version": 0,
            "attributes": [],
            "vout": [
                {
                    "n": 0,
                    "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                    "value": "15984",
                    "address": "AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y"
                }
            ],
            "vin": [],
            "sys_fee": "0",
            "net_fee": "0",
            "scripts": [
                {
                    "invocation": "4004d2fe570d5f752d3ddaec1b1330b1e2433c8af4eefaa07b664a3de833fc32892fc7a0acadca7b939a5077bcfc3ebf1379763bf5f7d5a57a2f4279580cf68ec8",
                    "verification": "21031a6c6fbbdf02ca351745fa86b9ba5a9452d785ac4f7fc2b7548ca2a46c4fcf4aac"
                }
            ],
            "claims": [
                {
                    "txid": "0x83df8bd085fcb60b2789f7d0a9f876e5f3908567f7877fcba835e899b9dea0b5",
                    "vout": 0
                }
            ]
        }
    ]
}

The two references are "15984" and "40". Also, whenever the error "Insufficient Funds" comes in these tests a query of "getbalance" returns "Confirmed": "0.0"
as shown in https://github.com/CityOfZion/neo-python/pull/745#issue-237080939
@ixje based on the fact that there isn't a better user feedback, I recommend closing this issue with the lesson learned being: Wait for transactions to be confirmed on the blockchain before sending more transactions from the same wallet.
Thoughts?

Yep I agree. I think a work around for users (which I didn't think of before) is to use the wallet split command.


doc: Don't use a fixed sidebar to better accomodate small screens

When the sidebar is too tall for the browser window, the user can
not scroll down to view the bottom of the sidebar when it is fixed.
Fixes #970

Current coverage is 100% (diff: 100%)

Merging #981 into master will not change coverage

@@           master   #981   diff @@
====================================
  Files          31     31
  Lines        2055   2055
  Methods         0      0
  Messages        0      0
  Branches      334    334
====================================
  Hits         2055   2055
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update 71cda99...3c66d3a


Add Value.IsXxx

Closes #253

Coverage: 94.491% (-0.06%) from 94.555% when pulling e099584ee55916ad791845cc10c2ab06b0b8b88d on nhAnik:253-value-isxxx into 86f366a2d10b8a8ddd3cb1a9b2a5c00f37a1df68 on gavv:master.

Thanks, the changes look good!
Sorry, seems I forgot to mention in the issue: in httpexpect each Is method should have counterpart Not method. For example, for IsObject, we also need NotObject. Could you please add them too?

Sure, I will add them.

LGTM!

BTW, welcome to our discord chat!

Thank you 🙂


Sparse output for MLPDecoder (for MNIST-set experiments)?

Hi, thank you for fast response!
I tested MNIST-set experiments on MLPDecoder and found that the output cardinality tends to go small when using the Chamfer loss.
While it is understandable that Chamfer loss only needs to keep "a few" points to minimize their loss (several target points map to the shared output point), I just want to check if this phenomena also happened to you (to check that it is not my problem, e.g., of environments).
Also, is it common to use an additional regularizer to enforce output and target to have similar number of points (i.e., || # of pred masks = # of target masks ||)?
I'm pretty new in this domain, hence thank you for your kind help! :)

MLPDecoder producing too few points is normal and happens for me too, especially when the dimensions for the MLP are somewhat small. With the hyperparams in scripts/mnist.sh, do you get results that look similar to Appendix C?
I haven't seen any papers that have such a regularisation term, but I don't think that there is any particular reason against it.

Oh, I just remembered: You have to use the testing git branch, not master. The testing branch biases the masks towards 1 so that it gets less stuck at the local optimum of predicting too few points. Let me know if that fixes it.

Hi, sorry for the late response! Adding 1 to the bias seems to work okay.
In particular, I checked the (soft) number of masks by masks[-1].sum(-1).mean() and found that initializing bias to 0 (master branch) collapses to # of masks < 20 and adding 1 (testing branch) collapses to '# of masks = 340 (almost max)`.
I also checked Hungarian loss, then the number of masks indeed goes to 130, which is near to the correct number of points.
It seems that learning the cardinality of sets (especially when using Chamfer loss) is extremely unstable!
Do you have any related work on this issue? It seems to be an interesting problem to handle.

With point cloud generation tasks of 3d objects, people usually sample a fixed number of points, e.g. 2048 points for a shape. That's why they can get away without using any masks (output size is always 2048 after all) so this issue with the Chamfer loss hasn't really come up in those contexts. https://arxiv.org/abs/2001.11845 has an output that, as far as I understand, does a classification over the set sizes, though they use the Hungarian loss anyway.

Thank you for the kind response!
As you said, the set size seems not so sensitive to the point clouds.
Investigating proper applications of the variable-sized set (e.g., object detection as you suggested) looks like an interesting research question. Thanks a lot for your helpful comments! :)


[v3] ButtonGroup : class and ui attributes not handled ?

Environment

Operating System: Darwin
Node Version:     v18.20.4
Nuxt Version:     3.13.2
CLI Version:      3.15.0
Nitro Version:    2.9.7
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      default
Runtime Modules<EMAIL_ADDRESS>Build Modules:    -

Version
v3.0.0-alpha.7
Reproduction
The :ui prop is not handled by the component ButtonGroup ?
Description
I tried to add somme classes to the ButtonGroup component, with class= attribute, with :ui= attribute, but it seems that nothing works.
Additional context
I've tried to look into the code, but I don't understand all the magic you've done !
Logs
No response

The ButtonGroup doesn't have a ui prop as it only has a root div. However, there was an issue with the class not being merged. Thanks for the report!


Have both master and main branches work at the same time, without breaking?

Feature Description
Some CI/CD workflows break when someone renames master branch to main.
What if there would be no need to change branch names, both "master" and "main" would work when there is one of those, and at visible web interfaces would visibly just show text "main", not "master"? This way, there would be no need to manually rename branches, and all repos would be "main" compliant by default. That change would only need to be done to git hosting software, and it would save the world from a lot of breakages.
Screenshots
No response

I also asked this from GitHub https://github.com/github/feedback/discussions/11397

You mean symbolic ref main as master or vice versa?

@zeripath
Both:

Renaming master to main: https://github.com/github/renaming .If master is renamed to main, it would be better that using master would still work.
If someone has not yet renamed master to main, cloning main would be good to work also
Web UI could always show that branch name is main. So nobody would have to make manual renames of branches.

git symbolic-ref refs/heads/master refs/heads/main

Please keep in mind that not everyone uses master/main terminology. While I personally don't object from main to the default branch, this might be unexpected to some users.
Implementing something like the rename feature in Gitea might be a good idea: If branch A is renamed to B, it is a symbolic ref until an actual branch A is pushed.


Better usage of empty spaces

Rows in mixed view are only as high as the tallest list within the row, for better usage of screen real estate.
Using 'vh' because there is no support for '%' height of a parent element with 'auto' height.

Replaced with new commit to better handle saving settings locally


Label desc

Depends on #55 (merging master after will help with review)
Closes #49

Closing this PR, after talking with @designlanguage there isn't much benefit to these descriptions. Someone coming to this tool will likely have the data "in hand" and ready to go.
I'll update #57 to remove this.


Add Airbnb logo to list of companies using Jest

More info:
https://medium.com/airbnb-engineering/unlocking-test-performance-migrating-from-mocha-to-jest-2796c508ec50

Summary

Airbnb is now using Jest, and it seems like a nice idea to include the Airbnb logo in the list of companies using Jest.
Test plan

I did not test this change in any way.

I did not test it either. We'll see if it works #yolo.
Thanks Joe!

Codecov Report

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

@@           Coverage Diff           @@
##           master    #3835   +/-   ##
=======================================
  Coverage   57.63%   57.63%
=======================================
  Files         194      194
  Lines        6782     6782
  Branches        6        6
=======================================
  Hits         3909     3909
  Misses       2870     2870
  Partials        3        3

Continue to review full report at Codecov.

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

It worked! http://facebook.github.io/jest/users.html


Error message when deployment fails

If the deployment fails, I get the following message -
[Error: Get API info returned status 401]
Deployment completed..
We should change the error message to "Deployment failed".

Fixed in Version : 0.1.5


Update CHANGELOG to include removal of Ruby 2.2

Summary
This amends the CHANGELOG document to include the latest work on removing Ruby 2.2 support.
See #425
Details

Also: Fix compare link in title of "master release".
Also: Format usernames using reference-style links. What do you think about that? Should I complete it throughout the document? We are hand-writing this, so it ought to simplify things.

Motivation and Context
I hope we soon get to release a new version.
How Has This Been Tested?
I previewed.
Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue).

Seems fine. More stuff to get put into there but this can be merged in


WIP: pfe-navigation next

Pre-existing CSS variables & ones RHDC is using: http://pastebin.test.redhat.com/956617

@kylebuch8 closing as stale, and we'll come back to this in rhds


Support managing tokens and applications

Implement in tower-cli https://github.com/ansible/awx/pull/904
endpoints under /api/o/
{
    "authorize": "/api/o/authorize/",
    "token": "/api/o/token/",
    "revoke_token": "/api/o/revoke_token/"
}

https://github.com/ansible/awx/blob/devel/docs/auth/oauth.md

@matburt @AlanCoding how far do we think we want to go with this?  At least in terms of immediate priority for tower-cli issues, I'm not sure I want to spend time updating tower-cli to deal in the actual creation/management of OAuth apps - there's already other plenty of other tools that can be used to interact with OAuth2 endpoints (including the UI in Tower itself).
Do we want to allow people to provide user+pass+secret_id+secret_key for an app and generate a token?  Or do we just want to add a flag for specifying a Personal Auth Token?
In my mind, the minimal path to OAuth2 support here is:

Go into Tower and create your app.
POST to /api/o/token/ to generate a personal access token.
Run tower-cli --oauth-token=<token-value>

I started this issue posting one thing, but here is a different thing.
Both applications and tokens are present as resources under the /api/v2/ path. These can be added as ordinary resources. This is dead-simple copy+paste and replace kind of effort.
I need to understand more about the standard and the implementation to make any helpful comment on the /api/o/ endpoints. If I say something now, I will probably be wrong, so this is the end of my comment.

There's a lot we can do here, and I think having the oauth2 implementation in Tower/AWX opens up a world of possibilities.
So... most CLI tools use a workflow that works really well with oauth. Look at oc/kubectl for example. You oc login give it your username and password and it goes out and fetches your token... stores that instead of your u/p
gcloud will open a browser and let you authenticate that way and pass the token back to the command line tool... this is pretty nifty-keen also since we support ldap/saml/etc. and I believe our 2-legged system would support this kind of thing

@matburt @rooftopcellist I don't think we're currently doing anything to facilitate personal access tokens ala https://github.com/evonove/django-oauth-toolkit/issues/257 (and what @matburt is describing - the notion of user+pass+default app to generate personal tokens).  Do we want to support this in the awx API?  If we don't, the alternative is that tower-cli integrators would probably have to provide four things to get an OAuth token:

auth username
auth password
application ID
application secret

We do have an implementation of personal access tokens, but it'll be necessary to allow folks to also supply the application id and secret to not require the use of personal access tokens.

Yep, @rooftopcellist has shown me the way:
$ curl -ku ryan:ryan -H "Content-Type: application/json" -X POST -d '{"description":"Tower CLI", "application":null, "scope":"read"}' https://awx.example.org/api/v2/users/1/personal_tokens/ | python -m json.tool


Activation of tools?

Hi, I think this project looks promising!
Can you clarify how I prompt to get info from a PDF. Using your tool example, you drag and drop a zip containing the .py-scripts and the PDF, into the frontend UI. Is that enough to "activate" it? How should the prompts be phrased to retrieve info from the data?
Good work on the tool template thingi, it will make it alot easier to just add our own and share!

Hey @adamengberg, thanks for checking out the project!
When you upload a tool to Tool Juggler, it's activated and ready to use right away.
You can turn tools on or off by clicking on them in the interface. To get info from a PDF, just be specific about the tool you want to use when asking the AI. You could say something like, "Can you give me a summary of the PDF using the [tool_name] tool?" This makes it clear to the assistant which tool you want it to use.
Once you've started a conversation about a PDF, you don't need to keep mentioning the tool, since the AI will get the context. But as you might know, it's never 100% with LLMs and keep in mind that Tool Juggler is in a super early alpha stage, so there might be some bumps along the way. Working on making it better!
Hope this helps! If you have more questions, don't hesitate to reach out. Cheers!

Thanks for you quick response! I get the PDF tool example to work by asking it to use that tool. I tried making another tool that takes several PDFs from a folder, but as soon as I import it freezes and I cant get a response.
Can I upload the code here for your review?

Hey @adamengberg, you can definitely upload your code here, and I'll try to take a look at it when I have some free time.
However, I'd like to encourage everyone to develop and deploy their own tools without relying on my supervision, as the main purpose of Tool Juggler is to empower users to create, customize and use their own tools.
The platform is still in its alpha stage, and it might not be as user-friendly as we'd like to debug your tools, but work on improving it is in progress.
As for your current issue, I suggest uploading those PDFs individually as separate tools and enabling or disabling them according to your needs. This should give you more flexibility and control in using the tools you've created.

Yes i see your point!
Would be nice to batch import PDF. i want to use it to import scientific publications, then it would be handy to import a bunch of papers from a research field i´ve gathered from Zotero. But the flexibility if you only have a couple of PDFs I understand! Thanks!


Update components.json

@joeinnes, Can you rebase your branch with staging and run npm run format ?
The formatting of src/routes/components/components.json is not correct (issue with end/start of the JSON object (https://github.com/svelte-society/sveltesociety.dev/pull/176/files#diff-d9f92e8e9adb76c17f488aefddaa940b6dfba83b2b212945311a1fc2fb637da7R2350))


Add missing project references

Summary of the Pull Request
It seems that a few C# projects are using the namespace 'interop' from a C++/CLI project without adding project references in their own project files.

PR Checklist

[ ] Closes: #xxx
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed
Build the project locally

@ACGNnsj please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

good catch, looks like these projects "cheated" from Settings.UI.Library having the reference


Replace CodeMirror with CodeEditTextView

https://github.com/CodeEditApp/CodeEditTextView

I tried its main branch today:

Line height of the line number and the code is not consistent
Needs a lot of code to get a color theme
No code highlight yet

I will try again in a month.


Not possible to access nested JSON MQTT data

Apache StreamPipes version
Other StreamPipes version (please specify below)
Affected StreamPipes components
Processing Elements
What happened?
When a MQTT adapter with a nested JSON data format is configured and  started, the data isn't accessible in the pipeline nor possible to visualize in Dashboard.
Data schema configuration:

Live preview of the data:

Even using a pipeline element, such as javascript eval, we cannot access the properties of nested objects.
When creating dashboard visualizations, it´s not possible to access values from nested object properties.
How to reproduce?
Create a MQTT adapter in Streampipes with nested JSON data. In the pipeline try to view (using live preview) or access atribute values in the pipeline. After creating and starting both the adapter and the pipeline, try visualize object property values in dashboard visualizations.
Expected behavior
In the pipeline access values from nested object attributes.
In the Dashboard, access and visualize data using nested objects.
Additional technical information
Streampipes version - 0.95.0
On a dashboard, if we select the raw widget to display the message, the nested objects appear as java.util.map, which implies that they are passing through the pipeline , but we have no way of accessing the data.
Are you willing to submit a PR?
No, I don't want to submit a PR.

Hi @acpenela,
thanks for opening this issue.
Nested structures are not completely supported in all StreamPipes components. However, you can flatten the events in the adapter, enabling you to move nested properties to the top level.
In the schema editor (as shown in your screenshot), you can drag and drop the entries to the top level, placing them next to the timestamp. As a result your event shoud look like this:
{
  "eixo_1": 4
  "eixol posição": 0.15,
  "eixol_velocidade": 17.1,
  "eixol aceleração": 1.6,
  "eixo1_ temperatura": 50.7
  "timestamp":<PHONE_NUMBER>38
}

If you encounter any issues during this process, please let us know. Additionally, we are planning to include a flatten feature in the adapter to assist you with this process in the future.
It is also possible to change the runtime names of your properties by clicking on Edit field.
Cheers,
Philipp


fix/added .toLowerCase

Added .toLowerCase to fix the bug of not being able to pass(ex. "Your Name" would not pass but "your name" would.)

Thanks for the PR, but this fix is not necessary. The string literals 'heads' and 'tails' included in the test are already lowercase.
We welcome more PRs but please in the future follow the Contribution Guidelines and have your code come from a branch with a name describing the fix and don't do a pull request on your own branch because it pollutes the commit history with extra merge commits. :smile:


Take the debug feature out of default features!

The debug feature is enabled by default, and it is very annoying!

This is intentional. Picking can be very complex, and it is hard to know why something is broken. It's much easier for me to debug issues with users if this is on by default, and can be disabled easily by the user.


Property ytPlayerContainer is private Error

I'm testing this component in an Ionic 2 RC2 environment, and when I test it on a device (iOS), I get an error:
Property ytPlayerContainer is private and only accessible within class YoutubePlayer
Any ideas?

Not sure why the this error happens, but i can set it to public


Error on clone/duplicate a select2

Hello, i've been working on duplicate select2 on a couple of forms on ruby on rails, when i duplicate the select2 element, i destroy it and  the clone it. but the behavior is not the expected (this is only happening on 4.0.6-rc1 version).
this is the example using 4.0.6-rc1
http://jsbin.com/coweheliyu/2/edit?html,js,output
using the 4.0.0 version works without a problem.
http://jsbin.com/jixinelade/3/edit?html,js,output
i've noticied after version 4.0.0, new data-select2-id is being added to parent elements.
Hope you guys can take a look on this.
Thanks

I ran into the same issue, looks like destroy() doesn't destroy everything. It works as expected with version 4.0.5

Yep, something is wrong with destroy. Very weird behavior after cloning. Can also confirm 4.0.5 works, 4.0.6rc1 does not.
In 4.0.6rc1 my parent span element gets a data-select2-id as well?

I get the same behavior with V 4.0.6-rc.1 almost all the element's parent(s) get a "data-select2-id=X" attribute. Also when destroying the element and reinitializing.


Recommended Usage code in home page is error

The demo in home page which is 'Recommended Usage: Make a Static Http Client' is error, because
JsonHttpResponseHandler is not the subclass of AsyncHttpResponseHandler
home page:http://loopj.com/android-async-http/

It is, indirect subclass through TextHttpResponseHandler


Valid username api call sometimes gives conflicting answers

Sometimes it'll say a username is available, and then it'll say the same username is unavailable in another call. Username is not updated in between

oops same issue as #169


vcpkg-tool change case of System32 to system32

See vcpkg-tool build failure for some ports (libiconv, gettext) I have found so far 23381
Somehow vcpkg-tool 6ef3648a2b7daf197fce82d936ff88ef98c26361 #406 commit seems to have changed the way System32 versus system32 is viewed in nix shells.
For some reason it is appends System32 instead of system32 in the path being used shell bash make operations causing an instant failure of the bash step with no messages or log files giving any tangible information, with only an empty file named .lineno in the x64-windows-dbg directory and the config-x64-windows-dbg-err.log file only contains this:

./../src/xxxx.clean/configure: line 478: sed: command not found
./../src/xxxx.clean/configure: line 477: expr: command not found
./../src/xxxx.clean/configure: line 478: sed: command not found
./../src/xxxx.clean/configure: line 492: sed: command not found
: error: cannot create .lineno; rerun with a POSIX shell.

with console output of this:

-- Configuring x64-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:128 (message):
Command failed: D:/vcpkg-test/downloads/tools/msys2/7e05e7aa09f1709f/usr/bin/bash.exe --noprofile --norc --debug -c > >"V=1 CPP='compile cl.exe -E' CC='compile cl.exe' CC_FOR_BUILD='compile cl.exe' CXX='compile cl.exe' RC='windres-rc rc.exe' >WINDRES='windres-rc rc.exe' AR='ar-lib lib.exe' LD='link.exe -verbose' RANLIB=':' STRIP=':' NM='dumpbin.exe -symbols ->headers' DLLTOOL='link.exe -verbose -dll' CCAS=':' AS=':' ./../src/1.16-b0c41d3469.clean/configure --build=x86_64-pc-mingw32 "--enable-extra-encodings" "--without-libiconv-prefix" "--without-libintl-prefix" "--enable-relocatable" "ac_cv_prog_ac_ct_STRIP=:" "gl_cv_double_slash_root=yes" "ac_cv_func_memmove=yes" "--disable-silent-rules" "--verbose" "--enable-shared" "--disable-static" "--prefix=/D/vcpkg-test/installed/x64-windows/debug" "--bindir=${prefix}/../tools/libiconv/debug/bin" "--sbindir=${prefix}/../tools/libiconv/debug/sbin" "--libdir=${prefix}/lib" "--includedir=${prefix}/../include" "--datarootdir=${prefix}/share/libiconv""
Working Directory: D:/vcpkg-test/buildtrees/libiconv/x64-windows-dbg
Error code: 1
See logs for more information:
D:\vcpkg-test\buildtrees\libiconv\config-x64-windows-dbg-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_configure_make.cmake:815 (vcpkg_execute_required_process)
ports/libiconv/portfile.cmake:29 (vcpkg_configure_make)
scripts/ports.cmake:145 (include)

I would ask to have this review, scrutinized, and checked by either @ras0219-msft @BillyONeal @strega-nil-ms in addition to @JackBoosY as the vcpkg-tool is a big ticket item to mistakenly make the wrong changes to and cause a whole lot more problems.
Thank you and have a wonderful week all.

I have no idea how to fix the Windows vcpkg-tool CI run?
The errors are:

##[error]Cmd.exe exited with '1'.
##[error]Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\a\format.diff

If someone could assist in educating me what must be done to fix these errors I would greatly appreciate it.

I have no idea how to fix the Windows vcpkg-tool CI run? The errors are:

##[error]Cmd.exe exited with '1'.
##[error]Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\a\format.diff

If someone could assist in educating me what must be done to fix these errors I would greatly appreciate it.

It means you need to rerun clang-format on something.

Somehow vcpkg-tool https://github.com/microsoft/vcpkg-tool/commit/6ef3648a2b7daf197fce82d936ff88ef98c26361 https://github.com/microsoft/vcpkg-tool/pull/406 commit seems to have changed the way System32 versus system32 is viewed in nix shells.

The correct name is "System32", with a capital:

This is why win32_fixup_path_case rewrites it to be a capital.

Nicole asked for capital here: https://github.com/microsoft/vcpkg-tool/pull/406#discussion_r818947083

(Also, regarding CI failures, you need to follow the link to Azure DevOps to get the full results. I wish that GitHub actions supported automatic VM setup and teardown so we could use that and/or ADO would report better status back here)

@BillyONeal - I concur and this is why I wanted someone more knowledgeable to review.
All I know is the 2022-02-24 vcpkg version shows path with system32 in lower-case, and the 2022-03-03 version shows System32 in upper-case, and I know nix shells are case sensitive and my git bash shell shows the path as /c/windows/system32 and the command failing is the one executing a long bash command?
So I not know where to go from here?

Ok so I guess I withdrawn the PR and close the Issue - sorry to have bothered you.
Thank you for your time and effort.
I still do not know why the newer vcpkg fails on one and does not on the older version.

Ok so I guess I withdrawn the PR and close the Issue - sorry to have bothered you. Thank you for your time and effort. I still do not know why the newer vcpkg fails on one and does not on the older version.

Nothing to be sorry for; you found a workaround that fixed the problem even if the test code changes aren't correct. (I tried to push what was needed to accept this here but the PR was created without permissions for maintainers to do that)
I created https://github.com/microsoft/vcpkg-tool/pull/419 which appears to fix the problem for me. The Right Thing is for msys et al. to be fixed to work with the correct case, but given that we need to get a tool release out to un-break CI right now I think backing out the case change is OK.

@BillyONeal - yes with the vcpkg-tool itself, I always like the converse/contact either you @BillyONeal, @ras0219-msft or @strega-nil-ms as I know how much of an impact this can be.
Thank you for your assistance and help.
You all take care and have a great week.

All is know is the bash command fails when vcpkg passes a Upper-Case System32 to it and succeeds if vcpkg passes a lower-case system32 to it.

AFAICT Msys2 bash basically uses the spelling supplied by the user on a case-insensitive file system.
$ cd C:/Windows/System32
$ echo $PWD
/c/Windows/System32
$ cd /
$ cd C:/windows/system32
$ echo $PWD
/c/windows/system32

Last not least, vcpkg has other references to lower-case system32, e.g.:
https://github.com/microsoft/vcpkg/blob/5962cf5a3bfc2124e8de991a4e45a8edcb3b4c69/scripts/cmake/vcpkg_configure_make.cmake#L340-L342
... where SystemRoot contains all-uppercase WINDOWS.


[1.16.1] Bug with the spawner module.

Hi!
There is a bug in the spawner module. When a mob is blacklisted, we can still add it to the spawner using shift + right click. This does not happen with just a right click.
Version: 1.16.1-4.1.3 (it also does it on version 1.16.3).

So that commit fixes that issue, but upon further inspection, this issue is actually caused by a regression in how the RightClickBlock event works (the ALLOW result no longer does anything), so my previous event handler that fixed this behavior is just broken.
I'll be opening a forge PR to hopefully get this resolved properly.


chore: Update formatting in shell script

Description:
Update formatting of the hack/operator-sdk-common.sh to support zsh
Signed-off-by: Nikhil-Ladha<EMAIL_ADDRESS>

@iamniting @umangachapagain can you please review.


Change deprecated constants into hidden constants

rustc, an important libc consumer, has a policy that they can't use any
crates with deprecated symbols.  Replace libc's two deprecated symbols
with hidden symbols instead.

:pushpin: Commit 6e8e7cf has been approved by alexcrichton

@bors: r+

:hourglass: Testing commit 6e8e7cf3b6b00573dc90a1cb1330495c6342c4fd with merge ef9eefb6df3f3a2cb989e8050519661faa7d7118...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing ef9eefb6df3f3a2cb989e8050519661faa7d7118 to master...


manifest requires foundry 0.8.0

https://raw.githubusercontent.com/ardittristan/VTTNPCGen/master/module.json
Says Foundry 0.8.0 is needed.  Is this module only for beta at the moment?

at the top of the readme there's a manifest that works with 0.7
0.8 required a big overhaul.


javascript "vis" doe not finish loading

In  contour_result this line should load the javascript

However it never finishes. Consequently, the visualization of the contour in 3d /4d does not work.
In the past this worked. Starting on November 13 2017 it did not work anymore. Also when past versions of git were checked out (where it previsously worked) I could not get it running again.

Today (November 16th) it started working again. I did not change anything related to static content / javascript.

The problem does not occur anymore. Closing the issue.


Testing updates

Quite a bit of work here, looking good

Still pretty broken. It's going to be a while, but Travis tests now so that's progress.

This is failing due to a larger failure in the cookbook. I think it's best to get this merged in now and then track down the larger failure. Keeping this long running branch open is only making issues worse for PRs being cut to fix the problems.


Getting error in flutter run

Getting error in Flutter run
When we are running flutter run we are facing some errors.
These are the tasks that are failing:

Task :app:processDebugResources FAILED
Task :flutter_share:checkDebugAndroidTestAarMetadata FAILED
Task :just_audio:mergeDexDebugAndroidTest FAILED
AGPBI: {"kind":"error","text":"Cannot fit requested classes in a single dex file (# methods: 68452 > 65536)","sources":[{}],"tool":"D8"}
Task :video_player_android:mergeDexDebugAndroidTest FAILED
AGPBI: {"kind":"error","text":"Cannot fit requested classes in a single dex file (# methods: 67057 > 65536)","sources":[{}],"tool":"D8"}
AAPT2 process unexpectedly exit.

Expected behavior
App should running.
Tools that are using

Android Studio: Android Studio Koala (2024.1.1)
Java (v17.0.10)
Flutter version: 3.22.1
Dart version: 3.4.1

I have fixed it for the latest flutter version
https://github.com/Faiyyaz/opensource-ecommerce-mobile-app
If you are okay with accepting PR then I will fork and raise a PR but for now sharing the link for my personal repository here

I have fixed it for the latest flutter version
https://github.com/Faiyyaz/opensource-ecommerce-mobile-app
If you are okay with accepting PR then I will fork and raise a PR but for now sharing the link for my personal repository here

I'm sorry to say, you have disappointed me.
After failing so many times, I got hope seeing your link.
But it's 404. I'm disappointed.

@bdsumon4u Can you check now? Sorry it was a private repo I made it public

@Faiyyaz, yes. It's now public and thanks for that. But can you please tell me which version of flutter did you use?

The latest one as of that date I don't think in 2 weeks there were any big version release

The flutter release I used was latest one as of that date and I think there are no major new version after that.

Getting following errors:
/C:/Users/mebro/AppData/Local/Pub/Cache/hosted/pub.dev/carousel_slider-4.2.1/lib/carousel_slider.dart:9:1: Error: 'CarouselController' is imported from both 'package:carousel_slider/carousel_controller.dart' and 'package:flutter/src/material/carousel.dart'.
import 'carousel_controller.dart';
^^^^^^^^^^^^^^^^^^
lib/screens/product_screen/view/downloadable_product_options.dart:34:36: Error: 'CarouselController' is imported from both 'package:carousel_slider/carousel_controller.dart' and 'package:flutter/src/material/carousel.dart'.
final buttonCarouselController = CarouselController();
^^^^^^^^^^^^^^^^^^
lib/screens/product_screen/view/downloadable_product_sample.dart:35:36: Error: 'CarouselController' is imported from both 'package:carousel_slider/carousel_controller.dart' and 'package:flutter/src/material/carousel.dart'.
final buttonCarouselController = CarouselController();
^^^^^^^^^^^^^^^^^^
lib/screens/product_screen/view/product_image_view.dart:41:36: Error: 'CarouselController' is imported from both 'package:carousel_slider/carousel_controller.dart' and 'package:flutter/src/material/carousel.dart'.
final buttonCarouselController = CarouselController();
^^^^^^^^^^^^^^^^^^
/C:/Users/mebro/AppData/Local/Pub/Cache/hosted/pub.dev/carousel_slider-4.2.1/lib/carousel_slider.dart:48:15: Error: 'CarouselController' is imported from both 'package:carousel_slider/carousel_controller.dart' and 'package:flutter/src/material/carousel.dart'.
: CarouselController() as CarouselControllerImpl,
^^^^^^^^^^^^^^^^^^
/C:/Users/mebro/AppData/Local/Pub/Cache/hosted/pub.dev/carousel_slider-4.2.1/lib/carousel_slider.dart:62:15: Error: 'CarouselController' is imported from both 'package:carousel_slider/carousel_controller.dart' and 'package:flutter/src/material/carousel.dart'.
: CarouselController() as CarouselControllerImpl,
^^^^^^^^^^^^^^^^^^
Target kernel_snapshot_program failed: Exception
FAILURE: Build failed with an exception.

Where:
Script 'C:\flutter\packages\flutter_tools\gradle\src\main\groovy\flutter.groovy' line: 1687

What went wrong:
Execution failed for task ':app:compileFlutterBuildDebug'.

Process 'command 'C:\flutter\bin\flutter.bat'' finished with non-zero exit value 1

@mebron This is because the latest flutter has its own carousel slider can you downgrade from 3.24 and try again


Tax Exchange Rate - source and target currency codes

Hi,
First of all I want to thank you for this package. It is a god send! I noticed that the Source and Target currency codes for Tax Exchange Rate cant be set. Is it by design or just not implemented?
Sample UBL from LHDN site
<cac:TaxExchangeRate>
<cbc:SourceCurrencyCode>EUR</cbc:SourceCurrencyCode>
<cbc:TargetCurrencyCode>MRY</cbc:TargetCurrencyCode>
<cbc:CalculationRate>5.07</cbc:CalculationRate>
</cac:TaxExchangeRate>

Missing from implementation. Thanks for informing.
If you found something is missing, you may inform me again.

Thank you!

Code updated to main branch and tagged as 1.0.5


Add public to Cache-Control header

Pull request checklist:

[ ] CHANGELOG.md was updated, if applicable

Description

After testing, this doesn't seem necessary. Your original PR did the trick, I was just missing some magic cloudflare settings


is.touchDevice(): possible improvement

Hi, I've seen quite a few posts somewhere else including these checks:
|| (navigator.MaxTouchPoints > 0)
|| (navigator.msMaxTouchPoints > 0))
Like here: http://ctrlq.org/code/19616-detect-touch-screen-javascript
and here: https://coderwall.com/p/mqd6pw/detect-touchcapability-in-javascript
Should they be added?

Thanks!
We'll keep an eye on the popularity of the request.


Add to Contacts

Ref: Conversation #551 / wbgordy

Ref: Conversation #3673 / Paul

Ref: Conversation #3739 / Nathan

Ref: Conversation #3727 / Steven

Ref: Conversation #3872 / Stephen

Ref: Conversation #3974 / Amit

Ref: Conversation #4076 / Peter

Ref: Conversation #4375 / Peter

Ref: Conversation #5170 / Natan

Ref: Conversation #4459 / Joseph A.

Ref: Conversation #4353 / Jose

Ref: Conversation #2839 / Luke T

Ref: Conversation #2868 / James

Ref: Conversation #2864 / Gregg


System-wide logging improvements

The zap logger setup we have has been working well so far, but as the project expands we should consider:
a) potential improvements, refactors, or redesigns of how we use loggers across places in the code
b) newer/better/standardized libraries to switch to
I've tried a few other logging libraries, and so far none seem to be as good as zap for our use cases, but more research is required.
slog (upcoming standard library structured logging)

It has a design similar to zap, and a good feature set and API
It is still very much in development, and lacks a lot of features that I like from zap (e.g. custom log output handlers)

zerolog

Inspired by/derived from zap, but with fewer options for customization. For this reason it probably isn't a good fit.
Performance improvements are very interesting though - I've noticed that zap is pretty heavy on memory allocations (although there are a lot of optimizations we can make in our own code).

Some issues we are running into currently:

Plugin logs are weird. I'm considering making a fork of go-plugin and swapping out hclog because the interoperability with zap is complicated
Sampling lacks important features such as logging the number of dropped logs. I've implemented this in my fork of zap which we use, but it's annoying to maintain.

As discussed earlier, noting some additional improvement suggestions

fetch agent plugin logs remotely instead of manually
send test log output to a file
I've kept the sampling behaviour the same as before. However, slog-sampling lets you configure the % rate of sampled logs for each log level (eg log 10% Info, 100% error and above). Suggestions welcome


gam info group output issue

The issue tracker is for reporting product deficiencies. How do I questions should be posted to the discussion forum at https://groups.google.com/group/google-apps-manager. When in doubt, start at the discussion forum and return here only when instructed to do so.
Please confirm the following:

I have upgraded to the latest GAM release from http://git.io/gamreleases and I still have this issue. - yes 3.65

I am typing the command as described in the GAM Wiki at https://github.com/jay0lee/GAM/wiki - yes

I am using a Google Apps for Work, Unlimited or EDU account (Google Apps Standard / Free is not supported) - using google apps for work

Full steps to reproduce the issue:

am using "gam info group<EMAIL_ADDRESS>to look up the group setting, I was specifically looking for whoCanPostMessage setting.

Expected outcome (what are you trying to do?): I want to look up whoCanPostMessage setting, and know if it's "public" or "all org members"( which is not totally open to public)
Actual outcome (what errors or bad behavior do you see instead?): both "Public" and "all org members" shown as whoCanPostMessage: ALL_IN_DOMAIN_CAN_POST, which is not very useful in this case.
Is there a way to differentiate those setting better on thru the GAM output?

One issue please


Configure Theano test to use GPU

This pull request should be merged after https://github.com/openai/cleverhans/pull/66

Closes #65

Closes #60

LGTM. Fixed a small dimension mismatch bug


Reduce the boilerplate in transform

Coverage increased (+0.5%) to 83.496% when pulling a43079f56f4785a1077fbccaa88f62cca6d5faa3 on rust-av:less-boilerplate-transform into 6237e6b34fe157c13f1ddd2f0a77029c0666f049 on xiph:master.


.NET6: Garbage collection of Variant crashes

Godot version
v4.0.beta3.mono.official (01ae26d31)
System information
Windows 10, .NET sdk 7.0.100-rc.2.22477.23
Issue description
After a lot of debugging and custom building of the engine, I managed to narrow down a crash when using C# signals containing strings as parameters.
The crashes occur randomly, this is due to memory corruption occurring somewhere in the engine.
My debugger always stopped inside Memory::free_static when cleaning up a Variant of type String whose pointer is already invalid, called from here.
Steps to reproduce
Create a C# signal with a string parameter to connect to, emit the signal somewhere and connect to it somewhere.
It seems like it doesn't matter what string you pass as long as it isn't empty and there has to be some callback connected to the signal.
Minimal reproduction project
Bug.zip

related to #67460
maybe related to #66174

I'm not sure if its related but it seems using "CallDeferred()" also causes this issue.
I think it might be related since it happens immediately or after a random amount of time after using it.
So it could be a GC issue

#68329 Same as you here.

I opened PR https://github.com/godotengine/godot/pull/69194 that may fix this issue, can you try it out to confirm?
Linux users can download the artifact built by CI: https://github.com/godotengine/godot/suites/9514119809/artifacts/451640372
For other platforms, you'll have to build Godot yourself.

I tested #69194, and it fixed the crash caused by signals containing strings as parameters.

Confirmed fixed in beta 8, well done!


Namespaced install attempts to create cluster-wide CRDs

What happened: I created a namespaced cluster with:
NAMESPACED=true FEDERATION_NAMESPACE=dev scripts/deploy-federation-latest.sh my-cluster

then the deployed federation-controller in the "dev" namespace logs the following and exits:
Federation v2 controller-manager version: version.Info{Version:"v0.0.7", GitCommit:"3e251608ca5357080b95a0bedc45759652f17d29", GitTreeState:"clean", BuildDate:"2019-03-22T22:30:26Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
W0408 23:16:26.511755       1 client_config.go:548] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0408 23:16:26.743345       1 log.go:172] Creating CRD clusterpropagatedversions.core.federation.k8s.io
F0408 23:16:26.747413       1 controller-manager.go:108] Could not create CRDs: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "system:serviceaccount:dev:default" cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope

What you expected to happen: Namespaced federation would not reference any CRDs for cluster-scoped resources like "clusterpropagatedversions".
How to reproduce it (as minimally and precisely as possible): Install with the above command on a cluster that's missing any federation-v2 cluster-level CRDs.
Anything else we need to know?:  The namespaced CRDs were created successfully by the namespaced Helm chart.  It's only the cluster-scope CRDs that are missing (and I would expect them to be missing, and not referenced in the federation-controller).
Federation controller arguments from the pod:
  containers:
  - args:
    - --limited-scope=true
    - --federation-namespace=$(FEDERATION_NAMESPACE)
    - --registry-namespace=$(CLUSTER_REGISTRY_NAMESPACE)
    command:
    - /root/controller-manager
    env:
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    - name: FEDERATION_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    - name: CLUSTER_REGISTRY_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    image: quay.io/kubernetes-multicluster/federation-v2:latest
    imagePullPolicy: Always

Environment:

Kubernetes version (use kubectl version) v1.13.2
Federation version v2, v0.0.7
Install method (helm vs script) script/deploy-federation-latest.sh
Install configuration (namespaced vs cluster-scoped) namespaced
Others

/kind bug

As of last week, the controller manager no longer has the ability to install CRDs, so it would not be possible to reproduce this bug with master.  However, until #701 is implemented there is no released chart and the documentation is not clear on the need to specify an image version when deploying from the chart in master.  Once #701 is released I think this issue can likely be closed.

With the helm chart 0.0.9, I need the following doc fix:
--- a/docs/userguide.md
+++ b/docs/userguide.md
@@ -516,7 +516,7 @@ experimenting with federation on a production cluster.
 ### Helm Configuration

 To deploy a federation in a namespaced configuration, set
-`global.limitedScope` to `true` as per the Helm chart [install
+`global.scope` to `Namespaced` as per the Helm chart [install
 instructions](https://github.com/kubernetes-sigs/federation-v2/blob/master/charts/federation-v2/README.md#configuration).

but when I run the Helm install with global.scope=Namespaced, I get:
no matches for kind "FederatedTypeConfig" in version "core.federation.k8s.io/v1alpha1", unable to recognize "":

It seems that some cluster-wide CRDs are still required to do a namespaced install.

@michaelfig A fedv2 deployment depends on a number of API resources (e.g. FederatedCluster, FederatedTypeConfig, etc) that are deployed as CRDs.  CRDs are cluster-scoped resources even if the resources they represent are not (e.g. FederatedCluster is namespaced).  Therefore, deployment of federation depends on having sufficient permissions to create CRDs.
Assuming your use case requires allowing a non-privileged user to deploy namespaced federation, you could achieve this result by creating a chart that would create the CRDs common to deployments of federation.  This chart would need to be installed by a cluster admin. Another chart would deploy the resources required to run a namespaced control plane.  Since enabling propagation for a type requires creating a CRD representing the federated type, a cluster admin would have to perform that operation.
I'm going to close this issue since the original problem has been fixed. The control plane is no longer capable of creating crds as part of its execution, and a documented procedure for deploying a released version of the chart is now available.  Feel free to file a separate issue to continue discussion of non-privileged deployment of namespaced federation.


Fix desktop app bundle

What it solves
Desktop app bundle was broken when homepage was set in package.json. Here the electron bundle is adapted to serve the static files from the /app route to match web app structure
How this PR fixes it
Serve static files from the /app subroute
Also bumps dependencies, with many security fixes
I also enabled the Network switcher in the desktop app

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.008%) to 32.205%

Files with Coverage Reduction
New Missed Lines
%

src/components/AppLayout/Header/components/Layout.tsx
1
0%

Totals

Change from base Build<PHONE_NUMBER>:
0.008%

Covered Lines:
3080

Relevant Lines:
8495

💛  - Coveralls


drop-down all option in server side mode not working

Issue Type (delete the irrelevant ones)

[x] Bug

Specs
What version are you using?
2.9.0
What browser?
chrome
Expected Behavior
show all records after selecting All option in paging bar
all option perPage value should be equal to totalRecords
Actual Behavior
after selecting all option, perPage value is -1

@Alirezanet this is by design. In order to specify 'all' records to the server, you need a non-positive integer value. You can either make a change at the server indicating that -1 == all records... or add a condition in 'on-per-page-change' to catch -1 and change it to whatever value you want to send to the backend.
closing.


[ID proof explorer] Handle id proof request rejection from mobile wallet

When the user rejects a request for an ID proof in the mobile wallet, the rejection is currently not handled in the proof explorer app.
It would be nice if this was the case, to align with how rejection is handled by the browser wallet, and to be able to test this scenario internally.

What happens at the moment? Is there no indication of this? I assume they can recover by refreshing?

What happens at the moment? Is there no indication of this? I assume they can recover by refreshing?

Yes, I also don't think this is a critical thing to solve, but it would be good with confirmation that the rejection can be received in the dapp-end.

Yes, I agree with that. If it takes less than an hour we should just do it. This is relevant for testing the wallet.


Chips with data debug and loot

Hi,
When you want to test a rocket, or try to search for asteroids how do you obtain DATA, some fast way for debug purpouses?
Can we generate some data using a command? To have them for example as a Quest reward, or loot?
(I also added some questions to the Asteroid Mission Setting Issue, please read them)
Thanks and thanks for the mod it is superb.

There is currently a command to fill the data on the entire chip, but it fills all the data to 100%, If memory serves it's "/advRocketry filldata" while holding an asteroid chip.  If you've got a mod that can generate loot with items with NBT you should also be able to add data in whatever amounts you want that way too.


MSSQL - TypeError: _this.driver.Connection is not a constructor

Either there's something going on, or the error message isn't helpful. :-)
My connection works with the base mssql, but not with Knex. Sample code to reproduce (run with babel-node):
import mssql from 'mssql';
import knex from 'knex';

require('dotenv').config();

const test = async () => {
  try {
    await mssql.connect(process.env.DATABASE_URL);
    const result = await mssql.query`select 1 as dbIsUp`;
    console.log(result.recordset);
    mssql.close();
  } catch (err) {
    console.log(err);
  }
};
test();

const db = knex({
  client: 'mssql',
  connection: process.env.DATABASE_URL,
  debug: true,
});

db.raw('select 1 as dbIsUp').then((values) => {
  // there is a valid connection in the pool
  console.log(values);
}).catch((err) => {
  console.log(err);
});

Expected Result:
Connects without errors, OR error message that helps troubleshoot issue
Actual Result:
  knex:pool INFO pool mssql:mssql:client0 - dispense() clients=1 available=0 +0ms
TypeError: _this.driver.Connection is not a constructor
    at /mnt/c/Users/Terry/Projects/gohealth/node_modules/knex/lib/dialects/mssql/index.js:135:24
    at Promise._execute (/mnt/c/Users/Terry/Projects/gohealth/node_modules/bluebird/js/release/debuggability.js:300:9)
    at Promise._resolveFromExecutor (/mnt/c/Users/Terry/Projects/gohealth/node_modules/bluebird/js/release/promise.js:483:18)
    at new Promise (/mnt/c/Users/Terry/Projects/gohealth/node_modules/bluebird/js/release/promise.js:79:10)
    at Client_MSSQL.acquireRawConnection (/mnt/c/Users/Terry/Projects/gohealth/node_modules/knex/lib/dialects/mssql/index.js:134:12)
    at Object.create (/mnt/c/Users/Terry/Projects/gohealth/node_modules/knex/lib/client.js:239:16)
    at Pool._createResource (/mnt/c/Users/Terry/Projects/gohealth/node_modules/generic-pool/lib/generic-pool.js:354:17)
    at Pool._ensureMinimum (/mnt/c/Users/Terry/Projects/gohealth/node_modules/generic-pool/lib/generic-pool.js:408:12)
    at new Pool (/mnt/c/Users/Terry/Projects/gohealth/node_modules/generic-pool/lib/generic-pool.js:157:8)
    at Client_MSSQL.initializePool (/mnt/c/Users/Terry/Projects/gohealth/node_modules/knex/lib/client.js:269:17)
    at Client_MSSQL.Client (/mnt/c/Users/Terry/Projects/gohealth/node_modules/knex/lib/client.js:116:12)
    at new Client_MSSQL (/mnt/c/Users/Terry/Projects/gohealth/node_modules/knex/lib/dialects/mssql/index.js:93:20)
    at Knex (/mnt/c/Users/Terry/Projects/gohealth/node_modules/knex/lib/index.js:60:34)
    at Object.<anonymous> (/mnt/c/Users/Terry/Projects/gohealth/scratch.js:18:12)
    at Module._compile (module.js:571:32)
    at loader (/mnt/c/Users/Terry/Projects/gohealth/node_modules/babel-register/lib/node.js:144:5)
  knex:pool INFO pool mssql:mssql:client0 - dispense() clients=0 available=0 +54ms
  knex:pool INFO pool mssql:mssql:client0 - dispense() clients=0 available=0 +1ms
  knex:pool INFO pool mssql:mssql:client0 - dispense() clients=0 available=0 +0ms
[ { dbIsUp: 1 } ]

Taking from http://stackoverflow.com/questions/43283552/node-js-knex-and-mssql-error-typeerror-this-driver-connection-is-not-a-cons, downgrading to<EMAIL_ADDRESS>solves this issue.
However a proper fix would be needed.

Closing in favor of #1999
Knex currently has no support for node-mssql 4.0.0. (PR Open #2029)

@wubzz - even if support were added, this error still persist!
https://github.com/tgriesser/knex/commit/17bf763cb13543f502668d2f74ae0ca1b2d67a28

@calebeaires Well as far as I can tell #2029 hasn't been published. Or are you testing from master branch?

@wubzz still using 0.13.0. I thought this package were the last one!

Still getting this issue on 0.13.0.
Unhandled rejection TypeError: _this.driver.Connection is not a constructor
at node_modules/knex/lib/dialects/mssql/index.js:135:24
"dependencies": {
"knex": "^0.13.0"
},

Is there any update on when this fix is going to be released and published to npm? Or when is the next release scheduled?

There are no schedules, but I'll make the release before christmas. Maybe this month, maybe some other.

Great. Thanks.

@elhigu any update on this? I believe mssql v4 is needed in order to support multi-subnet-failover. This is a pretty big deal breaker for anyone needing failover support.

Have you checked knex 0.14.4?

Hello all,
I know i'm late to the party...
I'm receiving the same error others above are reporting.
message: "_this.driver.ConnectionPool is not a constructor"
stack: "TypeError: _this.driver.ConnectionPool is not a constructor
    at https://localhost:4321/dist/sqlconnector-webpart-web-part.js:41995:24
    at Client_MSSQL.acquireRawConnection (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:41994:12)
    at create (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:41375:23)
    at https://localhost:4321/dist/sqlconnector-webpart-web-part.js:93108:34
    at Object.tryPromise (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:93289:24)
    at https://localhost:4321/dist/sqlconnector-webpart-web-part.js:93108:17
    at new Promise (<anonymous>)
    at callbackOrPromise (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:93099:12)
    at Pool._create (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:93029:9)
    at Pool._doCreate (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:93001:36)
    at Pool._tryAcquireOrCreate (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:92952:18)
    at Pool.acquire (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:92878:14)
    at https://localhost:4321/dist/sqlconnector-webpart-web-part.js:41428:26
From previous event:
    at Client_MSSQL.acquireConnection (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:41427:34)
    at Runner.ensureConnection (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:52320:24)
    at Runner.run (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:52140:42)
    at Raw.Target.then (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:49474:43)
    at SqlHelperUtil../lib/webparts/sqlconnectorWebpart/environment/SqlHelper/SqlHelperUtil.js.SqlHelperUtil.ExecuteSqlQuery (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:543:46)
    at WebFormEventListeners.ConnectionWizardDataSubmit (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:661:37)
    at ObjectExplorerBuilder.ConnectionWizardDataSubmit (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:924:39)
    at HTMLButtonElement.<anonymous> (https://localhost:4321/dist/sqlconnector-webpart-web-part.js:805:119)"
__proto__: Error {constructor: , name: "TypeError", message: "", …}

Here is my package.json file:
{
  "name": "sqlconnector-webpart",
  "version": "0.0.1",
  "private": true,
  "main": "lib/index.js",
  "engines": {
    "node": ">=0.10.0"
  },
  "scripts": {
    "build": "gulp bundle",
    "clean": "gulp clean",
    "test": "gulp test"
  },
  "dependencies": {
    "@microsoft/sp-core-library": "1.9.1",
    "@microsoft/sp-lodash-subset": "1.9.1",
    "@microsoft/sp-office-ui-fabric-core": "1.9.1",
    "@microsoft/sp-webpart-base": "1.9.1",
    "@pnp/common": "^1.3.5",
    "@pnp/logging": "^1.3.5",
    "@pnp/odata": "^1.3.5",
    "@pnp/sp": "^1.3.5",
    "@types/es6-promise": "^3.3.0",
    "@types/webpack-env": "^1.14.0",
    "graceful-fs": "^4.2.2",
    "jquery": "^3.4.1",
    "tsc": "^1.20150623.0",
    "webpack": "^4.39.2"
  },
  "devDependencies": {
<EMAIL_ADDRESS>"^0.7.29",
    "@microsoft/sp-build-web": "1.9.1",
    "@microsoft/sp-module-interfaces": "1.9.1",
    "@microsoft/sp-tslint-rules": "1.9.1",
    "@microsoft/sp-webpart-workbench": "1.9.1",
    "@types/chai": "^4.2.0",
    "@types/gulp": "^4.0.6",
    "@types/knex": "^0.16.1",
    "@types/mocha": "^5.2.7",
    "@types/mssql": "^3.3.0",
    "ajv": "^6.10.2",
    "globalthis": "^1.0.0",
    "gulp": "^3.9.1",
    "knex": "^0.14.4",
    "mssql": "^3.3.0"
  }
}

I tried installing<EMAIL_ADDRESS>I also downgraded my knex version to 0.14.4 to see if that would help.
The newer version gives an error that says it's not compatible with<EMAIL_ADDRESS>if there's anything else I can do or any advice you could offer me i'd be greatly appreciative.
Oh, and i'm a noob when it comes to typescript so if there is a workaround I may need some guidance/assistance implementing it.
Thank you for your time.
Great job with the library and docs by the way.

latest knex (0.19.x) should work with latest mssql 3.x driver. mssql 4 is not yet supported.


[spring-boot] Automate releaseDate, eol and extendedSupport retrieval

Based on https://spring.io/projects/spring-boot#support.

Expected diff:
diff --git i/releases/spring-boot.json w/releases/spring-boot.json
index f296c92..75c826c 100644
--- i/releases/spring-boot.json
+++ w/releases/spring-boot.json
@@ -1,5 +1,36 @@
 {
-  "releases": {},
+  "releases": {
+    "3.2": {
+      "name": "3.2",
+      "releaseDate": "2023-11-23",
+      "eol": "2024-11-23",
+      "extendedSupport": "2026-02-23"
+    },
+    "3.1": {
+      "name": "3.1",
+      "releaseDate": "2023-05-18",
+      "eol": "2024-05-18",
+      "extendedSupport": "2025-08-18"
+    },
+    "3.0": {
+      "name": "3.0",
+      "releaseDate": "2022-11-24",
+      "eol": "2023-11-24",
+      "extendedSupport": "2025-02-24"
+    },
+    "2.7": {
+      "name": "2.7",
+      "releaseDate": "2022-05-19",
+      "eol": "2023-11-24",
+      "extendedSupport": "2025-08-24"
+    },
+    "2.6": {
+      "name": "2.6",
+      "releaseDate": "2021-11-17",
+      "eol": "2022-11-24",
+      "extendedSupport": "2024-02-24"
+    }
+  },
   "versions": {
     "3.2.3": {
       "name": "3.2.3",


Need enable web3 for mirror node

Feature to Enhance
To use RPC port need web3 enabled in mirror node

Requested Enhancement
Need enable web3 for mirror node

Business Need
To use RPC port need web3 enabled in mirror node

Additional Context
No response

:tada: This issue has been resolved in version 0.24.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


openstack failureDomain: Add RootVolume type

The volumeType is as of OpenStack v17 the canonical way to distribute storage in separate failure domains. This change introduces the ability to set a variable volume type for the Control plane instances.
/cc mandre emilienm

Nice addition, thanks. Could you add a test to the testsuite among rootVolume.availabilityZone maybe? Thanks

/assign JoelSpeed

/hold cancel
This should be ready for another pass!

Are we expecting any further changes? Has this been tested at all to give us confidence in the API? I have no further feedback given we've gone through and established there's no patterns etc that can be applied

I don't expect any further changes on this. As for the pattern, I have slavishly followed the OpenStack ProviderSpec nomenclature.
Tests will happen in the CPMS PR.