All of my BIO3 EXE do not work anymore after seed attempt

I tried to run a seed of the randomizers for RE3 and all of my BIO3 EXE file crash immediately =[ what do i do

Turned out to be a controller issue, new updates are great!Danny Laguer On May 4, 2023, at 6:22 PM, Ted John @.***> wrote:
Did you manage to sort the issue out? Does the vanilla game still work?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>


Support console extensions to VM details navigation

Hello, we're a Red Hat partner building some console extensions and would like to add a horizontal nav tab to the VM details page. Without the KubeVirt plugin loaded, we can do this by adding a console.tab/horizontalNav extension for the VirtualMachine kind. However, once this plugin is loaded, the nav list is loaded from the useVirtualMachineTabs hook so our tab does not appear.

cc @tnisan @avivtur @upalatucci @pcbailey

hei @evanstoner  we fixed it here: https://github.com/kubevirt-ui/kubevirt-plugin/pull/2092


webhook implementation

Description
The webhook parameter allows the system to notify an external service or consumer about the completion status of
an experiment-processing job. When a job is completed, this webhook will be triggered to send an HTTP request to a
predefined URL, configured either via an environment variable (webhookURL) or within a kruize configuration
file.
This notification mechanism is essential for systems that require real-time updates about the job's processing
status, enabling consumers to take immediate follow-up actions. For example, an external analytics dashboard, a
monitoring service, or a message queue like Kafka can listen for these webhook calls to further process or log the
job completion data.
Fixes # (issue)
Type of change

[ ] Bug fix
[x] New feature
[x] Docs update
[ ] Breaking change (What changes might users need to make in their application due to this PR?)
[ ] Requires DB changes

How has this been tested?
Please describe the tests that were run to verify your changes and steps to reproduce. Please specify any test configuration required.

[x] New Test X
[x] Functional testsuite

Test Configuration

Kubernetes clusters tested on:

Checklist :dart:

[x] Followed coding guidelines
[x] Comments added
[x] Dependent changes merged
[x] Documentation updated
[ ] Tests added or updated

Additional information
Include any additional information such as links, test results, screenshots here

@msvinaykumar I think the implementation is unnecessarily adding complexity. What we need is to embed the webhook as part of the Bulk API itself.
{
  "filter": {
    "exclude": {
      "namespace": [],
      "workload": [],
      "containers": [],
      "labels": {}
    },
    "include": {
      "namespace": [],
      "workload": [],
      "containers": [],
      "labels": {
        "key1": "value1",
        "key2": "value2"
      }
    }
  },
  "time_range": {},
  "datasource": "prometheus-1",
  "experiment_types": [
    "container",
    "namespace"
  ]
  "webhooks": {
      "default": "http://URL:PORT/bulkAPIDefaultWebhook",
      "Error": ""http://URL:PORT/bulkAPIErrorWebhook"
  }
}

Also what gets posted on the Webhook is the BulkAPI response as-is.

@msvinaykumar Please fix the conflicts

@msvinaykumar I think the implementation is unnecessarily adding complexity. What we need is to embed the webhook as part of the Bulk API itself.
{
  "filter": {
    "exclude": {
      "namespace": [],
      "workload": [],
      "containers": [],
      "labels": {}
    },
    "include": {
      "namespace": [],
      "workload": [],
      "containers": [],
      "labels": {
        "key1": "value1",
        "key2": "value2"
      }
    }
  },
  "time_range": {},
  "datasource": "prometheus-1",
  "experiment_types": [
    "container",
    "namespace"
  ]
  "webhooks": {
      "default": "http://URL:PORT/bulkAPIDefaultWebhook",
      "Error": ""http://URL:PORT/bulkAPIErrorWebhook"
  }
}

Also what gets posted on the Webhook is the BulkAPI response as-is.

Implemented


Possibly wrong 4WD_Rover config file

Hi,
I'm trying to run a simulation with our 2WD Rover Pro which has an R&D payload and we mounted a LiDAR on top. There are two issues:

In /roverrobotics_description/launch/description-2wd.launch as a config is stated 4WD_Rover_with_SLAM_pack. IMO there shall be a 2WD config with or without SLAM pack available or at least more general naming if the configs are identical.
As soon as you try to launch the same file with 4WD_Rover as a config file, the launch fails.
A workaround was to comment out the accessories in the roverrobotics_description/urdf/2WD_Rover/2WD_rover.urdf.xacro (line 5) and then it loads the robot model without an issue.

Is it possible to revisit the config files and fix that or share how this shall we used, in case one doesn't want to use the SLAM pack option? Thanks in advance!

ping

This is a good workaround, we are not going to be adjusting the config files at this time but we will make note of your workaround and make that information available.


Expand CI matrix to 1.13 / OTP 24

Expand the CI release matrix to cover elixir 1.13.x and erlang/OTP 24. This will allow us to verify compatibility with more recent versions of elixir and erlang.

Closing, covered by https://github.com/fastjames/ex-gpgme/pull/7 .


[Upsert] Skip removing upsert metadata when shutting down the server

When the server shuts down, removing all the metadata from the upsert manager can be time consuming and not provide any value since we re-construct the metadata during restart. This PR tracks whether the upsert manager is closed, and skips the segment remove if it is already closed

Codecov Report

Merging #9551 (06e17c9) into master (1c202c7) will increase coverage by 7.04%.
The diff coverage is 20.00%.

@@             Coverage Diff              @@
##             master    #9551      +/-   ##
============================================
+ Coverage     62.86%   69.90%   +7.04%
+ Complexity     5073     4876     -197
============================================
  Files          1917     1929      +12
  Lines        102523   102881     +358
  Branches      15561    15600      +39
============================================
+ Hits          64449    71921    +7472
+ Misses        33257    25881    -7376
- Partials       4817     5079     +262

Flag
Coverage Δ

integration1
26.05% <0.00%> (+0.03%)
:arrow_up:

integration2
24.44% <0.00%> (-0.33%)
:arrow_down:

unittests1
67.31% <20.00%> (+<0.01%)
:arrow_up:

unittests2
15.70% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...cal/upsert/BasePartitionUpsertMetadataManager.java
56.77% <20.00%> (-1.63%)
:arrow_down:

...data/manager/realtime/DefaultSegmentCommitter.java
0.00% <0.00%> (-80.00%)
:arrow_down:

...er/api/resources/LLCSegmentCompletionHandlers.java
43.56% <0.00%> (-18.82%)
:arrow_down:

...data/manager/realtime/SegmentCommitterFactory.java
88.23% <0.00%> (-11.77%)
:arrow_down:

...inot/core/util/SegmentCompletionProtocolUtils.java
57.69% <0.00%> (-7.70%)
:arrow_down:

...transform/function/IsNotNullTransformFunction.java
65.51% <0.00%> (-6.90%)
:arrow_down:

...or/transform/function/IsNullTransformFunction.java
75.86% <0.00%> (-6.90%)
:arrow_down:

...altime/ServerSegmentCompletionProtocolHandler.java
51.88% <0.00%> (-6.61%)
:arrow_down:

...roller/helix/core/relocation/SegmentRelocator.java
72.97% <0.00%> (-5.41%)
:arrow_down:

...l/segment/index/readers/OnHeapFloatDictionary.java
86.36% <0.00%> (-4.55%)
:arrow_down:

... and 269 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add television series' you have seen or want to

Entourage, heard a lot of good things about that show. #2 #Hacktoberfest

done!


xds: remove wasm metadata exchange fallback

Change-Id: I66556eb42ed7261f849114ec967ee681b431a47a

@kyessenov: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
ad1d55b79cc2a4907f19f6fa522bf7b666f1e1a3
link
true
/test release-notes

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

@kyessenov: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
ad1d55b79cc2a4907f19f6fa522bf7b666f1e1a3
link
true
/test release-notes

lint_istio
ad1d55b79cc2a4907f19f6fa522bf7b666f1e1a3
link
true
/test lint

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


App takes long to launch

It takes ca 10 seconds to launch the app and to show the risk status. This happens since the last update of the app.
Device:
Galaxy A6 (a6lte)
Android 10

How long does it take (1 sec.,5 sec., etc.)?

Hi @ucmichan,
thanks for your feedback.
As @Ein-Tim already commented, can you please let us know how long it takes till the app is launched and the risk status is updated.
How long are you using the App? Was it "slow" from the beginning?
Thanks.
Best regards,
ABB
Corona-Warn-App Open Source Team

It takes ca 10 seconds to launch the app and to show the risk status. This happens since the last update of the app.
I also updated the issue description.

During this 10s launch do you see a loading screen like this one?

Do you have added a test (QR code) in your app?


Rough in "charter" content in README.

Per the discussion in #11 -- I think this is where we've landed for how we are going to jump into this.
In discussion with Jonathan Gregory, I've been advised that our goals around origin/offset style coordinates are not actually out of line with the CF data model documented in Appendix I and that we should probably just go ahead using that CF data model and implementing the compact origin/offset style coordinate variables needed for direct geotiff compatibility as an implementation of the CF data model seperate from the NetCDF-CF convention. I've noted that in deliverables.
I'm not attached to any of this but wanted to move us along since it seems we are in agreement.

Per the conversation at the GeoZarr spec call today, what I have in this PR around the deliverable is not necessarily correct. For now, we are just going to evolve https://github.com/zarr-developers/geozarr-spec/blob/main/geozarr-spec.md to accommodate the full suite of requirements of geozarr. How this is published as a normative standard is an open question. I will try to summarize where I think the group stands regarding that in an update to this PR.

@briannapagan @christophenoel @rabernat -- I think this now reflects where we stand?
https://github.com/zarr-developers/geozarr-spec/pull/13/files?short_path=b335630#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5

Seems very good to me

Yes, I will also commit some minor changes. Thanks David!


Seemingly valid names are being reported as invalid by metadata service

This name appears to be valid: https://app.ens.domains/name/⌐◨‐◨.eth/details
⌐◨‐◨.eth
The eth-ens-namehash.normalize method also doesn't throw any errors:
require("@ensdomains/eth-ens-namehash").normalize('⌐◨‐◨.eth')

⌐◨‐◨.eth

Yet the metadata service is reporting that as invalid: https://metadata.ens.domains/mainnet/0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85/29374690480179650074424749477986431727881478513446796185670528844166493337335/image

I have the same problem with 𓃵𓃵𓃵.eth
Have you found a solution?

When this happens, it appears that the NFT metadata endpoint also returns is_normalized: false.
Are marketplaces like OpenSea/Rarible automatically delisting names because our metadata service is doing this? We have been getting many support tickets in recent days about OpenSea delisting ENS names, when it appears that there's nothing invalid about the name. In some cases this could be due to a human-intervention delisting because OpenSea staff thinks the name is trying to spoof/impersonate some other name.

Oh my bad, I need to explain what goes wrong. So the issue is causing because of ens-validation library, which was previously not in use but after adding emoji support to the library I started to use it in ens-metadata-service actively. The reason why I needed that library is to evaluate non-ascii dangerous patterns more precisely.
Later on we started to see some names invalid. The reason for that, while ens-validation library supports full set of emojis, it apparently does not have support for some of b/w symbols. I was working on adding them into the validation library but there is a big issue about that. The "some" I mention above, basically a lot of it. Those symbols are represented as set of symbols, e.g. (Egyptian_Hieroglyphs, Anatolian_Hieroglyphs and many more.) I am still looking into it to grasp how to handle this issue easier, and what is the estimation of those addings. If this gonna take near forever we may revert usage of validation library for now.

Thanks for the explanation, that definitely sheds some light!
It looks like it's not just those kinds of symbols, but characters from other more common languages too, like Spanish, Greek, etc. For example, someone reported an issue with this name today: ξlon.eth
ξ is lowercase so ξlon.eth should be a valid and normalized name too, but runs into the same problem:
https://metadata.ens.domains/mainnet/0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85/27978210512157853987895129733316778952294480585435466862955698074581821116023

Have you reverted yet? Thanks for the explanation.

This also appears to be happening with other quite common characters too, like €. For example, someone registered €euro.eth today and it was immediately delisted from OpenSea.
Same thing in the metadata service, it's returning "is_normalized: false": https://metadata.ens.domains/mainnet/0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85/75146923466576329054850177628347347164866684791162808436924508302462317903567
require("@ensdomains/eth-ens-namehash").normalize('€euro.eth');

€euro.eth

It's just a guess on my part, but I think that the massive amount of OpenSea delistings we've seen recently are directly tied to our metadata service and the fact that it's incorrectly reporting names as not normalized.

Hi!
thank you serenae-fansubs for mentioning my problem. Yes, I have registered €euro.eth domain. At first it wasn’t showing on opensea at all. Then, after long conversations with their support team, somehow it managed to show up in my account. But again as “invalid name”.
checked my OS account today, it just disappeared from the list of my NFTs.
Is there any solution for that? Is there anything I can do about it or just wait ?
thank you

I've spoken to 8 other people and we are also having this issue! I registered a name a few hours ago and the metadata service incorrectly reported it as not normalized again. PLEASE FIX THIS ASAP! It is causing some of my clients who buy from me on OpenSea and Rarible to distrust me!! >:(

I made a PR for this issue and it should solve the problem for many names, and I will be sure that mistakenly delisted names on NFT marketplaces will relist them.
However what I see in the discussion, some of the reported names may look valid when you check with normalization library but in actual they are not valid when it comes to domain spoof checking. The new library I introduced does this check properly unlike ens-validation library and in case you are in doubt that the name must be valid, you can make a check manually with the official confusable unicode character list.
One example is ⌐◨‐◨.eth @serenae-fansubs  shared.
Here is the quick implementation of spoof check on given name;
https://runkit.com/mdt/ens-confusable
in short, the result is;
'isConfusing'  true
'confusables' [
  { point: '⌐' },
  { point: '◨' },
  { point: '‐', similarTo: '-' },
  { point: '◨' },
  { point: '.' },
  { point: 'e' },
  { point: 't' },
  { point: 'h' }
]
'rectified version' '⌐◨-◨.eth'

'labelhash of original name' '29374690480179650074424749477986431727881478513446796185670528844166493337335'
'labelhash of rectified name' '111440747936573806392167052078801952303595836080754646941339900940965969244004'

Based on this result, if we check opensea with the labelhash of rectified name we see that there is already a valid name with valid characters, so that makes the given name invalid.
https://opensea.io/assets/0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85/111440747936573806392167052078801952303595836080754646941339900940965969244004

Thanks for the updates and work on this!! I definitely appreciate that this is not an easy problem to solve.
At the end of the day, if the manager UI allows a name to be registered, then it should be considered valid in my opinion.
Is this new library also going to be applied to the manager UI too, and will names automatically be redirected to the "rectified" version? Because right now you can search for both ⌐◨‐◨.eth and ⌐◨-◨.eth and different names come up.
And I'm assuming the same changes should be made to ens-eth-namehash too, for its normalize method?
Basically as far as normalization goes, I think it's less important what the actual rules are, and more important that all the places in ENS that uses normalization are consistent, and it sounds like they are currently not consistent, which leads to these issues where someone registers a name and then finds out later that they can't use it.

Manager app UI

Searching for a name should yield the normalized/rectified version of that name
Going directly to the URL of a non-normalized name should redirect to the normalized version (like ⌐◨‐◨.eth should redirect to ⌐◨-◨.eth)

The ENS metadata service
The ENS eth-ens-namehash normalize method, which ENS explicitly recommends client dapps to use for normalizing names

Since it sounds like ENS is changing which names are valid/normalized and which ones aren't, and some people have already registered names through the manager UI that they thought were valid, I'm assuming those people will simply be stuck with unusable/unsellable names, right? Does the ENS core team have any kind of marketing/outreach announcement planned for when this goes live?
Again thanks, I know there is no perfect solution here, and there have been long discussions about this: https://discuss.ens.domains/t/ens-name-normalization/8652/54. Just want to make sure that if we are making this change, that it is made consistent across all the ENS libraries/tools/UI, so that users won't run into this issue again in the future!

At the end of the day, if the manager UI allows a name to be registered, then it should be considered valid in my opinion.
Is this new library also going to be applied to the manager UI too, and will names automatically be redirected to the "rectified" version? Because right now you can search for both ⌐◨‐◨.eth and ⌐◨-◨.eth and different names come up.

Yes, definitely that's my aim to do so. This check should be done in wherever we can integrate it.

And I'm assuming the same changes should be made to ens-eth-namehash too, for its normalize method?

Basically as far as normalization goes, I think it's less important what the actual rules are, and more important that all the places in ENS that use normalization are consistent, and it sounds like they are currently not consistent, which leads to these issues where someone registers a name and then finds out later that they can't use it.
* Manager app UI

  * Searching for a name should yield the normalized/rectified version of that name
  * Going directly to the URL of a non-normalized name should redirect to the normalized version (like [⌐◨‐◨.eth](https://app.ens.domains/name/%E2%8C%90%E2%97%A8%E2%80%90%E2%97%A8.eth/details) should redirect to [⌐◨-◨.eth](https://app.ens.domains/name/%E2%8C%90%E2%97%A8-%E2%97%A8.eth/details))

* The ENS metadata service

* The ENS [eth-ens-namehash](https://github.com/ensdomains/eth-ens-namehash) `normalize` method, which [ENS explicitly recommends client dapps to use](https://docs.ens.domains/contract-api-reference/name-processing#normalising-names) for normalizing names

Currently the library remains separated from normalization library itself, in the future it might be unified or one can be used in another. But one thing is for sure that both checks needs to be done for consistency whenever we do normalization.

Since it sounds like ENS is changing which names are valid/normalized and which ones aren't, and some people have already registered names through the manager UI that they thought were valid, I'm assuming those people will simply be stuck with unusable/unsellable names, right? Does the ENS core team have any kind of marketing/outreach announcement planned for when this goes live?

Currently it is not yet clear. But in general yes, I believe this will be done at some point.

Again thanks, I know there is no perfect solution here, and there have been long discussions about this: https://discuss.ens.domains/t/ens-name-normalization/8652/54. Just want to make sure that if we are making this change, that it is made consistent across all the ENS libraries/tools/UI, so that users won't run into this issue again in the future!

🙏 Absolutely same thoughts

So for example if I were to create a name such as victor’s wallet.eth would
it continue to show as invalid name on opensea/other marketplaces or would
it just have the caution emoji next to it like ⌐◨‐◨.eth?
On Sun, Mar 27, 2022 at 8:27 AM Muhammed Tanrıkulu @.***>
wrote:

I made a PR for this issue and it should solve the problem for many names,
and I will be sure that mistakenly delisted names on NFT marketplaces will
relist them.
However what I see in the discussion, some of the reported names may look
valid when you check with normalization library but in actual they are not
valid when it comes to domain spoof checking. The new library
https://github.com/ensdomains/unicode-confusables I introduced does
this check properly unlike ens-validation library and in case you are in
doubt that the name must be valid, you can make a check manually with the
official confusable unicode character list
http://www.unicode.org/Public/security/latest/confusables.txt.
One example is ⌐◨‐◨.eth @serenae-fansubs
https://github.com/serenae-fansubs shared.
Here is the quick implementation of spoof check on given name;
https://runkit.com/mdt/ens-confusable
in short, the result is;
'isConfusing'  true
'confusables' [
{ point: '⌐' },
{ point: '◨' },
{ point: '‐', similarTo: '-' },
{ point: '◨' },
{ point: '.' },
{ point: 'e' },
{ point: 't' },
{ point: 'h' }
]
'rectified version' '⌐◨-◨.eth'
'labelhash of original name' '29374690480179650074424749477986431727881478513446796185670528844166493337335'
'labelhash of rectified name' '111440747936573806392167052078801952303595836080754646941339900940965969244004'
Based on this result, if we check opensea with the labelhash of rectified
name we see that there is already a valid name with valid characters, so
that makes the given name invalid.
https://opensea.io/assets/0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85/111440747936573806392167052078801952303595836080754646941339900940965969244004
—
Reply to this email directly, view it on GitHub
https://github.com/ensdomains/ens-metadata-service/issues/71#issuecomment-1079931877,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AII7GPRR6KSGUEGE6TEFYPDVCBV4BANCNFSM5NYI4JQA
.
 We go and register a name for x amount of years just to find out we can’t transact with it on 3rd party marketplaces such as Opensea. There was instance a few weeks ago where I was going to buy it’s.eth from Opensea and finally once the seller and I came to an agreed upon price it became invalid on opensea and was later removed from the website as a whole. It seems to be happening to many names that have apostrophes in them

yep I have the same issue I bought a domain name is it has been delisted and I contacted opensea and they said its been permanently delisted and I reckon I have such as good domain being ßullish.eth can I please get some help

Hello ENS team. Support sent me here to report on another 3-letter ENS domain that gives "Invalid name" orange background with an exclamation point for:
õ¿ö.eth
On a different issue, I do have this one without any errors but does not display properly.  The mouth doesn't appear.
ʕʘ̅͜ʘ̅ʔ
Thank you.

I also have the same issue. I just registered an ens domain name that contains the characters [₿], but I can't use this domain name to transfer money in metamask, I can't see my domain name nft on opensea, os prompts me that it can't be displayed, and I can't use this ens domain name in etherscan Search for the corresponding address.

Same issue here but i have domains with emoji letters (🅰🅱🅲🅳🅴, 🅐🅑🅒🅓🅔) all have been delisted

Hey again @mdtanrikulu!
I know the normalization discussion is still ongoing on the forums, but can we expect the metadata service to be reverted in the meantime so that people don't run into the invalid image problem?
Or, should the ENS manager app be updated to not allow the same set of characters that the metadata service currently doesn't allow?
The main issue right now is that people go to the ENS manager website, and it allows them to type in and register a name, and it's only later on that they find out it's invalid. So if this issue isn't going to be resolved anytime soon, would it make sense to at least apply the same normalization changes to the manager UI in the meantime as a stopgap solution?
Thanks!

Hi guys
i registered https://app.ens.domains/name/01.eth/details
it was acceptable input in the search bar but it's being marked as an invalid domain

👱♀.eth  is not showing on opensea , and invalid on looksrare/ x2y2
It is present on my keyboard, does it has xwz ?

I also do have this problem with ◕ω◕.eth

can u do somethin to make appear my
https://app.ens.domains/name/1оо.eth/details
thanks

hi! have the same issue :(
https://app.ens.domains/name/𓂀𓂀𓂀𓂀.eth/details

I’m having the same issue I registered
sΞanmichaΞl.eth and it’s showing up on ens as the lower case Xi, doesn’t show in OS and on Looks says it’s invalid

Here is also the latest live demo app from adraffy: https://adraffy.github.io/ens-normalize.js/test/resolver.html
The normalization ENSIP is not final, but you can use the above tool to check whether your name will be valid in the future or not.
For example @itjustis that name looks fine: https://adraffy.github.io/ens-normalize.js/test/resolver.html#𓂀𓂀𓂀𓂀.eth

But others like the name in the post at the top ⌐◨‐◨.eth will not be valid: https://adraffy.github.io/ens-normalize.js/test/resolver.html#⌐◨‐◨.eth

thanks for the  link serenae, when u say future, how long do u think it will take to have a  normal display?  cause with 3 charachters 1 month registration is around 100$..

i mean when u have a valid name but no display or airdrop this is almost useless

@yoleyo With the current build of that normalization code, it looks like your name will be considered valid: https://adraffy.github.io/ens-normalize.js/test/resolver.html#1оо.eth

That improvement proposal is still in progress and not finalized. Once something is finalized, my hope is that it is applied everywhere.

ENS manager app/website
ENS metadata service
ensjs
eth-ens-namehash
ethers.js
web3.js
Metamask, other wallets/dapps/websites (hopefully is just a matter of updating to the newer version of one of the above libraries)

I'm sure @mdtanrikulu and the other devs will add that normalization code here to the metadata service and manager UI and other ENS places, but it'll be up to other devs in other web3 libraries to abide by the same rules.

All right thanks for the informations, i hope it will be on soon.
is this on this post we will find updates about it?
thanks

Hey can you guys do me the smallest favor nd validate the character ⌐ please? It's the only thing standing in the way of this being a valid ens ⌐◨‐◨.eth. Thanks in advance if you can do it

I have also a problem with the following Domain
ẞot.eth
Do we have any time frame for solving the Problem

Same issue here with po⅁.eth
Registered, appeared on opensea without a name, refreshed metadata and it disappeared. Thanks for fixing this!

do u have any idea when this will be fixed?

I registered the following names and they are not showing on OpenSea and shows as Invalid names on LooksRare

https://adraffy.github.io/ens-normalize.js/test/resolver.html
When I queried my ens name at this address, everything seems normal, but my NFT delist from opensea. I can't even see my NFT in my Trust Wallet.
Please resolve this issue as soon as possible.

I seem to also have this problem.. i am able to see the nft when i see the transaction hash, but on OS/looksrare and other marketplace, it shows as invalid. on metamask and trying to transfer it works fine.
This is my address 😱😱.eth
please help

I seem to also have this problem.. i am able to see the nft when i see the transaction hash, but on OS/looksrare and other marketplace, it shows as invalid. on metamask and trying to transfer it works fine. This is my address 😱😱.eth please help

I think that one would never be considered valid because of the extra Zero-Width Joiner characters you (or whoever registered it) put in there: https://adraffy.github.io/ens-normalize.js/test/resolver.html#😱😱.eth

In my opinion when you can buy it from the app.ens.domain website it should be valid.

I use Turkish in my country and we have a capital letter i. He was banned from everywhere just because his first name had a capital i.
https://en.wikipedia.org/wiki/İ

im also having problems with my doamin, 2pác.eth , as soon i bought it, it got instantly delisted

I have same issue with moonbird’s.eth
No where to be seen on open sea
hopefully resolved soon thanks

any uptdates?

I talked to the team. And the devs are trying to address the issue with opensea metadata. It should be resolved. They just haven’t given me a time frame
Get Outlook for iOShttps://aka.ms/o0ukef

From: yoleyo @.>
Sent: Thursday, May 5, 2022 8:02:54 PM
To: ensdomains/ens-metadata-service @.>
Cc: trxyl @.>; Comment @.>
Subject: Re: [ensdomains/ens-metadata-service] Seemingly valid names are being reported as invalid by metadata service (Issue #71)
any uptdates?
—
Reply to this email directly, view it on GitHubhttps://github.com/ensdomains/ens-metadata-service/issues/71#issuecomment-1118379199, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZAYVJDIS2OJLKCIRQFY2LLVIOME5ANCNFSM5NYI4JQA.
You are receiving this because you commented.Message ID: @.***>

great, thanks for info

It looks like this affects Japanese characters too: ミュウツー.eth
https://metadata.ens.domains/mainnet/0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85/34543231005394167657646627178145067742716461140010355061808593149089148364942

i think having the front throw errors for zero width joiner invalid combinations would be wise.
Any way to make the names that used invalid zero width joiner combinations valid maybe by replacing them with another character?

Same Challenge happening with me via ens regarding 比心♥ - WOuld love for Ens to keep us all updated (play-by-play) via twitter. Thank you!

This is answer from opensea customer service
Hi there,  Thanks for reaching out. I apologize for any inconvenience this may have caused. I understand it can be quite confusing if your ENS is not showing at OpenSea. Don't worry, I’d be happy to clarify why your ENS name is not visible on OpenSea.  ENS allows users to register names that are not valid. For example, they may contain zero-width spacing between characters or invalid characters altogether. Because of this, ENS will remove the names once their system identifies them.  It’s important to note that OpenSea doesn’t control ENS — instead, OpenSea is simply a window into viewing what’s currently in your wallet. If ENS removes something or marks it invalid, it’s not something OpenSea can change. We do, however, display a warning message on ENS names that we believe to be at risk of removal.  With that said, if you believe they incorrectly removed or marked your ENS as invalid, we recommend reaching out to them. Once it’s been corrected, OpenSea will start displaying the name again within your wallet.  Here’s the website to contact ENS directly: https://docs.ens.domains/frequently-asked-questions I know this can be confusing, so please let me know if I can help with anything else. Take care! 😊NemoOpenSea Customer Experience | Hi there,  Thanks for reaching out. I apologize for any inconvenience this may have caused. I understand it can be quite confusing if your ENS is not showing at OpenSea. Don't worry, I’d be happy to clarify why your ENS name is not visible on OpenSea.  ENS allows users to register names that are not valid. For example, they may contain zero-width spacing between characters or invalid characters altogether. Because of this, ENS will remove the names once their system identifies them.  It’s important to note that OpenSea doesn’t control ENS — instead, OpenSea is simply a window into viewing what’s currently in your wallet. If ENS removes something or marks it invalid, it’s not something OpenSea can change. We do, however, display a warning message on ENS names that we believe to be at risk of removal.  With that said, if you believe they incorrectly removed or marked your ENS as invalid, we recommend reaching out to them. Once it’s been corrected, OpenSea will start displaying the name again within your wallet.  Here’s the website to contact ENS directly: https://docs.ens.domains/frequently-asked-questions I know this can be confusing, so please let me know if I can help with anything else. Take care! 😊

Hey there, I was directed to this page by ENS support on twitter regarding the same issue of having an "invalid" names being delisted or not being visible on Opensea. One of the names I registered contained characters from the Japanese keyboard and others contained emoji's. I received the same message Pitter108 received after contacting Opensea. This is an example of one of the names. https://app.ens.eth.limo/#/name/エレブー.eth/details
I'm glad to know it has been something that is being worked on and there will be a resolution for this soon. It's also helpful to know there is a tool that I can use to check names with non ASCII characters, which I'll try to use in the future.
Good luck!

Any update friends? I still didn't receive those registered name.

Having the same issues and found this thread on discord. Payed around 600$ in eth for a 3 character domain which is delisted on Opensea after..  Many people on Discord having this issue for months. A fix or update is needed here before more people lose money...

Is there anybody to fix our problem?

This domains
While browsing around on OS i came across this domain and observed it contains an ⚠
https://opensea.io/assets/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85/641843354079041929038989821364773426388122798518459335069695137152283574237

What brought me to the idea of having some sort of flag to make it evident that some domains contain special characters. If i understand correctly os is just trying to prevent scams. What if we had a mechanism to add a flag to differentiate domains with non discernable characters?

This is another answer from opensea customer service
Hello,
Thank you for patiently waiting for our response. How are you doing? I hope you are well.
I am very sorry to hear that your ENS domains doesn't show in OpenSea. I understand that this has been frustrating, and I do apologize for the inconvenience it has caused. Rest assured that I will do my best to clarify why your ENS name isn’t visible on OpenSea.
Taking a look at the item’s history, your ENS name was delisted under our Terms of Service, meaning it will no longer appear on our platform. I understand this can be really disappointing.
If an ENS name violates our Terms of Service, or we receive a DMCA request, we may be obligated to remove it from OpenSea. However, please rest assured that your domain name is still valid, even if we aren’t able to display it on our platform. The ENS is still in your wallet, and can be seen on other platforms for sale. We can’t confirm whether it violates the Terms of Service of other websites.

I know that this is not the response you are expecting to hear, and I understand the disappointment. I wish I can provide you with a better resolution, so if I can help you in another way, please let me know. Don't hesitate to reach out back to me, I'm just here for you.

What that mean ☝. Is that That means we lost our money ? How can I sale my nft ?
Any response I really appreciate

I think if OS continues to delist domains like this then ens should also update its list of valid domains and remove those which do not fulfill the terms and conditions of exchanges or just show a warning sign at the time of minting

https://adraffy.github.io/ens-normalize.js/test/resolver.html#リヴァイ・アッカーマン               リヴァイ・アッカーマン    is showing normalized but still not appering on OS , is there any other way to check normalization before minting a domain

This is another answer from opensea customer service
Hello,
Thank you for patiently waiting for our response. How are you doing? I hope you are well.
I am very sorry to hear that your ENS domains doesn't show in OpenSea. I understand that this has been frustrating, and I do apologize for the inconvenience it has caused. Rest assured that I will do my best to clarify why your ENS name isn’t visible on OpenSea.
Taking a look at the item’s history, your ENS name was delisted under our Terms of Service, meaning it will no longer appear on our platform. I understand this can be really disappointing.
If an ENS name violates our Terms of Service, or we receive a DMCA request, we may be obligated to remove it from OpenSea. However, please rest assured that your domain name is still valid, even if we aren’t able to display it on our platform. The ENS is still in your wallet, and can be seen on other platforms for sale. We can’t confirm whether it violates the Terms of Service of other websites.    I know that this is not the response you are expecting to hear, and I understand the disappointment. I wish I can provide you with a better resolution, so if I can help you in another way, please let me know. Don't hesitate to reach out back to me, I'm just here for you.

Can a dev confirm that this is true? Meaning with the update OS doesn't list the domain anymore?

https://adraffy.github.io/ens-normalize.js/test/resolver.html#リヴァイ・アッカーマン リヴァイ・アッカーマン is showing normalized but still not appering on OS , is there any other way to check normalization before minting a domain

based on what i've read so far around on discord and on gitbub, the character "ー" got caught up in one of the latest updates which renders all names with that character as 'invalid'. hopefully the ens team is willing to look at that character specifically since it bricks a chunk of japanese characters.

it seems that even on my metamask, under the ENS assets, i dont see the ens domain i registered. can we have an update on this?

I bought 3 digit domain, using non character. When I check the domain  it says valid and registered by me. But its delisted in opensea and it says invalid address with red background

and we all waiting for a fix, but nothin seems to be coming

It is coming! I assure you, devs have been hard at work on this: https://discuss.ens.domains/t/ens-name-normalization/8652/128
Not all names will become valid after the change though! The code is not final, but this live demo site can be used to get a good idea of what will be valid/invalid per the metadata: https://adraffy.github.io/ens-normalize.js/test/resolver.html

Hello thank you for reply ,  i checked live link you sent, I entered my domain which had delisted from opensea “aрe.eth”  the “р” alphabet is different thats why they delisted it from OS.  Do you think they will fix it ?

hi, i bought some JP ENS:
ユクシー.eth
0x17595d4ed4e2d0af4ce013560fa2884f8efa38234cd0622fec0645c7e891a257
https://metadata.ens.domains/mainnet/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85/19921806114804879714177476371129274652135542314822121026147215006123759778213
マーシャドー.eth
0xaa2dc94305a7a5677166c8564f95e269270dfcc1484b6f2925f889f3662157df
https://metadata.ens.domains/mainnet/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85/70014084200189111013728177536713399682074110973574252266516382054367630835630
i think the problem is with this character 'ー' that is used in most of JP words. hope you can fix this character

any progress? still waiting on my n°1.eth , n°2.eth, n°3eth,.. n°5eth, n°7eth n°9eth n°10.eth n°20.eth and n°50.eth??

@mdtanrikulu Is there a status update on this issue?
I notice we're still receiving support tickets and forum inquires about this.

@mdtanrikulu Is there a status update on this issue?
I notice we're still receiving support tickets and forum inquires about this.

Hi @coltron-code and everyone wondering the progress in here.
We patched ens-app as in same fashion as metadata service to prevent future delisting issues.  Currently both services work with ens-validation library, which means no other name registered trough ens-app will be delisted from now on.
Of course this is not an ultimate solution, since the problem is in core of ens-validation library itself, but a measure to keep the issue under control in some extent.
The main work and discussion regarding normalization continues here.
When the normalization spec settles, we will be using this standard in all services asap.

since the normalization spec is settled, and reimbursement for the invalid names are done, closing this issue.


[feature] registry-username should be a secret

Is your feature request related to a problem? Please describe.
The registry-username input of the generator_container_slsa3 workflow is declared as input which prohibits using secrets as values. The following example fails:
  provenance:
    uses<EMAIL_ADDRESS>    with:
      registry-username: ${{ secrets.DOCKER_USERNAME }} # NOT ALLOWED
    secrets:
      registry-password: ${{ secrets.DOCKER_PASSWORD }}

Describe the solution you'd like
The registry-username input should be a secret. Example workflow should look liks this:
  provenance:
    uses<EMAIL_ADDRESS>    secrets:
      registry-username: ${{ secrets.DOCKER_USERNAME }}
      registry-password: ${{ secrets.DOCKER_PASSWORD }}

Describe alternatives you've considered
I thought about publishing slsa data in ghcr but it feels weird when everything else is in dockerhub.
Additional context
This is only relevant when you are NOT using ghcr to publish images.

Hi @sebhoss thanks for the report. I agree we should not force users to expose their usernames.
Can you tell us more about the risk you have in mind:

The username is not redacted from the logs?
The username is available from the source code in your repo.
Both?

Hey thanks for getting back to me. My initial concern was really more about an usability issue that stops me from using a variable instead of hard-coding my username in multiple repositories within a single GitHub organization. Declaring the username as a secret would allow me to use the 'secrets' mechanism that GitHub currently offers. The docker/login-action uses the same idea in its initial example at https://github.com/docker/login-action#docker-hub and I'm guessing that lots of people have a setup very similar to that. However, they cannot re-use the same (secret) variables to configure the action from this repository because they will get an error similar to this:
Unrecognized named-value: 'secrets'. Located at position 1 within expression: secrets.DOCKER_USERNAME

By declaring the username of this action a secret, the workflow config could look like this:
jobs:
  login:
    runs-on: ubuntu-latest
    steps:
      - uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      ...
  provenance:
    uses<EMAIL_ADDRESS>    secrets:
      registry-username: ${{ secrets.DOCKER_USERNAME }}
      registry-password: ${{ secrets.DOCKERHUB_TOKEN }}

I could not find a lot of documentation why reusable workflows make this distinction between inputs and secrets but it's causing an inconsistency in workflow configuration and might frustrate adopters of the slsa actions.
That said, https://github.com/github/roadmap/issues/575 sounds like a great solution as well and I'm fine with waiting for that to land - feel free to close this ticket!

Thanks for the explanation. We'll make sure to update our doc once https://github.com/github/roadmap/issues/575 is landed.
The problem you're encountering is that reusable workflows are isolated so env variables and secrets are not available by default.
Here are options to consider in the meantime:

use of inherit https://github.blog/changelog/2022-05-03-github-actions-simplify-using-secrets-with-reusable-workflows/. I'n not 100% sure this will work, but give it a try and let us know.
declare a second job to set the variable:

jobs:
  username:
    outputs:
      username: ${{ steps.username.outputs.value }}
    runs-on: ubuntu-latest
    steps:
      # WARNING: please verify this works. Will the secrets be redacted?
      - run: echo "value=${{ secrets.DOCKER_USERNAME }}" >> $GITHUB_OUTPUT
         id: username
  login:
    needs: [username]
    runs-on: ubuntu-latest
    steps:
      - uses: docker/login-action@v2
        with:
          username: ${{ needs.username.outputs.username }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      ...
  provenance:
    needs: [username]
    uses<EMAIL_ADDRESS>    secrets:
      registry-username: ${{ needs.username.outputs.username }}
      registry-password: ${{ secrets.DOCKERHUB_TOKEN }}

Let me know if any of these work. The second option is not great UX-wise :/
@ianlewis any other ideas?

I've tried the workaround, but still did not work.
https://github.com/vincentgoat/kubeedge/actions/runs/3754855275/workflow

Yeah, set-output skips output of the username because the value might contain a secret so the workaround won't work.
This is a separate downside of putting usernames in secrets. GitHub will sanitize the output of anything with the username in it.

I think there is at least one exception for public usernames: An AWS Access Key ID can be used when pushing into ECR repositories and those keys are part of GitHub secrets scanning feature (https://docs.github.com/en/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-alerts). This prohibits you from writing that key as plain text into your repository.

I think there is at least one exception for public usernames: An AWS Access Key ID can be used when pushing into ECR repositories and those keys are part of GitHub secrets scanning feature (https://docs.github.com/en/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-alerts). This prohibits you from writing that key as plain text into your repository.

I've only ever seen the aws ecr get-login-password method for logging into the ECR registry, where the username is "AWS". In that case you use the AWS access key id for the username and secret access key for the password? Is that documented somewhere?

Yeah I think the recommend practice is NOT to use access keys but rather that assume-role stuff. The usage of an access key is documented/shown at https://github.com/docker/login-action#aws-elastic-container-registry-ecr

Yeah, fair enough. I think the Access key ID is enough of a secret value that you'd want to keep it in a secret (though at least using the aws CLI is the preferred method).
BTW, My comment above was referring to the fact that, on the other hand, if you use secrets to hold usernames like "AWS" when using the aws CLI method, then GitHub will sanitize and skip output of any values in the workflow that have the value "AWS" in them, sometimes causing massive breakage.

Hey all,
As a heads-up, we'll likely be reverting the repository-username input (as it has not been released yet) that we added and asking folks to use the new support for configuration variables to store the repository username. This is just to keep our workflow API cleaner since Github supports variables natively now.
You can add it to your repository's environment and access it using vars.
  provenance:
    uses<EMAIL_ADDRESS>    with:
      registry-username: ${{ vars.DOCKER_USERNAME }}
    secrets:
      registry-password: ${{ secrets.DOCKER_PASSWORD }}

I just tested this with some workflows and it works as expected using 1.4.0

As a heads-up, we'll likely be reverting the repository-username secret input (as it has not been released yet)

After getting a https://github.com/slsa-framework/slsa-github-generator/pull/1550#issuecomment-1396074022 from @34fathombelow  and reviewing the issue again, I think I will go ahead and leave in the repository-username secret input. We did  have one issue with regard to public usernames (https://github.com/slsa-framework/slsa-github-generator/issues/1347#issuecomment-1362494259) that the new variables feature won't solve so I think the change is actually warranted. I'll close #1550 and add the e2e test for it back in.
Hopefully I can get time to create a release in the next week or so.


Jobs view doesn't load when going directly to page-alpha

I think this is a relatively new issue since it's not an issue on beta.

Go directly to https://www.alpha.patricbrc.org/job/ (or go there and reload page) and my jobs list doesn't show up.  I noticed the list will show up after sorting.

My updates last week caused this as they aren’t complete yet.  The updates i committed last week address some of the performance issues with the Jobs Grid, but also cause this issue.  Will take a look when i can.

On Oct 10, 2016, at 12:32 PM, nconrad<EMAIL_ADDRESS>wrote:
I think this is a relatively new issue since it's not an issue on beta.

Go directly to https://www.alpha.patricbrc.org/job/ https://www.alpha.patricbrc.org/job/ (or go there and reload page) and my jobs list doesn't show up. I noticed the list will show up after sorting.

https://cloud.githubusercontent.com/assets/1194246/19243394/239e6520-8edd-11e6-8fd9-395c20d0140b.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/PATRIC3/patric3_website/issues/1014, or mute the thread https://github.com/notifications/unsubscribe-auth/AALobh8Dqzz-CRcaomnowmQEwNzaWT3mks5qymiYgaJpZM4KSwTj.

Fixed.


camera angle for calibration

Hi. I am trying to do the calibration now. But I have a question:
Is it ok if we set the camera at angles of 60 degree above about the arena? I think the angle over 45° should affect the accuracy of calibration. I wonder if >45° angle is not acceptable in the experiment.
Please give your advice. Thank you very much.

Tagging @spoonsso for the clarification.

There is no issue with calibrating at those angles. The only issue with steeper camera angles is that they may not capture the animal appendages as well (via occlusion by the body)


Reghbali nnunet import

Description
This PR adds support for BIDS and individual lesion quantification and modifies the docs.
Motivation and Context

BIDS standard is used for organizing neuro-imaging research data. While still not fully supportive of clinical sequences, it can be used for organizing clinical data. This PR adds an implementation of PipelineDataDir for BIDS.

-Individual lesion statistics should be also generated by the pipeline. This PR adds the step for that.
Test Plan
New unittest is added and multiple tests are updated.
Reviewers

please run integration

please run integration

comment

comment

re

@deploy

@deploy

'@deploy'

"@deploy"

e2e

please run integration

please run integration

ok

ok


Survey Delete Dialog Box Implemented

[Implement ODK-X  Delete dialog box issue 458 ](https://github.com/orgs/odk-x/projects/2/views/1?pane=issue&itemId=48440748
Here is a comparism before and after

)

SVG logo version: https://drive.google.com/drive/folders/1N_P_VJuTCiIfkguiWw1BzAVk6TqZP90G

@Redeem-Grimm-Satoshi PR updated

@r0ssing This looks good, please go ahead and merge it


Hive engine shall respect hive.server2.enable.doAs

:mag: Description
Issue References 🔗
Currently, the Hive engine ignores hive.server2.enable.doAs and always constructs HiveSessionImplwithUGI
Describe Your Solution 🔧
Hive engine shall respect hive.server2.enable.doAs, to align the behavior with HiveServer2
Types of changes :bookmark:

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Behavior Without This Pull Request :coffin:
The Hive engine always constructs HiveSessionImplwithUGI
Behavior With This Pull Request :tada:
When hive.server2.enable.doAs is true, the Hive engine constructs HiveSessionImplwithUGI;
When hive.server2.enable.doAs is false, the Hive engine constructs HiveSessionImpl;
Related Unit Tests

Checklists
📝 Author Self Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] This patch was not authored or co-authored using Generative Tooling

📝 Committer Pre-Merge Checklist

[x] Pull request title is okay.
[x] No license issues.
[x] Milestone correctly set?
[ ] Test coverage is ok
[x] Assignees are selected.
[ ] Minimum number of approvals
[x] No changes are requested

Be nice. Be informative.

cc @zhouyifan279

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (65ba3b1) 61.32% compared to head (4ac97a7) 61.37%.
Report is 1 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #5778      +/-   ##
============================================
+ Coverage     61.32%   61.37%   +0.05%
  Complexity       23       23
============================================
  Files           607      607
  Lines         35940    35940
  Branches       4932     4932
============================================
+ Hits          22040    22059      +19
+ Misses        11506    11500       -6
+ Partials       2394     2381      -13

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Thanks, merged to master/1.8


No live threads left while saving

Hi guys!
I have trouble when trying to save object:
2.1.5 :001 > user = User.new(bio: 'test')
 => #<User id: nil, first_name: nil, user_name: nil, bio: "test", birthdate: nil, active: nil, created_at: nil, updated_at: nil>
2.1.5 :002 > user.save!
fatal: No live threads left. Deadlock?
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/ione-45e1f52da02d/lib/ione/future.rb:667:in `pop'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/ione-45e1f52da02d/lib/ione/future.rb:667:in `value'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/gems/cql-rb-2.0.4/lib/cql/client/client.rb:553:in `block in prepare'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/gems/cql-rb-2.0.4/lib/cql/client.rb:60:in `synchronous_backtrace'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/gems/cql-rb-2.0.4/lib/cql/client/client.rb:553:in `prepare'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/datastax_rails-eec9c50dd18d/lib/datastax_rails/cql/base.rb:42:in `block in execute'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/notifications.rb:164:in `block in instrument'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/notifications.rb:164:in `instrument'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/datastax_rails-eec9c50dd18d/lib/datastax_rails/cql/base.rb:29:in `execute'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/datastax_rails-eec9c50dd18d/lib/datastax_rails/persistence.rb:154:in `write_with_cql'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/datastax_rails-eec9c50dd18d/lib/datastax_rails/persistence.rb:83:in `block (2 levels) in write'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/notifications.rb:166:in `instrument'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/datastax_rails-eec9c50dd18d/lib/datastax_rails/persistence.rb:77:in `block in write'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/datastax_rails-eec9c50dd18d/lib/datastax_rails/persistence.rb:76:in `tap'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@activiter/bundler/gems/datastax_rails-eec9c50dd18d/lib/datastax_rails/persistence.rb:76:in `write'
... 22 levels...
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/railties-4.2.0/lib/rails/commands/console.rb:9:in `start'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/railties-4.2.0/lib/rails/commands/commands_tasks.rb:68:in `console'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/railties-4.2.0/lib/rails/commands/commands_tasks.rb:39:in `run_command!'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/railties-4.2.0/lib/rails/commands.rb:17:in `<top (required)>'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:274:in `require'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:274:in `block in require'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:240:in `load_dependency'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:274:in `require'
	from /Users/adammarkowski/IdeaProjects/Activiter/bin/rails:8:in `<top (required)>'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:268:in `load'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:268:in `block in load'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:240:in `load_dependency'
	from /Users/adammarkowski/.rvm/gems/ruby-2.1.5@global/gems/activesupport-4.2.0/lib/active_support/dependencies.rb:268:in `load'
	from /Users/adammarkowski/.rvm/rubies/ruby-2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /Users/adammarkowski/.rvm/rubies/ruby-2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from -e:1:in `<main>'2.1.5 :003 >

This is my User model:
class User < DatastaxRails::Base
  uuid    :id
  string  :first_name
  string  :user_name
  text    :bio
  date    :birthdate
  boolean :active
  timestamps
end

I've set ione and datastax_rails to github repositories at Gemfile, but this didn't change anything at all.

It seems that cql-rb works fine:
'''
2.1.5 :001 > client = Cql::Client.connect(hosts: ['localhost'])
2.1.5 :002 > client.use('activiter_development')
=> nil
2.1.5 :014 >   client.execute("INSERT INTO users (id, bio, user_name) VALUES (uuid(), '2013-02-24T10:14:23+0000', 'Rang bell, ate food');")
=> #Cql::Client::VoidResult:0x007fc05b9a10f0
2.1.5 :015 >
2.1.5 :015 > client.execute("select * from users")
=> #<Cql::Client::QueryResult:0x007fc05b978e20 ................
'''

Ok, one of the guys finally reminded me where I saw that issue before, but I don't think it's going to apply here.  It was if you tried to execute a CQL query while you were in a byebug session.  Byebug seemed to be locking the thread up.  I don't suppose there's any chance that's happening here is it?  I tried replicating what you described above with several versions of Ruby and Rails and couldn't make it happen.

I had a similar problem (though with any query, including where queries). In my case the problem was Spring. Try it by starting rails without spring ('DISABLE_SPRING=true rails c').


Prevent progress to next stage of analysis until "completed" the current step

Expected Behavior
The interface should prevent you from moving to the next stage of the image analysis until you have completed the current step, whatever that means for each step.
Current Behavior
You can proceed to, for example, "Annotate and segment" wthout importing any images.
Context (Environment)

Detailed Description

Possible Implementation

Checklist before submitting

[ ] I have confirmed this using the officially supported Docker Compose setup using the local.yml configuration and ensured that I built the containers again and they reflect the most recent version of the project at the HEAD commit on the master branch
[ ] I have searched through the other currently open issues and am confident this is not a duplicate of an existing bug
[ ] I provided a minimal code snippet or list of steps that reproduces the bug.
[ ] I provided screenshots where appropriate
[ ] I filled out all the relevant sections of this template

Will be thinking about a good practice solution for this.

If nobody has working on this yet, I will begin tomorrow.

So I think since each tab are controlled by vue-router, the solution to this would be to add a gate layer to each route and check for condition.
https://router.vuejs.org/en/advanced/navigation-guards.html
Will be going through the doc and implement a simple gate layer for each route.


typo?

x:Class="Names.MainWindow" instead of x:Class="Names.LayoutStep2"?

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 097f0935-4e55-891d-5a27-fb898d63d8f3
Version Independent ID: cce4458e-b162-09f3-48ea-b4481aa4c183
Content: Create a new app with Visual Studio tutorial - WPF .NET
Content Source: dotnet-desktop-guide/net/wpf/get-started/create-app-visual-studio.md
Product: dotnet-desktop
Technology: dotnet-wpf
GitHub Login: @adegeo
Microsoft Alias: adegeo

Thank you for taking the time to report this.
The LayoutStep2 is a side effect of the code snippet system that imports code during publish. I can't reuse the same class name to show the progression of before/after. I can hide that portion of code though, just showing the grid itself.


RFC: Add support for Dataspace

💬 Request for Comments
Right now the requirement to specify project, version, mapping, runtime to create a new query is a little too technical, we would like to have a preset for these coordinates when creating new queries. This concept DataSpace would also be used to contain a description of semantics or taxonomy of the models within a project.

[x] Add a dummy shape for DataSpace in finos/legend-pure for the classifier path (https://github.com/finos/legend-pure/pull/320)
[x] Add support for DataSpace (as a Packageable Element) (protocol, grammar, compilation) in legend-engine-language-pure-dsl-data-space in finos/legend-engine (https://github.com/finos/legend-engine/pull/369)
[x] Add support for this in finos/legend-studio (https://github.com/finos/legend-studio/issues/469)
[ ] Support creating query from DataSpace in Legend Query

https://github.com/finos/legend-depot/issues/20
[ ] Query for now, due to the blocker on depot site, we will mock some DataSpaces for demo and development
[ ] Query We will need to do some verification to make sure the coordinate of DataSpace works
[ ] Query Add the 4th mode to create a query from a DataSpace, let's make it so that if we detect a Diagram, we render the diagram and allow people to right-click on the type and create a query from that class, for this to happen, we need to:

[ ] Create an extension mechanism in LegendQuery to allow different modes of creating queries
[ ] Make DataSpace DSL depend on  Diagram DSL as it should be and for the plugin in LegendQuery, render the diagram and such
[ ] Create an extension mechanism in Diagram DSL to allow extending the list of context menu when right-clicking a class view

// TODO
//
// 1. Go through the
// 2.
// 3. Put `Start from DataSpace` and `Load existing query` as main options on the main screen
//    Consider hiding other modes
//
// 4. How to require access/entitlement to make the query
// 5.  In terms of mapping/runtime: the execution context (mapping, runtime)
// 2. In terms of taxonomy, data meaning, dictionary: could we make user explore things better
// 3.

// ###Pure
// Class model::DataSpace2
// {
//   business: String[1];
//   dataTypes: String[*];
//   subSpaces: model::DataSpace2[*];
//   ...
// }
###DataSpace
DataSpace model::dataSpace
{
  // @John: `groupId` and `artifactId` might not be needed
  // should just be the same as the
  groupId: 'test.group.verylonggroup.annie';
  artifactId: 'test-data-space';

  versionId: '1.0.0';

  // @John: Have `mapping` and `runtime` as lists of `pairs`,
  // e.g. realms (same mapping, different universes), similar mappings (slightly different)
  mapping: model::something::Mapping;
  runtime: model::something::Runtime;

  description: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Consequat mauris nunc congue nisi vitae. Pellentesque massa placerat duis ultricies lacus sed turpis tincidunt id. Felis eget velit aliquet sagittis id consectetur purus ut. Pretium aenean pharetra magna ac placerat vestibulum lectus mauris ultrices. Sapien eget mi proin sed libero. Lectus vestibulum mattis ullamcorper velit sed ullamcorper morbi. Eu facilisis sed odio morbi. Tempor orci dapibus ultrices in iaculis nunc sed augue. Pharetra convallis posuere morbi leo urna. Libero enim sed faucibus turpis in eu. Suspendisse in est ante in nibh. Amet volutpat consequat mauris nunc congue nisi.';
  diagrams: [
    model::Diagram1,
    model::Diagram2
  ];
  supportEmail<EMAIL_ADDRESS>}


pythonPackages.dateutil: 2.5.3 -> 2.6.0

Motivation for this change
nix-build -A python35Packages.sympy fails to build both before and after the update.
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] Linux

[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

See also #22870.

Youch, I missed the existing PR. I close this one.

No need for that; I prefer this commit since you also move the file :)
Anyway, as pointed out in the other PR, apparently it broke cairoffi on darwin.


merge from template-arlac77-github

package.json

chore(deps): add ^11.10.3 remove ^11.10.2 (devDependencies.npm-pkgbuild)

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

npm package (@latest dist-tag)
v5.0.117
GitHub release

Your semantic-release bot :package::rocket:


Improved Performance for Fixed List Columns

Goal: Load Fixed List Columns more quickly.
Columns with fixed and ragged list features currently take significanlty longer to load compared with scalar features. See #82
This is a first step toward making list features load more quickly.
Handling the special case of fixed list features where the lists are all of the same length, we can bypass some of the slower code that handles ragged lists and load these more quickly.

Following the refactor of list handling #104 this PR has too many conflicts and demonstrates the difficulty we had with the code as it was before.
I've opened a new PR #112 that extracts and builds on the relevant parts from this one.


Adding audio and subtitle flag for ffmpeg muxing options

I noticed that after the muxing process is finish there is no language flag for the audio and subtitle in the mediainfo.
I would suggest adding these options to ffmpeg if you are planning on supporting multi language subtitles.

Good point. Right now, audio language is always Japanese and subtitle language is always English.
It shouldn't be too hard to tag them appropriately, and it's a nice enhancement.

Good point. Right now, audio language is always Japanese and subtitle language is always English.
It shouldn't be too hard to tag them appropriately, and it's a nice enhancement.


Add Danger

Add Danger
Add mocha, chai, and sinon as dev dependencies.

Hrm, did I ship a bad build?

can you try 3.3.1? :)

The danger side of this is now all good

Included 2 more changes to this PR:

Update karma-phantomjs-launcher to 1.0.2 and fix the PhantomJS browser timeout issue.
Freeze node version at 6.9.4 to avoid the issue temporarily:

Store.prototype.__proto__ = EventEmitter.prototype;
                                        ^
TypeError: Cannot read property 'prototype' of undefined
    at Object.<anonymous> (/home/travis/build/artsy/day-schedule-selector/node_modules/socket.io/lib/store.js:35:41)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/travis/build/artsy/day-schedule-selector/node_modules/socket.io/lib/manager.js:16:13)
    at Module._compile (module.js:571:32)
npm ERR! Test failed.  See above for more details.
The command "npm test" exited with 1.

          1 Error

:no_entry_sign:
Please provide a summary in the Pull Request description

  Generated by :no_entry_sign: danger

Oh yeah Danger works! Thanks, @orta!


Feat(bangpy_ops):update bangpy version to 2.1.0.

PR: https://github.com/Cambricon/mlu-ops/pull/151

done


Implement targeted sign out

https://aws.amazon.com/about-aws/whats-new/2021/06/amazon-cognito-now-supports-targeted-sign-out-through-refresh-token-revocation/
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-document-history.html

Ah nice one, so we don't automatically log out all devices at once :D


Typo in "New issue" page on k/website issues

This is a Bug Report

Problem:
There is a Kubernetes Dashboard project in about at .github/ISSUE_TEMPLATE/support.md
It's better to change Kubernetes Dashboard project with Kubernetes Website project
Proposed Solution:
Change Kubernetes Dashboard project with Kubernetes Website project in about of .github/ISSUE_TEMPLATE/support.md
Page to Update:
https://github.com/kubernetes/website/issues/new/choose

/lifecycle active
/priority backlog


Precise refresh rate

Any plans for glfwGetVideoMode to return a more precise refresh rate? Some monitors refresh at TV-compatible timing and actually fall between integer values. For example, I have a monitor that refreshes at 59.94Hz, but glfw reports it as 59Hz.

This would be useful for me. I overclock my monitors, so showing precise frame rates is useful

Forgive me for resurrecting this, but I could really use this feature. Knowing the exact refresh rate of the monitor can be used to reduce the input lag from V-sync through some clever tricks I'd like to try. Would it be possible to add this earlier than 4.0?

@theagentd Probably not, but I'll see if I can offer you a workaround.

Simply being able to GET the precise refresh rate of the current display mode would be enough for my tests.

Would some code based on the native access functions be useful to you?

What exactly does that mean? I'm OK with only having it for Windows for testing purposes if that's what you mean.

Plus one for a more precise refresh rate.  In my engine, I use the refresh rate to play precise animations, and the integer refresh rate makes animations drift on platforms where I'm relying on glfw.  It's sad that the high precision refresh rate exists for a split second inside glfw but then gets rounded away :)

@elmindreda
This issue was opened in 2014; 9 years ago, and GLFW 4 is still not arriving yet. There are ways to support this functionality in GLFW 3. The current GLFWvidmode and glfwGetVideoMode can be marked as deprecated, and removed in GLFW 4, and a new opaque GLFWvideoMode object can be added now, which is retrieved with glfwGetVideoMode2 (The 2 suffix gets removed in GLFW 4). This is similar to how Vulkan updates its API. This is also exactly what Apple did with their CGDisplayMode.
typedef struct GLFWvideoMode GLFWvideoMode;

GLFWAPI GLFWvideoMode* glfwGetVideoMode2(GLFWmonitor* monitor);

GLFWAPI float glfwVideoModeGetRefreshRate(GLFWvideoMode* videoMode);
// ... etc

Is this something you'd be interested in?

This sounds like a great approach.

I agree, it'd be more modular in the future too.

As it's not possible to have an array of opaque objects, glfwGetVideoModes2 can't have a similar signature to glfwGetVideoModes without increasing GLFW's memory usage, as it requires a separate internal array of pointers. This is a very tiny amount of memory, and it keeps GLFW's API just as simple as before, so it should be the preferred design, but I'll leave two other options here anyway.
2:
int glfwGetAvailableVideoModesCount(GLFWmonitor* monitor);
GLFWvideoMode* glfwGetAvailableVideoMode(GLFWmonitor* monitor, int index);

3:
typedef struct GLFWarray GLFWarray;

struct _GLFWarray
{
    int count;
    int stride;
    char* data;
};

typedef struct _GLFWarray _GLFWarray;

GLFWAPI int glfwArrayGetCount(const GLFWarray* array)
{
    return ((_GLFWarray*) array)->count;
}

GLFWAPI void* glfwArrayGetElement(const GLFWarray* array, int index)
{
    const _GLFWarray* _array = (_GLFWarray*) array;

    assert(index >= 0);
    assert(index < _array->count);

    return &_array->data[index * _array->stride];
}

GLFWAPI const GLFWarray* glfwGetVideoModes2(GLFWmonitor* handle)
{
    _GLFWmonitor* monitor = (_GLFWmonitor*) handle;
    assert(monitor != NULL);

    _GLFW_REQUIRE_INIT_OR_RETURN(NULL);

    if (!refreshVideoModes(monitor))
        return NULL;

    _GLFWarray desc = {
        monitor->modeCount,
        sizeof(_GLFWvideoMode),
        (char*) &monitor->modes
    };

    *(monitor->modesDescription) = desc;
    return (GLFWarray*) &monitor->modesDescription;
}

// Usage:

GLFWmonitor* monitor = ...;
const GLFWarray* array = glfwGetVideoModes2(monitor);

for (int i = 0; i < glfwArrayGetCount(array); ++i)
{
    const GLFWvideoMode* mode = glfwArrayGetElement(array, i);
    int w, h;
    glfwVideoModeGetPixelSize(mode, &w, &h);
    printf("[%i] Pixel size: [%i, %i]\n", i, w, h);
}

@ws909 Agreed, something like that is needed at this point.

@ws909 Agreed, something like that is needed at this point.

I began work on this. I'm planning to exclude glfwVideoModeGetPixelSize and glfwVideoModeGetScaling for now. Those can be added later.


Trim Subnet CIDR While Creating Virtual Link

What happened?
While creating a cloud instance, a virtual link job is being executed with manifest:
apiVersion: batch/v1
kind: Job
metadata:
  name: add-vl
  labels:
    app: add-vl
spec:
  template:
    spec:
      # robolaunch tenancy labels
      nodeSelector:
        robolaunch.io/cloud-instance: <CLOUD-INSTANCE>
        robolaunch.io/department: <DEPARTMENT>
        robolaunch.io/organization: <ORGANIZATION>
        robolaunch.io/super-cluster: <SUPER-CLUSTER>
      containers:
      - image: nicolaka/netshoot:latest
        command: [ "/bin/bash", "-c", "--" ]
        #args: [ "ip link add subnet-3 type dummy; ip addr add <IP_ADDRESS>/32 brd + dev subnet-3 label subnet-3:0; ip link set dev subnet-3 up;" ]
        args: [ "ip link add <subnet-id> type dummy; ip addr add <subnet-network-address>/32 brd + dev <subnet-id> label <subnet-id>:0; ip link set dev <subnet-id> up;" ]
        imagePullPolicy: IfNotPresent
        name: add-vl
        securityContext:
          capabilities:
            add: ["NET_ADMIN", "SYS_ADMIN"]
          runAsUser: 0
      restartPolicy: Never
      hostNetwork: true

Since the input <subnet-network-address> is gathered from cloud instance's subnet's spec.cidrBlock field, orchestrator sets the value wrong such as <IP_ADDRESS>/24/32. Job seems completed but it returns error log.
What did you expect to happen?
If the cloud instance cluster CIDR is X.Y.Z.T/24, I would expect orchestrator to set  <subnet-network-address> X.Y.Z.T/32. (/32 is static postfix) And the job should be completed successfully.
How can we reproduce it (as minimally and precisely as possible)?
After cloud instance creation, see logs of virtual link job:
kubectl logs -f pod/add-vl-<POD-POSTFIX>

Anything else we need to know?
No response

@Mert18


Upgrade to latest LTS 2.176.1

No security advisories though.

Just getting the ball rolling on this. Haven't really tested it yet.

#887 will close this one also.

/close


why not support double[]

why not support double[]?

Hi @libra1010, the vector type uses single-precision floats, so that's what the library uses (also, please provide more context for issues in the future).


rename Population.somata to Population.soma

to have name consistency among Population and Neuron.

Codecov Report

Merging #936 (e61bf2a) into master (76ce6b3) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #936   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           37        37
  Lines         2107      2107
=========================================
  Hits          2107      2107

As for #935 , could we have a first version with the two properties and a deprecation warning please?
Also, could we group all these breaking changes in the same version? So we will have only one big update to do when it will be released.

May I ask why these two fundamentally different entities need to have common signatures? Population.soma is a confusing combination, isn't it?

I saw that Population and Neuron has the same neurites property for features mechanism. So, I thought to make the similar approach for soma. Anyway, I can revert.
Can you clarify that somata aimed to empasize plural somas at Population? Should we rather call it somas then? Is somata an official name for plural somas?

neurites property is the same for both Population and Neuron because even a single neuron has a collection of neurites. However, a Neuron has only one soma, while the Population one soma per Neuron. This is why I find the combination of singular soma and plural Population misleading.
And yeah "soma" is a greek word and its plural is indeed "somata", not "somas". ^^

good then, I'm reverting

I apologize for not noticing this PR earlier.. :(

No worries. From now on I will put you as a reviewer. Thanks for clarifying.

And yeah "soma" is a greek word and its plural is indeed "somata", not "somas". ^^

Ah I did not know that! Thanks for the greek course :)

Ah I did not know that! Thanks for the greek course :)

That caught me as well. I always thought somata is more like official name for soma e.g. more biological, including all organelles and stuff.


Unable to deploy Ops Director on vSphere due to credhub failure

We deployed Ops Manager for vSphere v1.12.2 via pcf-vsphere-1.12.2.ova appliance.
But after that we were unable to deploy Ops Director on vSphere due to credhub failure.
The excerpt from the log :
  Running the post-start scripts 'bosh/0'... Failed (00:10:10)
Failed deploying (00:20:17)

Stopping registry... Finished (00:00:00)
Cleaning up rendered CPI jobs... Finished (00:00:00)
Deploying:
  Running the post-start script:
    Sending 'get_task' to the agent:
      Agent responded with error: Action Failed get_task: Task 063d458d-829c-479e-6967-a75b4fafdc81 result: 1 of 2 post-start scripts failed. Failed Jobs: credhub. Successful Jobs: uaa.
Exit code 1
===== 2017-10-20 08:38:51 UTC Finished "bosh2 --no-color --non-interactive --tty create-env /var/tempest/workspaces/default/deployments/bosh.yml"; Duration: 1230s; Exit Status: 1
Exited with 1.

The workaround mentioned on Knowledgebase page hadn't worked :
https://discuss.pivotal.io/hc/en-us/articles/115012474187-CredHub-fails-to-start-when-deploying-Pivotal-Cloud-Foundry-1-11-and-1-12-
Regenerate command for certificates had worked (200 OK), bu ut further deployment hadn't succeded.

@sumkincpp can you provide the associated credhub.log file?

@ebeer Sure! Sorry for delay, how can I get it from the VM? Where it stored and what are ssh credentials?

Ok, seems that error is with certificates regeneration(https://docs.pivotal.io/pivotalcf/1-12/security/pcf-infrastructure/api-cert-rotation.html#regenerate).
This command succeeds :
$ curl "https://OPS-MAN-FQDN/api/v0/certificate_authorities/active/regenerate" \
-X POST \
-H "Authorization: Bearer YOUR-UAA-ACCESS-TOKEN" \
-H "Content-Type: application/json" \
-d '{}'

But further verification via
curl "https://AAAAAAAAAAAA/api/v0/certificate_authorities/" -X GET -H "Authorization: Bearer XXXXXXXXX" -H "Content-Type: application/json" -k

shows that only one old CA is present.
During API call via /api/v0.certificate_authorities, the following lines appeared in /tmp/logs (Nothing unusual): certificate_authorities regenerate.txt
I believe that Api::V0::CertificateAuthoritiesController#regenerate_certs api call isn't regenerating CA.

@sumkincpp the OpsManager certificate regeneration process is not connected to CredHub at this time, to my knowledge. Pivotal support should be able to assist you with your OpsManager issue.

@ebeer Ok, how can I get credhub.log file from Ops Director vm?

@sumkincpp for a BOSH deployment, credentials would be in the manifest and CredHub logs in /var/vcap/sys/log/credhub/  OpsManager may have a different structure, so Pivotal Support should be more helpful for your situation.

@sumkincpp Did you redeploy after the rotation?


[Feature request] Please add WM_NAME as match criteria for Group settings

Greetings!
I have a use case that causes some inconvenience when using Group settings.  When I do xprop on both the VirtualBox machine manager and a VirtualBox VM, the WM_CLASS name and class is always VirtualBox but the WM_NAME is more specific as to the window's function.  This causes both the VBox manager and VM to match my rule, and ends up removing the title and borders on the VBox manager, which I don't want.
I realize I should probably file a bug on the VBox site, but this feature request may come in handy for other programs run under JWM.
Is it possible to add matching for WM_NAME in Group settings?
Thank you! :smile:

Added comment to existing (four year old) VirtualBox bug report.
https://www.virtualbox.org/ticket/12534#comment:3

See #265

@rdnvndr Thanks.  I did a search but that bug didn't come up.  I'll go ahead and close this since Joe doesn't want to do this.  Thanks! :smile:


Title discussion

I'm still not totally happy with the title so I'm opening an issue for us to kick around and settle on options. Here are a couple of options to get us started.

Forecasting biodiversity in breeding birds using best practices
Forecasting species richness in breeding birds using best practices

Could you clarify what you don't like about the current one?
I think you're right to drop changes in. What I like about something more like Best practices for forecasting biodiversity: an example using breeding birds is that it specifies that the best practices are for forecasting biodiversity, rather than for ecology in general or for forecasting birds in particular.

I guess for me it sets the paper up more as focusing as on the best practices per se and less on the analysis and my read of the way we've ended up writing it is that the balance is the other way around. In other words, for the current title I'd expect a paper that primarily focused on walking through each of the best practices in detail and then provided examples/case studies using them. This is magnified by the colon.

Okay, I agree with that. I'll keep thinking about it.

How about this?

Forecasting biodiversity in breeding birds: best practices and limitations

My brain naturally reads the stuff after the colon as kind of a subtitle here and so I'd naturally associate this with more of an ideas piece, but I'm OK with it as a compromise.

Okay, fair point.  I'll use

Forecasting biodiversity in breeding birds using best practices

Sorry for going back-and-forth on this so many times...

No problem at all. In the modern era I think titles are really important and so I think trying out a bunch of different options and going back-and-forth to get the best one is a good use of time.