EVA: Duplicate association fields — source trait names

This ticket is part of the effort to get rid of duplicates in unique_association_fields in the evidence strings submitted by EVA.
Sometimes, different ClinVar trait names are mapped to the same ontology term. For example, record RCV000763237.1 associates one variant, rs151045328, with three conditions:

Usher syndrome, type 1C
Deafness, autosomal recessive 18
Usher syndrome, type 1

We currently have the 1st and the 3rd one mapped to the same ontology term, Orphanet_886. Hence, we have two almost identical evidence strings where only the source name of the trait is different.
To bring some context about the scale, currently we have 249 clusters of evidence strings with the same association fields because of this issue.
The solution which I suggest to implement for this is to add phenotype_source_name to the list of unique_association_fields. This means we would still have the same number of evidence strings, but they will have different association fields. This can be tracked & discussed in this ticket.

Your suggested solution would fix "the issue" but I am not sure that I would add much value. As you say, in this case two ClinVar conditions ("Usher syndrome, type 1C" and "Usher syndrome, type 1") are mapped to the same ontology term ("Usher syndrome") which produces duplicates. However, the duplication does not mean that the association is lost, only that one of the two evidence strings is used. You can see this in the association page for USH1C and Usher syndrome (the evidence for RCV000763237 is in the last row in the screenshot below):

If we deduplicate the evidence strings for the two conditions we would get two rows for RCV000763237 and I don't think that is that useful. Ideally, we would want those two phenotypes mapped to two independent ontology terms if they are  to be considered two separate subtypes of the disease.

If the disease are genuinely different then we should ask for additional ontology terms. It needs someone to understand the relationships of Type 1 and Type 1C, and edit the ontology. Also Deafness, autosomal recessive 18 may not be a disease but an OMIM term for an association which is equivalent to Usher Syndrome Type 1 or Type 1C. Unfortunately there are historical OMIM terms like this

@AsierGonzalez @iandunham Right, so I think we have two separate issues here:
When two trait names currently point to the same ontology term, but should actually point to two different ones, then I agree this is a curation issue and should be fixed at this level. Currently we have no way of doing this because of the archaic curation approach, but the new web-based system should allow us to keep track of all traits in fine detail. So we can gradually go through all such cases and fix them.
However, what do we do in cases where two names actually should point to the same ontology and do represent the same condition? I don't like the idea of our evidence strings having non-unique unique_association_fields. Should we, then, issue only one evidence string for a set of traits pointing to the same ontology? If yes, then how do we decide what to put into disease.source_name column, which currently contains original trait name from ClinVar?

If two ClinVar phenotypes point to the same ontology term in the same ClinVar accession then it is right to consider them duplicates. With the current approach (no phenotype source name in the unique association fields) our pipeline would discard one and there would not be any issues. As I said, I don't see the value of adding the source name to the unique association fields just to distinguish two different ways of calling the same phenotype. Do you see it differently?

In light of the clarifications you provided, I agree that while simply adding source name to the unique association fields will technically solve the problem, it will not add any value. So let's not do that.
I still want to avoid having duplicates in the unique association fields in the evidence strings which we submit to you. Partly because it's just not right to have duplicates in a field which is supposed to be unique, and partly because this actually complicates computing differences and bulk statistics.
From what you say, it seems that the current approach for dealing with this on your side is to choose one (arbitrary?) evidence string from a cluster of strings having the same unique_association_fields. In this case, what we could do is implement a similar thing on our side as well, so that the strings which you receive are already duplicate-free. This also has an added benefit that the deduplication on our side can be controlled and fine-tuned.
If you can confirm you're happy with this solution, then we can close this issue, and I'll add an internal issue to our backlog.

Also, I have created a relevant issue in the repository for the new trait curation web app we are developing: https://github.com/EBIvariation/trait-curation/issues/12. It will provide an opportunity to view all ontology terms which have mappings from multiple trait names.

Also also, I just want to share a quote from Gautier Koscielny, who in 2018 commented:
One possible explanation is because the disease mapping process in EVA has mapped different ClinVar diseases to the same EFO/ORDO term.
If you put the source name of the disease in the unique association field, they should be unique.
That’s why I always asked the data providers to provide the original label of the disease in the submission as a way to understand how the mapping was performed.

Summary of discussion in EVA-OT meeting held on 9-06-20
In the future, when multiple ClinVar conditions map to the same EFO id all the ClinVar disease names will be listed in an array in ".disease.source_name":

@tskir to make the changes to the EVA pipeline
@AsierGonzalez to make the necessary changes to the JSON schema
No changes will be made to the unique_association fields
Manual curation will still be required to decide when different ClinVar conditions are synonyms and when new terms have to be added to the ontology. The new manual curation framework will be useful for that.

This commit to branch ag_eva_changes adds support for arrays of strings. The two alternatives below are not valid:
"disease": {
    "id": "http://www.orpha.net/ORDO/Orphanet_886",
    "source_name": "usher syndrome, type 1c",
    "name": "Usher syndrome"
  },

And
"disease": {
    "id": "http://www.orpha.net/ORDO/Orphanet_886",
    "source_name": ["usher syndrome, type 1c", "Usher syndrome, type 1"],
    "name": "Usher syndrome"
  },

Re-assigning to the next sprint so that PR can be opened and approved

I leave the ticket open until the next time we receive an EVA evidence file

This has not been implemented and it isn't prioritised for 20.11 - moving it to 21.02

@tskir we have revisited this issue and the solution discussed above does not apply anymore. We are working on a new ETL pipeline and as a consequence we are making important changes to the JSON schema (more info in #1249). We have reviewed the solution we discussed here, i.e. using an array in disease.source_name but that causes issues downstream. Therefore we have decided to use a different approach that will also apply to other data sources.
When multiple phenotypes/ conditions map to the same EFO, they will be captured in a single evidence string but the source_name will only contain one of them, randomly chosen. There will be another field where the full list of original disease names will be included in an array, not only the ones that map to the given EFO id.
I hope this does not cause any issues to you. We will get in touch with you soon to explain the changes.

@AsierGonzalez Thank you for the update! I have not yet done any substantial work on this issue, so no time is wasted.
The only part which bugs me a bit is choosing one source_name on random—sounds like it might somewhat undermine the stability/reproducibility of the results. But of course we'll be able to implement this in whichever way your pipeline require

You are right in that using a random source_name may make it difficult to compare the output of different runs. However, any differences should not cause internal issues as the only use we have in mind for it is to display it in the webapp and we assume that all the conditions that map to the same EFO id will be very similar. The only case I can think of that could cause difficulties is if a subtype of a disease (e.g. Usher syndrome, type 1C that started this discussion) is mapped to a more general term in one release (causing a duplicate in the current implementation) and in the next release it gets mapped to another disease because it has been added to the ontology. Can you think of any other problematic cases?
One solution to ameliorate the issue could be not to choose randomly the source_name to be reported but to pick the first one alphabetically or the shortest or longest. At least this will avoid changes due to different ordering in the input file when nothing else changes.

Yes, choosing the first name in lexicographical order does sound better to me than just being random.
I can't think of other problematic cases right now, although I'm still not sure I understand the value behind choosing a designated source name to display. Do you suppose you could share a screenshot of how this data would look on the web page?

Good, let's use the first one in lexicographical order then.
To be honest, it's still not decided whether this value will be displayed in the front-end but we want all the data sources to be as consistent as possible in the new schema, which is why having an array of strings was an issue.
We will keep our minds open when we start using the new schema and pipeline in case we identify any issues.

This has not been implemented yet and it is not scheduled to be done for 21.02 - moving it to 21.04.

This has not been implemented yet and it is not scheduled to be done for 21.02 - moving it to 21.04.

The above-mentioned solution has been changed in the light of the migration of ClinVar to the v2 of the JSON Schema (more details here). The current approach to report the conditions in ClinVar from 21.04 on is the following:

cohortPhenotypes: the list of all disease terms of a RCV accession.
diseaseFromSource: the first of those disease terms that are mapped to the EFO term.
diseaseFromSourceId: the ClinVar disease id of the term under diseaseFromSource. If available.
diseaseFromSourceMappedId: the EFO id which is mapped from the term diseaseFromSource

An interim solution has been implemented so far where cohortPhenotypes lists the preferred name of all the different traits annotated for a given RCV since providing a complete list is not straightforward as @tskir has commented:

The cohortPhenotypes field will not yet contain all disease names from ClinVar. This is because trait representation in ClinVar is complex and will require additional investigations, which might not be complete in time for the release. In short, each RCV record contains a TraitSet, which in general has multiple Trait records, each of which in general has multiple Name entries (synonyms). We're currently only using one Name (marked as “preferred”) per Trait. So if there are three Traits in a TraitSet, the cohortPhenotypes will list only the three preferred names, one for each, regardless of how many synonym names each of the Traits had.


Crash in CoreFoundation - CFDictionaryGetValue

We have a crash in the app. We using the AFNetworking 3.0.
There are logs:

Crashed: com.apple.NSURLSession-work
0  CoreFoundation                 0x228f7cdc CFDictionaryGetValue + 27
1  Foundation                     0x231eeb5b _NSSetLongLongValueAndNotify + 54
2  Foundation                     0x231eeb5b _NSSetLongLongValueAndNotify + 54
3  CFNetwork                      0x22f05251 -[__NSCFLocalDataTask _onqueue_didReceiveResponse:completion:] + 68
4  CFNetwork                      0x22f48789 __61-[__NSCFURLLocalSessionConnection _didReceiveResponse:sniff:]_block_invoke + 96
5  CFNetwork                      0x22f473c3 -[__NSCFURLLocalSessionConnection withDelegateAndPendingCompletion:] + 190
6  CFNetwork                      0x22f4871b -[__NSCFURLLocalSessionConnection _didReceiveResponse:sniff:] + 374
7  CFNetwork                      0x22f4aa67 SessionConnectionLoadable::_loaderClientEvent_DidReceiveResponse(_CFURLResponse*) + 170
8  CFNetwork                      0x22fb1271 ___ZN19URLConnectionLoader26protocolDidReceiveResponseEP14_CFURLResponse_block_invoke + 24
9  libdispatch.dylib              0x2255d823 _dispatch_call_block_and_release + 10
10 libdispatch.dylib              0x2256a423 _dispatch_queue_drain$VARIANT$mp + 1758
11 libdispatch.dylib              0x22569a61 _dispatch_queue_invoke$VARIANT$mp + 284
12 libdispatch.dylib              0x2256c15d _dispatch_root_queue_drain + 396
13 libdispatch.dylib              0x2256bfcd _dispatch_worker_thread3 + 96
14 libsystem_pthread.dylib        0x22721b29 _pthread_wqthread + 1024
15 libsystem_pthread.dylib        0x22721718 start_wqthread + 8

This issue occurs on the iPad 2 (iOS 9.3.5), iPad 3 (iOS 9.3.5), iPhone 6 Plus (iOS 9.3.0).
Can you please help resolve this issue?
Thanks!

Sorry, but there’s not enough in that log to go off of—I don’t even see any AFNetworking code in the backtrace.

same issue


Check if window exists in Region

This is again needed for server side rendering, in non-testing environments.

Coverage remained the same at 100.0% when pulling 9847be7ca1a38ab65c3672fbc94aad97abeb335c on region-window-check into f90041e232b188bdd4f397ac9a78293b1544d578 on master.


Netman might have a memory leak?

I have noticed that when Neovim is open for a long time (more than a few hours), my memory usage begins to creep up. I haven't recently made any changes to anything outside Netman so this might be caused by it. I am unsure how this could happen as netman doesn't save much in memory. But its best to verify that we are clearing all caches correctly and aren't accidentally leaving things in memory forever that don't need to be there.
The new cache module should be helping with this

To verify this, I am going to test this both overnight tonight (opening the same files) without netman enabled, and overnight tomorrow night with netman enabled. If we have a memory leak somewhere within netman, it will show different memory usage results between the 2 tests.
It is a very slow thing, so its quite difficult to pinpoint.

Confirmed the memory leak is not from Netman but instead from an LSP that was hungry. Closing out


Allow passing explicit DeviceClass

For cases where we want to associate OSD and pools with devices on
specific nodes with specific devices, we need a more fine-grained level
of device-type, which is passed on to rook as CRUSH-device-class.
As an example, consider cluster with ssd devices from two different
vendors, where user would want to have different pools, one for each
sub-device type. When combined with node-labeling and this patch, the
task becomes trivial.
Signed-off-by: Shachar Sharon<EMAIL_ADDRESS>

/retest
On Tue, Apr 20, 2021 at 10:45 AM openshift-ci[bot] @.***>
wrote:

@synarete https://github.com/synarete: The following tests failed,
say /retest to rerun all failed tests:
Test name Commit Details Rerun command
ci/prow/ocs-operator-ci e1d55bd
https://github.com/openshift/ocs-operator/commit/e1d55bda0819f95dfbec005dd2e193e2da1143a5
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_ocs-operator/1161/pull-ci-openshift-ocs-operator-master-ocs-operator-ci/1384410319517913088 /test
ocs-operator-ci
ci/prow/ci-index-fixed-dependencies e1d55bd
https://github.com/openshift/ocs-operator/commit/e1d55bda0819f95dfbec005dd2e193e2da1143a5
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_ocs-operator/1161/pull-ci-openshift-ocs-operator-master-ci-index-fixed-dependencies/1384410319408861184 /test
ci-index-fixed-dependencies
ci/prow/ci-index-dev-master-dependencies e1d55bd
https://github.com/openshift/ocs-operator/commit/e1d55bda0819f95dfbec005dd2e193e2da1143a5
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_ocs-operator/1161/pull-ci-openshift-ocs-operator-master-ci-index-dev-master-dependencies/1384410319379501056 /test
ci-index-dev-master-dependencies
ci/prow/ocs-operator-bundle-e2e-aws e1d55bd
https://github.com/openshift/ocs-operator/commit/e1d55bda0819f95dfbec005dd2e193e2da1143a5
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_ocs-operator/1161/pull-ci-openshift-ocs-operator-master-ocs-operator-bundle-e2e-aws/1384410319488552960 /test
ocs-operator-bundle-e2e-aws
ci/prow/images e1d55bd
https://github.com/openshift/ocs-operator/commit/e1d55bda0819f95dfbec005dd2e193e2da1143a5
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_ocs-operator/1161/pull-ci-openshift-ocs-operator-master-images/1384410319442415616 /test
images
Full PR test history
https://prow.ci.openshift.org/pr-history?org=openshift&repo=ocs-operator&pr=1161.
Your PR dashboard
https://prow.ci.openshift.org/pr?query=is:pr+state:open+author:synarete.
Instructions for interacting with me using PR comments are available here
https://git.k8s.io/community/contributors/guide/pull-requests.md. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow issue:
repository. I understand the commands that are listed here
https://go.k8s.io/bot-commands.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/ocs-operator/pull/1161#issuecomment-823054556,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5ZRR47CTHUF6DFS5OUPDLTJUV7NANCNFSM43HSOFSA
.

/test ocs-operator-ci


APIs For Introspecting Reason/OCaml LSP Environments

This diff implement Two New Language Server Features For Exploring IDE Environment.
One common issue with the vscode Reason plugin is that people are running it in an environment that consists of some hybrid of Opam, npm etc without fully understanding their dev time dependencies or what LSP "sees". This makes it difficult to help the Discord community.
I've added a server API to explore the user's environment, with an autocomplete window to search for various keywords such as "merlin_version", or PATH.  When hitting enter on an entry, it will open the variable in a new editing buffer. The user may also choose Show Entire Environment which will open up the environment that the language server sees in a new windows, so that users may copy/paste it into the Discord channel so that we can help debug their setup.
Another issue is that when building native libraries, such as the Reason parser itself, the build is misconfigured or tries to depend on libraries that aren't actually provided by the package dependencies.  Each ocaml package contains multiple possible library names - it's not a 1-1 mapping, so it can be confusing to people new to the ecosystem.  Here, I'm also adding a feature to display a popup list of ocaml library dependencies provided by the project dependencies. Because of my previous PR all of these introspections are now project specific. It will fall back to global introspection if you don't have well-isolated projects.

There's also a Corresponding VSCode UI diff showing how these can be exposed in clients. I'll duplicate the screenshots here:

Thanks! This looks really nice. I'll give it a try first a little later today but otherwise it looks good to merge.


Quick prototype of huh forms for prompt input

Closes #NNN
Check the following

[ ] Maintain high code coverage
[ ] Be properly formatted
[ ] Documentation changes are included
[ ] Include a change file if expected

Additional context
Any additional info that might help get your pull request merged.

If you add a Height to the NewSelect and NewMultiSelect that should take care of everything.  Looking forward to this change!
huh.NewMultiSelect[string]().
	Title("Projects").
	Options(projectOptions...).
	Value(&p.Projects).
	Height(10),

I am waiting on huh to support hide funcs so I can conditionally hide the optional prompts in one form.

This is still on hold until huh is updated, no eta or anything.


Update all examples to use spir-v bytes by default

As per #85 all examples should be updated to use spir-v bytes for shaders instead of the raw glsl/hlsl string by default as more devices support this by default.

Done in 0.5.0


the ref name was too confusing, change to another

The change seems poor readability, not corresponding to the style of the document.


Is it possible using other "Video Source" as input in VCSimpleSession ????

@kciter Hi,
I have asked so many times on the internet, for the same question. Although your example works perfectly. But I can't figure it out how to change the input source or what function I can use.
so far I found that CameraSource::setupCamera should be the way for the input source. Do you any idea ?
Thank you & sorry if the problem is too simple.

jgh-/VideoCore#48
This issue may help you.


[Enhancement]: Update jackson databind version (support more than 50 containers in compose file)

Module
Core
Proposal
Currently the project is using Jackson databind yaml 2.8.x, and the comments on that part of the code say that this is for backwards compatibility.
Unfortunately that version uses an older version of snake yaml (1.17). This version has a known arbitrary code execution vulnerability, and it also fails to parse yaml that has >50 attributes, so it does not support more than 50 containers in a docker compose file.
jackson databind 2.8.x also has its own known vulnerabilitie: 1, 2.
I do not know what the compatibility issues the comment is referring to, but I think it's best to move to a newer version of jackson databind, even if it requires a new minor/major version.

testcontainers-core build.gradle:
configurations.all {
    resolutionStrategy {
        // use lower Jackson version
        force 'com.fasterxml.jackson.core:jackson-databind:2.8.8'
        force 'com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.8.8'
    }
}

Jackson-databind 2.8.8 should be updated. It has 54 CVEs. Even though testcontainers should run in the test scope
Direct vulnerabilities:

CVE-2022-42004
CVE-2022-42003
CVE-2021-20190
CVE-2020-9548
CVE-2020-9547
CVE-2020-8840
CVE-2020-36518
CVE-2020-36189
CVE-2020-36188
CVE-2020-36187
CVE-2020-36186
CVE-2020-36185
CVE-2020-36184
CVE-2020-36183
CVE-2020-36182
CVE-2020-36181
CVE-2020-36180
CVE-2020-36179
CVE-2020-35728
CVE-2020-35491
CVE-2020-35490
CVE-2020-25649
CVE-2020-24750
CVE-2020-24616
CVE-2020-10673
CVE-2020-10650
CVE-2019-20330
CVE-2019-17531
CVE-2019-17267
CVE-2019-16943
CVE-2019-16942
CVE-2019-16335
CVE-2019-14892
CVE-2019-14540
CVE-2019-14439
CVE-2019-14379
CVE-2019-12814
CVE-2019-12384
CVE-2019-12086
CVE-2018-7489
CVE-2018-5968
CVE-2018-19362
CVE-2018-19361
CVE-2018-19360
CVE-2018-14721
CVE-2018-14720
CVE-2018-14719
CVE-2018-14718
CVE-2018-12023
CVE-2018-12022
CVE-2018-11307
CVE-2017-7525
CVE-2017-17485
CVE-2017-15095

Vulnerabilities from dependencies:

CVE-2020-15250

This has been addressed by #8816


[varLib.iup] Rewrite force-set conditions & limit DP lookback length

This does two things:
Fixes forced-set computation, which was wrong in multiple ways.
Debugged it. Is solid now... Famous last words.
Speeds up DP time by limiting DP lookback length. For Noto Sans,
IUP time drops from 23s down to 9s, with only a slight size increase
in the final font. This basically turns the algorithm from O(n^3) into
O(n).

For Noto Sans, IUP time drops from 23s down to 9s

that's great!

Fixes forced-set computation, which was wrong in multiple ways

do you have a test case that shows how was it "wrong" and how this fixes it?
I'm actually not sure what's the current IUP test suite's coverage, so the mere fact that tests "pass" may not mean much.
The code is quite dense and I might not be able to do a full review pass right now.
But if you say it is "solid" now, I take you on your words.
Maybe @simoncozens who has worked on the Rust port recently can take a closer look.

I added some comments at least.

I'll add some tests.

I'm seeing something really weird. On my Linux machine the speedup is much less than on my Mac :(. No idea why.

I'm seeing something really weird. On my Linux machine the speedup is much less than on my Mac :(. No idea why.

For NotoSans, calling varLib module without layout interpolation, and with this branch, takes 13s on my Mac laptop, and 30s on my AMD desktop. That's quite unexpected.

I'm seeing something really weird. On my Linux machine the speedup is much less than on my Mac :(. No idea why.

For NotoSans, calling varLib module without layout interpolation, and with this branch, takes 13s on my Mac laptop, and 30s on my AMD desktop. That's quite unexpected.

My bad. I had debugging code committed accidentally.

Still the Mac laptop is ~20% faster. That's amazing.

Added a few tests. Granted, it's not much, but a start.

Added a few tests.

better than nothing, thanks! Out of curiosity, do these pass or fail without your patch?

FWIW, there are Rust IUP unit tests at https://github.com/simoncozens/rust-font-tools/blob/07e0c6ec007004090da1b0dd783f6e61b3dd74e2/fonttools-rs/src/otvar/iup.rs#L461-L514

@simoncozens Please port these changes to your Rust implementation.

@anthrotype How does this look now?

@anthrotype Thanks. Fixed.

@anthrotype Is this good now?

Ah sorry I missed the LGTM before.


[Warhammer 4e Character Sheet] Update & fixes v1.31

Changes / Comments

Reroll clicky buttons now integrated into the rol template out put for most rolls, including all repeating sections. This is diplayed in the Test value row.
NPC Tab rework, a number of modifications have been made to increase it performance when alot of NPC hare created. All NPC rolls are now integrated into the crit and reroll buttons. Weapons have been split into Melee(upto 3)/Ranged(upto 2) and Spell into Magic(upto 3)/Prayer(upto 2). Notes now no longer has a hider checkbox and is allow shows and the Roll outcome modifer are removed entirely, both were to greater performance hogs within the repeating section. Use the quality text field instead.
Channelling Roll template has been altered to be more inline with other rolls to allow the reroll intergation.
Weapons & Spells Tab rework, cleaned it up and added a Mod and Target display fields which matches the roll target.
All Mod fields will now prepopulate the Roll Modifider popup with the set value.
Fixed the Talents tab text field dragging issue from the last update.

Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[x] Does the pull request title have the sheet name(s)? Include each sheet name.
[x] Is this a bug fix?
[x] Does this add functional enhancements (new features or extending existing features) ?
[x] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.

Character Sheet Info Roll20 Internal Use only.


rootless: tagging of built image doesn't seem to work

/kind bug
Description
I run podman build . -t sync2jira I expect the resulting image to get the tag. It doesn't. For example I saw:
STEP 25: FROM a2ca749662b4fbe156cef473e586072f3c56cfd94d42c74ae968b3b5441911f0
STEP 26: CMD ["/usr/local/bin/sync2jira"]
--> cf2c605849dc1442f2783e9337d4bcb9578ed1319fa05c52242e089ed2226095
STEP 27: COMMIT
[dustymabe@media sync2jira (dusty *%)]$ podman images
REPOSITORY                                 TAG      IMAGE ID       CREATED             SIZE
<none>                                     <none>   cf2c605849dc   52 seconds ago      924 MB
<none>                                     <none>   8c3a9bb5bf74   About an hour ago   439 MB
localhost/sync2jira                        latest   0ed4a4f539e2   About an hour ago   439 MB

Steps to reproduce the issue:

podman build . -t sync2jira

podman images

Output of podman version:
[dustymabe@media sync2jira (dusty *%)]$ rpm -q podman
podman-1.1.2-1.git0ad9b6b.fc29.x86_64
[dustymabe@media sync2jira (dusty *%)]$ podman version
Version:            1.1.2
RemoteAPI Version:  1
Go Version:         go1.11.5
Git Commit:         a95a49d3038462d033f84ac314ec8a3064a99cff
Built:              Tue Mar  5 13:10:31 2019
OS/Arch:            linux/amd64

Output of podman info --debug:
[dustymabe@media sync2jira (dusty *%)]$ podman info --debug
debug:
  compiler: gc
  git commit: a95a49d3038462d033f84ac314ec8a3064a99cff
  go version: go1.11.5
  podman version: 1.1.2
host:
  BuildahVersion: 1.7.1
  Conmon:
    package: podman-1.1.2-1.git0ad9b6b.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: a95a49d3038462d033f84ac314ec8a3064a99cff'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree:<PHONE_NUMBER>
  MemTotal:<PHONE_NUMBER>0
  OCIRuntime:
    package: runc-1.0.0-68.dev.git6635b4f.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: ef9132178ccc3d2775d4fb51f1e431f30cac1398-dirty
      spec: 1.0.1-dev
  SwapFree:<PHONE_NUMBER>
  SwapTotal:<PHONE_NUMBER>
  arch: amd64
  cpus: 8
  hostname: media
  kernel: 4.20.14-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 8h 19m 18.88s (Approximately 0.33 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/dustymabe/.config/containers/storage.conf
  ContainerStore:
    number: 18
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /var/b/dustymabe-config-containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 32
  RunRoot: /run/user/1001
  VolumePath: /home/dustymabe/.local/share/containers/storage/volumes

Am I missing something?
localhost/sync2jira                        latest   0ed4a4f539e2   About an hour ago   439 MB
Looks like the tag?

Right. I had previously run podman build . and podman image tag  0ed4a4f539e2 an hour before. This was a subsequent run of podman build . -t sync2jira that occured 52 seconds ago and created cf2c605849dc. It's subtle, but you can see it in the output I pasted.

@dustymabe If you remove the tagged image, is it tagged again?
I wonder if we're refusing to tag because the image in question already exists

@dustymabe If you remove the tagged image, is it tagged again?

Nope.
REPOSITORY                                 TAG      IMAGE ID       CREATED        SIZE
<none>                                     <none>   8c3a9bb5bf74   18 hours ago   439 MB
docker.io/library/fedora                   latest   d09302f77cfc   2 days ago     283 MB
registry.fedoraproject.org/fedora          29       69c5db8b64a7   2 months ago   283 MB
registry.centos.org/centos                 7        719ea9c10b97   2 months ago   210 MB
quay.io/factory2/sync2jira-jenkins-slave   latest   55ea5c07ce83   6 months ago   1.33 GB
[dustymabe@media sync2jira (dusty *%)]$
[dustymabe@media sync2jira (dusty *%)]$ podman build . -t sync2jira
STEP 1: FROM fedora:latest
.
.
.

STEP 26: CMD ["/usr/local/bin/sync2jira"]
--> d5a8f69516dbcf08836e99a0112656ec2ca811965e4db167fa47c76e88c09af2
STEP 27: COMMIT
[dustymabe@media sync2jira (dusty *%)]$ podman images
REPOSITORY                                 TAG      IMAGE ID       CREATED          SIZE
<none>                                     <none>   d5a8f69516db   17 seconds ago   924 MB
<none>                                     <none>   8c3a9bb5bf74   18 hours ago     439 MB
docker.io/library/fedora                   latest   d09302f77cfc   2 days ago       283 MB
registry.fedoraproject.org/fedora          29       69c5db8b64a7   2 months ago     283 MB
registry.centos.org/centos                 7        719ea9c10b97   2 months ago     210 MB
quay.io/factory2/sync2jira-jenkins-slave   latest   55ea5c07ce83   6 months ago     1.33 GB

I wonder if we're refusing to tag because the image in question already exists

If that were the case it would still be a bug, right?

I added the rootless label too early, I can reproduce with root as well

@dustymabe Would definitely still have been a bug, though a different kind

Is Build missing SetInterspersed?

yes, I am preparing a PR right now

PR here: https://github.com/containers/libpod/pull/2646


Fix helm push permissions

This works locally for me, so maybe....
The setup.sh copies over the ~/.docker/config.json and that is in the build spec for this project.

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

Needs approval from an approver in each of these files:

OWNERS [TerryHowe]

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

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

Needs approval from an approver in each of these files:

OWNERS [TerryHowe,jaxesn]

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


[SPARK-36142][PYTHON] Follow Pandas when pow between fractional series with Na and bool literal

What changes were proposed in this pull request?
Set the result to 1 when the exp with 0(or False).
Why are the changes needed?
Currently, exponentiation between fractional series and bools is not consistent with pandas' behavior.
 >>> pser = pd.Series([1, 2, np.nan], dtype=float)
 >>> psser = ps.from_pandas(pser)
 >>> pser ** False
 0 1.0
 1 1.0
 2 1.0
 dtype: float64
 >>> psser ** False
 0 1.0
 1 1.0
 2 NaN
 dtype: float64

We ought to adjust that.
See more in SPARK-36142
Does this PR introduce any user-facing change?
Yes, it introduces a user-facing change, resulting in a different result for pow between fractional Series with missing values and bool literal, the results follow pandas behavior.
How was this patch tested?

Add test_pow_with_float_nan ut
Exsiting test in test_pow

cc @xinrong-databricks @ueshin @HyukjinKwon @itholic

Test build #141639 has started for PR 33521 at commit 6badfdf.

Test build #141639 has finished for PR 33521 at commit 6badfdf.

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

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

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46155/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46155/

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

Shall we rename the PR since the issue of Series with Decimal(NaN) is not adjusted here?

The PR looks good. Since it doesn't adjust the issue of Decimal(NaN) and ExtentionDtypes, which is inconsistent with the ticket title and description. Would you update the ticket? Thanks!

I think the PR does introduce user-facing change, resulting in a different result for pow between fractional Series with missing values and bool literal. Would you adjust the PR description?

it doesn't adjust the pow issue of Decimal(NaN) and ExtentionDtype
Would you adjust the PR description?
@xinrong-databricks , yes, the Decimal one should be added after SPARK-36000. thanks for the reminder of PR decription, updated!

Merged to master and branch-3.2.


feat(validate): add validate command

For now just do a simple pass through. This would be the command to add more sanity checks/validation steps as well.

Let's not do it: it's not faster and it doesn't add anything that other commands wouldn't do. And we have a terraform proxy command.


esm.sh responds with duplicate "Access-Control-Allow-Origin: *" headers following redirects

Description
When attempting to integrate esm.sh on https://plnkr.co/edit/, I noticed that .css files being loaded by the plnkr/runtime runtime were failing with CORS errors such as this:
Access to script at 'https://cdn.esm.sh/<EMAIL_ADDRESS>(redirected from 'https://esm.sh/<EMAIL_ADDRESS>from origin 'https://run.plnkr.co' has been blocked by CORS policy:
    The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed.

What seems to be happening is:

A first request to https://esm.sh/<EMAIL_ADDRESS>is coming back with a 307 pointing to https://cdn.esm.sh/<EMAIL_ADDRESS>The fetch seems to follow this redirect and sends a request with origin: null (not sure if this is per spec or what) for the canonical url.
esm.sh responds with two access-control-allow-origin: * headers causing Chrome to complain with the noted error.

I took a quick look at the CORS middleware but nothing popped out as obvious. Is it possible that something in CloudFlare might be duplicating this header?
Reproduction
Observe that the following produces duplicate access-control-allow-origin: * headers.
curl --head -X HEAD -H "origin: null" "https://cdn.esm.sh/<EMAIL_ADDRESS>

thanks for the details, i will look into it!

same problem here when fatching package.json content https://esm.sh/<EMAIL_ADDRESS>

i believe this has been fixed


Deploy shoot VPA earlier in the flow

Co-Authored-By: Rafael Franzke<EMAIL_ADDRESS>How to categorize this PR?

/area usability
/kind bug
What this PR does / why we need it:
The VPA component should be deployed rather early in the shoot flow, as other system components rely on the VPA CRD to be present for reconciliation.
Previously, the VPA component was reconciled as one of the last components in the shoot flow, in order to support a migration use case (from seed VPA to the new shoot VPA), ref https://github.com/gardener/gardener/issues/2683.
However, this use case should not exist anymore with ManagedSeed, ref https://github.com/gardener/gardener/issues/6305.
Which issue(s) this PR fixes:
Addresses https://github.com/gardener/gardener/pull/6293#issuecomment-1181521248
Special notes for your reviewer:
Release note:

NONE

/uncc


Add files via upload

Readme SS change

Codecov Report

Merging #257 (fc19243) into master (086dfd4) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #257   +/-   ##
=========================================
  Coverage     66.48%   66.48%
  Complexity      823      823
=========================================
  Files           119      119
  Lines          2760     2760
  Branches        341      341
=========================================
  Hits           1835     1835
  Misses          805      805
  Partials        120      120

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 086dfd4...fc19243. Read the comment docs.


Change date format of tooltip title

How can I change the date format of the tooltip's title?

In this example I would like to display "October 2016" instead of just "01 Oct"
Thanks for the great charts

tooltip: {
  x: {
    format: 'MMMM yyy'
  }
}


Cannot create a Flutter macOS app extension: 'FlutterEngineInitialize' returned 'kInvalidArguments'. The assets path in the Flutter project arguments was missing.

After https://github.com/flutter/engine/pull/41011/ started publishing artifacts I tried to make a macOS Share extension, but on launch the engine will not start:
Failed to find path for "flutter_assets"
embedder.cc (1601): 'FlutterEngineInitialize' returned 'kInvalidArguments'. The assets path in the Flutter project arguments was missing.

The App.framework bundle isn't found from the appex bundle.  Suspect macOS needs similar logic to this:
if ([mainBundle.bundleURL.pathExtension isEqualToString:@"appex"]) {

https://github.com/flutter/engine/pull/40332/files#diff-aff27bb72cc390eb03f0b733e1fa490102e311ffac10e8e09e8245e582484220R84
Here:
https://github.com/flutter/engine/blob/b50954c3f7d6dca6702ad843aa0fa7a51c774323/shell/platform/darwin/macos/framework/Source/FlutterDartProject.mm#L32
See also https://github.com/flutter/engine/pull/37421/files#diff-8646d867d6b502217ca15af1cfd042f7148929efb68e1f28d796351a80594832R38 which is changing this same spot.
Steps to reproduce

Create Flutter project

$ flutter create test_create
$ cd test_create
$ flutter build macos --config-only
$ open macos/Runner.xcworkspace/

Add a new Share target and Activate it.

In test_create/macos/FlutterShare/Info.plist change NSExtensionPrincipalClass to FlutterViewController.

In Xcode set a signing Team and set the Signing Certificate to Development for both the Runner and new FlutterShare targets. These app extensions fail with codesign errors if they are ad-hoc signed.

In the FlutterShare target build settings add -framework FlutterMacOS to Other Linker Flags

Run the FlutterShare target in Safari

In the top right corner of Safari under the Share menu choose FlutterShare

Results
In Xcode console:
2023-04-12 18:17:45.807583-0700 FlutterShare[28145:12591166] Failed to find path for "flutter_assets"
2023-04-12 18:17:45.808568-0700 FlutterShare[28145:12591166] Failed to find path for "flutter_assets"
embedder.cc (1601): 'FlutterEngineInitialize' returned 'kInvalidArguments'. The assets path in the Flutter project arguments was missing.
2023-04-12 18:17:45.808903-0700 FlutterShare[28145:12591166] Failed to initialize Flutter engine: error 2

and no UI launches.
cc @cyanglaz part of https://github.com/flutter/flutter/issues/124290

Also cc @cbracken

This is fixed by https://github.com/flutter/engine/pull/45351, closing

macOS does not seem to allow access to the app bundle while in app extension. The app bundle would return nil even if trying to load at the correct location.
  if ([mainBundle.bundleURL.pathExtension isEqualToString:@"appex"]) {
    // iOS and macOS app bundle has different structures (iOS version 17.0 and macOS 13.0)
    // On iOS, the structure is <AppName>.app/PlugIns/Extension.appex.
    // on macOS, the structure is <AppName>.app/Cotent/PlugIns/Extension.appex.
    // Up two levels on iOS.
    NSURL *bundleURL = mainBundle.bundleURL.URLByDeletingLastPathComponent
      .URLByDeletingLastPathComponent;
    NSBundle *bundle = [NSBundle bundleWithURL:bundleURL];
    if (!bundle) {
      // Up one more level on macOS.
      NSURL *macOSBundleURL = bundleURL.URLByDeletingLastPathComponent;
      bundle = [NSBundle bundleWithPath:macOSBundleURL.absoluteString];
    }
    if (bundle) {
      return bundle;
    }
  }

In above code, macOSBundleURL points to the <app_name>.app file, but the bundle is nil

Looks like getting the app's bundle from app extension is not meant to work. : https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html
For some reason it worked for iOS.
Looks like to make it work, we need to generated a seperated App.framework for the extension instead of accessing the App.framework from the app bundle.

1、delete assets folder
2、flutter build macos —debug (this command will create App.framework folder)
3、recover assets folder
4、flutter build macos —debug


Widgets state is not persisted after switching frontstage

Widget state is not persisted after switching frontstage.
Steps to reproduce the behaviour:

Go to any frontstage
Select any element
Change state (dock/undock, location) of any widget that appears after selecting an element
Go to another frontstage (right after the previous step, without clearing selection)
Go back to the initial frontstage
Select any element again
See that the widget with previously changed state is back to the state it had before the state was changed (it was not persisted)

Expected behaviour
Widget with previously changed state is in the same state and location where it was left before leaving the initial frontstage.

iTwin.js AppUI Version 4.5.1
iTwin.js Core Version 4.1.6

Hi, thanks for reporting this, I'll have a look at this next week, sorry for the delay.

Hi, I cannot reproduce this with the example widget we have currently in 4.6.2.
https://github.com/iTwin/appui/assets/1904889/e1832b40-e7ad-48e2-ae94-f1c56e5867fb
Can you validate if the issue persists on your side ?

Hi, I cannot reproduce this with the example widget we have currently in 4.6.2.
FrontstageSwitch.mp4
Can you validate if the issue persists on your side ?

Hi @raplemie, we also cannot reproduce it anymore with 4.6.1, so it seems this is resolved. Thanks!

Awesome, thanks!


Retried commit after ODistributedRecordLockedException fails and leaks distributed transaction slot

OrientDB Version: 3.1.21 (also present in 3.2)
Java Version: 1.8
OS: Linux/Mac
We have experienced production outages where all commit activity in a distributed database stalls, which by analysing heap dumps we have isolated to all of the promisedSequential slots in OTransactionSequenceManager being occupied by transactions that have long since completed.
We've reproduced the effect locally by running two client threads that rapidly (i.e. with no pauses) query and update a shared record, and create a separate record at the same time.
By instrumenting with logging we isolated the slot leak behaviour to when the transaction fails with a OClusterDoesNotExistException: Cluster id '-1' is outside the of range of configured.
When this error occurs, the transaction in the sequence manager is never cleared (either by notifySuccess or notifyFailure).
The root cause of the OClusterDoesNotExistException appears to be:

one of the competing threads times out in ONewDistributedTransactionManager.retriedCommit with a ODistributedRecordLockedException
the recovery for the exception invokes OTransactionRealAbstract.resetAllocatedIds, which resets the RID for the object creation (to -1,-2) and invokes updateIdentityAfterCommit.
on the next retry, the call to ONewDistributedTransactionManager.getInvolvedClusters fails, because one of the Record has a -1 cluster id.

It looks like a call to ODatabaseDocumentAbstract.assignAndCheckCluster is missing during the reset (which is what happens in the original assignment in OTransactionOptimisticServer.assignClusters, and introducing that call does appear to fix the problem.
What I'm not clear on is whether the ODatabaseDocumentAbstract.assignAndCheckCluster call should be added to OTransactionRealAbstract.updateIdentityAfterCommit or just to OTransactionRealAbstract.resetAllocatedIds, and how exactly updatedRids should be corrected when that happens.

This appears to do what I want:
--- forkSrcPrefix/core/src/main/java/com/orientechnologies/orient/core/tx/OTransactionRealAbstract.java
+++ forkDstPrefix/core/src/main/java/com/orientechnologies/orient/core/tx/OTransactionRealAbstract.java
@@ -624,10 +624,16 @@ public abstract class OTransactionRealAbstract extends OTransactionAbstract
   public void resetAllocatedIds() {
     for (Map.Entry<ORID, ORecordOperation> op : allEntries.entrySet()) {
       if (op.getValue().type == ORecordOperation.CREATED) {
+        ORID current = op.getValue().getRID().copy();
         ORecordId oldNew =
             new ORecordId(op.getKey().getClusterId(), op.getKey().getClusterPosition());
         updateIdentityAfterCommit(op.getValue().getRID(), oldNew);
-        updatedRids.remove(op.getValue().getRID());
+        // Clear previous update RID chain, which will include mapping created by updateIdentityAfterCommit
+        while (current != null) {
+          current = updatedRids.remove(current);
+        }
+        database.assignAndCheckCluster(op.getValue().getRecord(), null);
+        updatedRids.put(op.getValue().getRID().copy(), oldNew);
       }
     }
   }```

I think the same patch would need to be applied to `OMicroTransaction`?

Hi @timw,
For the stalled transaction sequential it should be there a reset when the transaction fail, that free the sequential position, if you want to track it are the call to context.releasePromises(); that will finally call OTransactionSequenceManager.notifyFailure, will double check that is is missing somewhere .
For the problem with the ids reset I do remember I've fixed a similar problem in 3.2.x series a while ago, but the only commit I can find are https://github.com/orientechnologies/orientdb/commit/4ef8c449627cc92e5afb5a8f546bb90f39348cab and b1375cb81a8a3b0fdc9ff0df700995c63eb90347 that seems to be already part of your changes.
Removing all the mapping in updatedRids it may be a bit dangerous,  because in the records there may still be ids pointing to something like 10:-10 that when serialized will not find the mapping anymore to the real id and fail/store a stale pointer.
The process that happen on commit will be transforming an id from 10:-5 or -1:-10 to something like 10:20 ( often the process is multiple steps: -1:-5 -> 10:-5 -> 10:20 and all the steps are in the updatedRids mapping ).
When reverting this id assignment because of concurrent  assignation of clusterPostion (the second part of the id so in 10:20 is 20) the correct way would be reset the id to something like 10:-x to trigger the next id association, and make sure that all the ids mapping (updatedRids) now have as end point the resetted id 10:-x, making sure that the old assigned id is now mapping to the new temporary.
So if before resetting in the updatedRids was there:
-1:-10 -> 10:-10 //First temporary transition
10:-10 -> 10:50 //Final Id assignation that failed to allocate

after reset the map should look something like
-1:-10 -> 10:-10 //First temporary transition
10:50 -> 10:-10 //Previous Id assignation now point to the temporary

so need to remove the 10:-10 -> 10:50  and add 10:50 -> 10:-10.
the id reset should not reset the clusterId ( int the 10:20 is the 10 part ) if is doing that probably there is something wrong.
Yes OMicroTransaction should have the exact same logic (in 3.2.x it merged back in the normal transaction)
(P.S. I know that many thing I wrote here you already know, making it clear to everyone  )

Thanks @tglman - your explanation was very helpful in understanding the intent here (although the updated rids map works in the opposite direction to your examples, tracking back references, so it's a bit confusing).
Having another look at 3.2/develop, it looks like you already fixed this in a667b24, which I should have noticed earlier, so this looks like it's only a 3.1.x bug. That patch appears to work for me.
With the patch applied, the net effect is to set the id to :-x, and the updatedRids map is unchanged (since that id is already present in the map, and the mapping from it to the initial id is restored after the call to updateIdentityAfterCommit.


[GEARPUMP-358] Decrease the frequency of watermark calculation

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[ ] Make sure the commit message is formatted like:
[GEARPUMP-<Jira issue #>] Meaningful description of pull request
[ ] Make sure tests pass via sbt clean test.
[ ] Make sure old documentation affected by the pull request has been updated and new documentation added for new functionality.

Codecov Report

Merging #232 into master will decrease coverage by 0.04%.
The diff coverage is 40%.

@@            Coverage Diff             @@
##           master     #232      +/-   ##
==========================================
- Coverage   69.01%   68.96%   -0.05%
==========================================
  Files         191      191
  Lines        6119     6123       +4
  Branches      358      357       -1
==========================================
  Hits         4223     4223
- Misses       1896     1900       +4

LGTM


Hydrate function messes caret when merging paragraphs

The Hydrate function from commit 103d75b causes a bug when merging blocks. Say that you have Paragraph_1 and Paragraph_2 (different blocks). When you press back on the beginning of Paragraph_2, the new state should be
Paragraph_1 [caret] Paragraph_2
But with the hydrate function the state we get is:
[caret] Paragraph_1 Paragraph_2

Can't reproduce. What is your editor.js version?
https://github.com/editor-js/paragraph/assets/3684889/93eef25b-081d-4708-8fe8-5d40b0a3ace0


AssetCanisterApiClient.MAX_CHUNK_SIZE is too high

Currently the MAX_CHUNK_SIZE is defined as follows
public const int MAX_INGRESS_MESSAGE_SIZE = 2 * 1024 * 1024; // 2MB
...
public const int MAX_CHUNK_SIZE = MAX_INGRESS_MESSAGE_SIZE - 200; // Just under 2MB

With this value I could not upload successfully a chunked file to the AssetCanister. The execution is stuck at
CreateChunkResult result = await this.CreateChunkAsync(createBatchResult.BatchId, chunkBytes);

If I put in a smaller value like
public const int MAX_CHUNK_SIZE = MAX_INGRESS_MESSAGE_SIZE - 500;

it works.

Looks good 👍


Don't Reinstall Installed Packages (when installing from package-file)

Have you checked for existing feature requests?

[X] Completed

Summary
The Problem
When installing a list of packages from a file using the command ppm install --packages-file ./MyPackages.txt, and for some reason the installation of a single package in this list fails (e.g. broken internet connection), re-running the command results in all packages, even those that have already been successfully installed, being rebuilt and reinstalled.
The Solution
When ppm installs packages from a file, it should only install those packages which aren't yet installed, skipping those packages that are already installed.
This behaviour could be optional, e.g. activated by a CLI argument such as --dont-reinstall
What benefits does this feature provide?
This feature would greatly improve the resiliency of PPM when installing multiple packages at once, as it would allow an interrupted installation process to continue where it left off instead of started all over again.
Any alternatives?
I don't see any similarly efficient or effective solutions to the described problem.
Other examples:
No response

This is a great suggestion, and would love to see any PRs attempting an implementation, otherwise is hopefully something that can be looked at soon. Thanks for the contribution!

This does technically introduce a breaking change if we were to add it.
i.e. currently ppm install can be used to both install a package from scratch as well as updating an existing package.
Of course there are other commands, namely ppm upgrade and ppm update (and ppm outdated) which, when run alone will perform updates for everything on the system but can accept the package name as an argument.
Although technically breaking I think there is a case for making some changes to some of these commands. Essentially what is being requested here is unrelated to the package file but asking to change the behaviour of how the install command works.

This does technically introduce a breaking change if we were to add it.
i.e. currently ppm install can be used to both install a package from scratch as well as updating an existing package.

It wouldn't be a breaking change if ppm install were to update out-of-date packages and skip reinstalling up-to-date packages.

@emendir this already seems to be the intended behavior for everything that isn't "installed globally", whatever that means. https://github.com/pulsar-edit/ppm/blob/bc06ac66615eb90e0977e46f45603acefd49c5b0/src/install.js#L267
I don't know if that is supposed to be an option somehow coming from the user, all I can see is that it's set to false for dependencies.
The question really is whether lifting that if-check could break anything elsewhere.


bower normalize-css#~2.1.2             ECMDERR Failed to execute "git ls-remote --tags --heads git://github.com/necolas/normalize.css.git", exit code of #128

Failed when run bower install, error No. is "No such file or directory"

It turns out it usually happens because of connectivity issues


Tracing podip bugfix test

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

/test all

/test all


Add a clear options on Select component

Feature request 🚀

[ ] I will create Pull Request
[x] It's just a suggestion

Expected

Would be nice to be able to add a clearable option to Select.
Not sure what we would like to do with that on single value but on the multiple Select, we could maybe add an icon (cross) to remove the option so you don't need to go into the list to remove an option.

Not sure if we want the option to be on the Select.Option or Select component.
Examples
 <GeistSelect multiple>
       {options.map((option) => (
           <GeistSelect.Option value={option.value} clearable>
               {option.label}
           </GeistSelect.Option>
        ))}
 </GeistSelect>

I agree with you that adding clearable to multiple-mode helps the user experience.

You think it should be by default when multiple is true?
or to add it to the Option component?

Been thinking a bit about this, the way i would do it is:

when multiple is true, clearable is true by default (i think it's a good UX to get a clearable select by default)
when multiple is true, you can pass clearable to false if you don't want it
if you pass clearable as a prop to select without multiple, we just ignore it

Does that makes sense for you or you would like something different?

You're absolutely right. I totally agree with you on this feature. @wcastand 👍

The feature was merged in rc so we can probably close this issue or you want to wait for the release on npm? @unix

We can close it now, and pre-release v2.1.0-canary.2 is out.


Can enroot be configured to support docker private registry with self signed certificate?

I tried to import docker image from private registry to enroot, but failed at SSL certificate problem:
enroot import 'docker://admin@hub.com#busybox:latest'
[INFO] Querying registry for permission grant
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
Can enroot be configured to support docker private registry with self signed certificate?
Thank you!

You should be able to configure the SSL_CERT_ variables in enroot.conf or in your environment.

I have created the self signed certificate and saved in /etc/docker/certs.d/hub.com/ca.crt. And I used curl to test it:
$ curl  https://hub.com/v2/_catalog
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
$ curl --cacert /etc/docker/certs.d/hub.com/ca.crt https://hub.com/v2/_catalog
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"registry","Class":"","Name":"catalog","Action":"*"}]}]}
But I setup the following SSL_CERT_ variables in /etc/enroot.conf,
SSL_CERT_DIR               /etc/docker/certs.d/hub.com
SSL_CERT_FILE              ca.crt
When I ran enroot import 'docker://admin@hub.com#busybox:latest', I still got the same error. Is my SSL_CERT_ variables setup correct? Thank you.

You should only use one of the other, for the file one it should be an absolute path.
And again if you use a directory, make sure that the directory has been rehashed.
Note that you can test these variables with curl similarly

Thank you for your help. After I setup the SSL_CERT_FILE in /etc/enroot.conf, it failed at "http" error.
$ enroot import 'docker://admin@hub.com#busybox:latest'
[INFO] Querying registry for permission grant
[INFO] Authenticating with user: admin
Enter host password for user 'admin':
curl: (1) Protocol "http" not supported or disabled in libcurl
I used curl to test hub.com with HTTP and HTTPS:
$ curl --cacert /etc/docker/certs.d/hub.com/ca.crt https://hub.com/v2/_catalog
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"registry","Class":"","Name":"catalog","Action":"*"}]}]}
$ curl --cacert /etc/docker/certs.d/hub.com/ca.crt http://hub.com/v2/_catalog
curl: (7) Failed to connect to hub.com port 80: Connection refused
The ENROOT_ALLOW_HTTP has been set to "no" in enroot.conf. Should I disable other variables in enroot.conf?  Thank you.

It looks like it's trying to go through http at some point (maybe a redirect), if so yes you would need ENROOT_ALLOW_HTTP

It works with ENROOT_ALLOW_HTTP yes. Thank you a lot for your help!


Unify type coercion and casting

Is your feature request related to a problem or challenge?
I think there is room for improvement in type coerceion or casting.
Background
comparison_coercion is widely used in datafusion, a lossless conversion
https://github.com/apache/arrow-datafusion/blob/main/datafusion/expr/src/type_coercion/binary.rs
can_coerce_from is used mainly for signature, a lossless conversion
https://github.com/apache/arrow-datafusion/blob/main/datafusion/expr/src/type_coercion/functions.rs
can_cast_types is from arrow-cast, which is a lossy conversion. It is also used in some comparison_coercion building block. https://github.com/apache/arrow-rs/blob/df69ef57d055453c399fa925ad315d19211d7ab2/arrow-cast/src/cast.rs#L76-L273
Not sure if there is other coercion I missed
Proposal
comparison_coercion and can_coerce_from seem like doing the similar thing, maybe we can just have one lossless conversion. If lossless conversion is useful for arrow-rs, we can introduce a lossless version of can_cast_types, then rely on it for datafusion.
Lossy conversion vs Lossless
I think the definition for lossy is that the value is not recoverable after casting back, otherwise it is lossless.
Lossy

Int32 to Int16 / Int8

Lossless

Int32 to Int64

Describe the solution you'd like

Replace can_coerce_from with comparison_coercion's building block numeric coercion, list coercion, string coercion, null coercion, etc
Split list_coercion from string_coercion to make each building block of coercion clear on the task it focus on. list_coercion do list/fixed size list/large list coercion, string_coercion do utf/large utf coercion.
Introduce these lossless coercion to arrow-rs?

Known issue or question I have

Introduce list_coercion that currently exist in string_concat_coercion
No list coercion for can_coerce_from
Decimal128 can cast to Float64 in can_coerce_from, why?

Describe alternatives you've considered
If there are many customize conversion need, then this change might not be helpful at all. We need other approach to let type casting / coercion easy to use.
No response
Additional context
No response

@tustvold Do you think introduce a lossless version of can_cast_types helpful?
cc @alamb

Decimal128 can cast to Float64 in can_coerce_from, why?

Floating points inherently permit precision loss

No list coercion for can_coerce_from

I think this would make sense as an addition, the current support for nested types in arrow-cast is very limited.

If lossless conversion is useful for arrow-rs

In general I think it would be very confusing if coercion can result in silent data loss, perhaps you might articulate why this would be useful? My current thinking is casting should never silently lose data.

My current thinking is casting should never silently lose data.
https://github.com/apache/arrow-rs/blob/df69ef57d055453c399fa925ad315d19211d7ab2/arrow-cast/src/cast.rs#L76C2-L80

Comment in can_cast_types mention that cast is lossy.
https://github.com/apache/arrow-rs/blob/df69ef57d055453c399fa925ad315d19211d7ab2/arrow-cast/src/cast.rs#L212-L216
Casting Int64 to Int32 return true. I'm not sure if the actual casting block this lossy conversion, but if not, this can silently lose data?

That comment is incorrect and doesn't match the implementation

That comment is incorrect and doesn't match the implementation. I believe it means that it supports conversions that are potentially fallible, e.g. Int32 to Int8, but it never silently looses data

Any scenario that we should hint it as potentially fallible but actually do nothing for them? It seems to me return false is more straightforward if we does not do the casting.

However, I think we can still cleanup comparison_coercion  and can_coerce_from  and forget about lossy conversion.

That comment is incorrect and doesn't match the implementation. I believe it means that it supports conversions that are potentially fallible, e.g. Int32 to Int8, but it never silently looses data

Any scenario that we should hint it as potentially fallible but actually do nothing for them? It seems to me return false is more straightforward if we do nothing.

Maybe Int64(1) cast to Int32(1) is one that is able to safely cast without data loss.

Maybe we need another verions of can_cast_types that no possible falliable hint. For i64, only u64 or larger type, no i32 or i16 since we dont know the actually data.

Is that not what can_coerce_from is?

can_coerce_from

Yes! Should we have it aside can_cast_types  in arrow-rs? Or just let it stay in datafusion for now.

Given the type coercion logic itself lives in DataFusion I personally think it makes sense for it to remain alongside it

Short summary for the next step of this issue

Cleanup can_coerce_from and comparison_coercion, reuse the code if possible. Rely on arrow-rs first (can_cast_types) if possible.
Add nested support. Start from List

https://github.com/apache/arrow-datafusion/blob/2a692446f46ef96f48eb9ba19231e9576be9ff5a/datafusion/expr/src/type_coercion/binary.rs#L388-L406
In comparison_binary_numeric_coercion, signed type and u64 is coerced to i64, anyone knows why is this acceptable?

https://github.com/apache/arrow-datafusion/blob/2a692446f46ef96f48eb9ba19231e9576be9ff5a/datafusion/expr/src/type_coercion/binary.rs#L388-L406
In comparison_binary_numeric_coercion, signed type and u64 is coerced to i64, anyone knows why is this acceptable? what kind of cases are?
for type u64 and f32, it will return f32 which is smaller than u64, not sure why is this too

The comment in the code you linked seems to say "some information loss is inevitable":
        // The following match arms encode the following logic: Given the two
        // integral types, we choose the narrowest possible integral type that
        // accommodates all values of both types. Note that some information
        // loss is inevitable when we have a signed type and a `UInt64`, in
        // which case we use `Int64`;i.e. the widest signed integral type.

It is likely for "usability" so that you can compare i64 and u64 without an explicit type cast 🤷

https://github.com/apache/arrow-datafusion/blob/2a692446f46ef96f48eb9ba19231e9576be9ff5a/datafusion/expr/src/type_coercion/binary.rs#L388-L406
In comparison_binary_numeric_coercion, signed type and u64 is coerced to i64, anyone knows why is this acceptable? what kind of cases are?
for type u64 and f32, it will return f32 which is smaller than u64, not sure why is this too

The comment in the code you linked seems to say "some information loss is inevitable":
        // The following match arms encode the following logic: Given the two
        // integral types, we choose the narrowest possible integral type that
        // accommodates all values of both types. Note that some information
        // loss is inevitable when we have a signed type and a `UInt64`, in
        // which case we use `Int64`;i.e. the widest signed integral type.

It is likely for "usability" so that you can compare i64 and u64 without an explicit type cast 🤷

I don't think that usability is the good reason :(  It might cause data loss.
@alamb I would like to change them to the straightforward version, choose the larger type between two. I think it can also be used all the place in datafusion easily (one place is can_coerce_from). Is there any concern about this change?

// The following match arms encode the following logic: Given the two
// integral types, we choose the narrowest possible integral type that
// accommodates all values of both types. Note that some information
// loss is inevitable when we have a signed type and a UInt64, in
// which case we use Int64;i.e. the widest signed integral type.

I rethink about this. This is the best we can do, like the comment mentioned, it is inevitable :(

After #8385, I found that it is not ideal to have one coercion for all the place (compare op, math op, signature coercion, etc... ).


kubernetes: 1.19.5 -> 1.20.4 (dockerd -> containerd)

Motivation for this change
This is an alternative to #109275 and #114722
Since docker 20.X has removed dockershim and Kubernetes as well has deprecated docker as container-runtime, it seemed sensible to switch to containerd as default runtime for the NixOS module.
The standard RBAC and DNS tests pass on my machine: nix-build nixos/release.nix -A tests.kubernetes.rbac.singlenode -A tests.kubernetes.rbac.multinode -A tests.kubernetes.dns.singlenode -A tests.kubernetes.dns.multinode
The PR is WIP because it still lacks documentation. Notably rel-notes, but probably also updates to sec-kubernetes in the manual.
Also, I'd like reviewers input to the question of how production ready the container runtime should be configured? Currently, I've gone with a minimal containerd.toml and minimal systemd parameters for the service. For production workloads, one likely want to configure things like ulimiits, oom-scores, cgroup params etc. Some of these settings are already set explicitly for virtualisation.docker, so users might expect this to be taken care of upstream.
Let me hear your thoughts.
cc @saschagrunert  @srhb
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[X] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

I believe the kube-addons manager can be provided with a deprecation message since upstream did deprecate the concept (not meant to block anything, jut a chore idea).
The CI tests fail at the same point as temhe other two PRs for good reason, the attribute is effectively not devlared in top.
Thank you a lot for pushing this!

Heads up for reviewers: 964ee25fed6772b955f6d5d603bbf9a4a8385e2a adds limits and oomscore for the containerd systemd-service. Personally, I feel infinity is quite aggressive here; that is nonetheless what upstream "recommends" (https://github.com/containerd/containerd/blob/master/containerd.service#L29-L37). Feedback would be much appreciated here.

Added release note.
IMHO manual changes are not needed for now, since sec-kubernetes doesn't mention docker specifically. With regards to the deprecated addon-manager, I plan to create an issue on removing this, but that's likely gonna be a next-release (21.11) thing.
(kind of expected we now how rel-note merge conflicts, will rebase nixos-unstable shortly)

LGTM, thanks @johanot.

Rebased on master to resolve a merge conflict in rl-2105.xml.
I'm running the nixos tests , I'll merge after they pass.

@ofborg build kubernetes

For informative purposes only: kustomize is going to land soon as part of kubectl with https://github.com/kubernetes/kubernetes/pull/98946
We should try to get this change into packages before next NixOS release.


⚠ Bofrost.es has degraded performance

In cf5b004, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1369 ms

Resolved: Bofrost.es performance has improved in f57181d after 1 hour, 56 minutes.


Dockerfile: remove inline comments

Newer docker version (> 1.12.x) now perform a pre-build syntax check. Inline comments are no longer allowed.
Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>

LGTM.  It would be nice to preserve at least the comment about the version conflict, but do feel free to merge as is.


Fix the changelog updated ports count.

Drive by: get rid of from/to
Thanks to @autoantwort for pointing this out.

No from/to because it is implicit via the last release?

Is the to part different by mistake?

Is the to part different by mistake?

What a great example of why that line is bad! :)


postal.logger statement doesn't compile

Hi klevefre,
you wrote about debugging Postal:

You can set a closure on a Postal instance to have IMAP logs:
let postal = Postal(configuration: ...)
postal.logger { log in
print(log)
}

Unfortunately this doesn't work in my code.
I get the compiler error message "Cannot call value of non-function type 'logger?'
This is my code:
init(hostname: String, userName: String, password: String) {
    log.debug("init called...")

    configuration = Configuration(hostname: hostname, port: 993, login: userName, password: .plain(password), connectionType: .tls, checkCertificateEnabled: false)

    let postal: Postal = Postal(configuration: configuration)
    postal.logger { log in
        print(log)
    }
[...]

What's wrong with my code? It's exactly as you wrote...?

I'm sorry i've made a typo it's:
let postal = Postal(configuration: ...)
postal.logger = { log in
    print(log)
}


JS scoping issue

I'm getting the following error in openfl.display3D.textures.VideoTexture when trying to play video via Starling when targetting html5:
Uncaught TypeError: _gthis.__textureReady is not a function
It seems like the scope for 'this' is messed up and instead of this referencing the VideoTexture class it is referencing the attachNetStream function. Any idea on what might be causing this? is it an OpenFL problem, or at a Haxe level? I'm not really sure how to work around this :/
This issue is present in the Starling demo video scene

Fixed!
My guess is that passing a closure preserves the scope, for example, consider the following:
private function callMethod (method:Dynamic):Void {
    Reflect.callMethod (method, method, []);
}
...
callMethod (myMethod);

In JavaScript, I think this behaves similar to:
callMethod (myMethod.bind ());

...as a result, the scope of this is preserved within the function that is passed, so even though the scope when the method is called is the method, not the class, it works fine because the closure is wrapped to preserve scope.
However, code in Starling here was using Reflect.field first:
var method = Reflect.field(base, "attach" + type);
Reflect.callMethod(method, method, [attachment]);

...this was passing the vanilla attachNetStream method to Reflect.callMethod, which has no guards to protect its scope. The fix was to use base as the scope when calling the method.
Tricky :smile:

Hey Joshua. Thanks for looking into this, really appreciate it!
I really don't get js scoping, it seems super unhelpful.


Dashboard reports 0 for all MPS

This is likely because it's not using the "records" key from each user

Also noticed this. +1


PREFIX value doesn't seem to propagate well enough when packaging

Hyprland Version
 System/Version info
Hyprland, built from branch HEAD at commit 03ebbe18ed8517ee22591eac82cd54322f42cb7d  (props: bump ver to 0.34.0).
Date: Mon Jan 1 12:03:15 2024
Tag: v0.34.0

flags: (if any)
legacyrenderer

Bug or Regression?
Bug
Description
Built Hyprland for Debian Testing (for own use only) with PREFIX=/usr and a local DESTDIR for packaging, On installed package, hyprpm has similar behaviour to #4082 . In my case, the problem was hyprland.pc still pointing to /usr/local as prefix. Once this was corrected, it worked fine. Somehow cmake believed that prefix was still /usr/local when creating hyprland.pc.
How to reproduce
Build with prefix different than default /usr/local
Crash reports, logs, images, videos
No response

Did you build using CMake (with the Makefile) or using Meson?

With the Makefile.

I'll look into it, but it might take a while. In the meantime you could use Meson to build Hyprland, as that's known to work properly.

issue is here:
https://github.com/hyprwm/Hyprland/blob/4b4bd90b1450cbfc01d9ac429363cc7cecd6be8b/CMakeLists.txt#L14-L15
cmake prefix is never set to the PREFIX env in the makefile.
Probably should add -DCMAKE_INSTALL_PREFIX:STRING=${PREFIX} in the makefile to cmake config commands.

@pkreuzt can you try this patch?
patch.txt

Tried your patch and it seems to set the prefix fine on hyprland.pc
On a sidenote, I've not hit (yet) the above referenced issue about mismatched packaged headers. At least with hyprland.pc path correctly set. Actually I updated my installed (official) plugins today with hyprpm without an issue.

it would happen if you for example:

install an official package (e.g. hyprland on arch)
clone hyprland from git
install manually

e65f52bf2d6abb001c402c8302ac7003da8cd06d


Documentation (docker attach): explain how to attach a combination of stdin/stdout/stderr

The documentation for the docker attach command says:

Use docker attach to attach your terminal’s standard input, output, and error (or any combination of the three) to a running container

But it does not explain how to attach to any combination of standard input, output and error. (Even though one can guess that specifying --no-stdin will only attach the user's terminal's standard output and error to the running container's standard output and error.)
It would be great if the syntax was explained (at least with an example, e.g. indicating how to attach stdin and stderr only).
File: engine/reference/commandline/attach.md

Looks from all the testing I've done that --no-stdin is the only ocnfigurable option regarding standard streams. I've tried things like --no-stdout and no-stderr and they don't work. I propose we remove the "(or any combination of the three)" wording form the Extended description section.

Thanks for your answer Nigel!
Well, if you confirm that there really is no way to attach any chosen subset of stdin, stdout and stderr with the docker attach command, then yes, I agree that the documentation should reflect that fact.
But that would be rather surprising to me since the docker run command allows you to do that (by specifying the --attach option multiple times) when running a container (as opposed to attaching to one, as is the case for the docker attach command).
Wouldn't that be strange that a command specifically designed to attach to a running container doesn't allow users to choose what standard streams to attach when a less specific command (docker run) allows them to?

Gotcha @youssefabidi totally agree!
I'll see if I can do some digging.
I think the issue might that you've found a bug or missing feature. If you have, we'll need to raise against the appropriate code repo. The job of the docs is to accurately represent what Docker actually does - not what it should do ;-)
I'll do some chasing next week.  Appreciate the heads-up on this.


HBASE-26473 Introduce db.hbase.container_operations span attribute

For batch operations, collect and annotate the associated span with the set of all operations contained in the batch.
This is an HBase-specific extension that I am proposing. The idea here is to provide a single field containing all of the operations contained within an "envelope-type" operation. That field can then be indexed for query, allowing operators to easily find the operations that they seek. This is a project-specific proposal for a solution to the general issue I raised on open-telemetry/opentelemetry-specification#2202.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 14s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 37s
master passed

+1 :green_heart:
compile
0m 55s
master passed

+1 :green_heart:
shadedjars
9m 11s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 46s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 20s
the patch passed

+1 :green_heart:
compile
0m 52s
the patch passed

+1 :green_heart:
javac
0m 52s
the patch passed

+1 :green_heart:
shadedjars
9m 13s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 45s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 56s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 35s
hbase-client in the patch passed.

37m 26s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3951

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux fea62f726dbb 4.15.0-153-generic #160-Ubuntu SMP Thu Jul 29 06:54:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8f5a12f794

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/testReport/

Max. process+thread count
227 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 59s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 17s
master passed

+1 :green_heart:
compile
0m 57s
master passed

+1 :green_heart:
shadedjars
9m 10s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 51s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 10s
the patch passed

+1 :green_heart:
compile
0m 58s
the patch passed

+1 :green_heart:
javac
0m 58s
the patch passed

+1 :green_heart:
shadedjars
9m  7s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 50s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m 26s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 50s
hbase-client in the patch passed.

39m 36s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3951

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 95845900ecb0 4.15.0-162-generic #170-Ubuntu SMP Mon Oct 18 11:38:05 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8f5a12f794

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/testReport/

Max. process+thread count
217 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 26s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  3s
master passed

+1 :green_heart:
compile
1m 45s
master passed

+1 :green_heart:
checkstyle
0m 53s
master passed

+1 :green_heart:
spotbugs
1m 45s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 47s
the patch passed

+1 :green_heart:
compile
1m 44s
the patch passed

+1 :green_heart:
javac
0m 48s
hbase-common in the patch passed.

+1 :green_heart:
javac
0m 56s
hbase-client generated 0 new + 121 unchanged - 1 fixed = 121 total (was 122)

+1 :green_heart:
checkstyle
0m 51s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
19m 24s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
2m  7s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 28s
The patch does not generate ASF License warnings.

46m 23s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3951

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 8f7684e027a7 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8f5a12f794

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Let's wait on this change until either we receive clear direction from open-telemetry/opentelemetry-specification#2202 or I can show clear benefit in my end-to-end testing.

Seems no progress on the otel side? So maybe it is a chance for us to define the best practice of tracing multi/batch operations?

Seems no progress on the otel side? So maybe it is a chance for us to define the best practice of tracing multi/batch operations?

Still no comments from them. If you are still +1, @Apache9 , I'll rebase this commit and merge it. Lack of response from upstream isn't great though.

Seems no progress on the otel side? So maybe it is a chance for us to define the best practice of tracing multi/batch operations?

Still no comments from them. If you are still +1, @Apache9 , I'll rebase this commit and merge it. Lack of response from upstream isn't great though.

Just go ahead. I'm OK with the current approach.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 22s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 45s
master passed

+1 :green_heart:
compile
0m 58s
master passed

+1 :green_heart:
shadedjars
9m 31s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 51s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 29s
the patch passed

+1 :green_heart:
compile
0m 55s
the patch passed

+1 :green_heart:
javac
0m 55s
the patch passed

+1 :green_heart:
shadedjars
9m 10s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 42s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m 24s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 35s
hbase-client in the patch passed.

38m 47s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3951

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 70da4717816f 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7be9f26e40

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/testReport/

Max. process+thread count
220 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 24s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 43s
master passed

+1 :green_heart:
compile
1m 56s
master passed

+1 :green_heart:
checkstyle
0m 56s
master passed

+1 :green_heart:
spotbugs
2m  2s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 19s
the patch passed

+1 :green_heart:
compile
1m 54s
the patch passed

+1 :green_heart:
javac
0m 51s
hbase-common in the patch passed.

+1 :green_heart:
javac
1m  3s
hbase-client generated 0 new + 121 unchanged - 1 fixed = 121 total (was 122)

+1 :green_heart:
checkstyle
0m 56s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
22m 27s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
2m  9s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 22s
The patch does not generate ASF License warnings.

52m 49s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3951

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 60ac528f68bc 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7be9f26e40

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
86 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
5m 10s
Docker mode activated.

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 29s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
7m 47s
master passed

+1 :green_heart:
compile
1m 23s
master passed

+1 :green_heart:
shadedjars
11m 38s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 21s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
6m 44s
the patch passed

+1 :green_heart:
compile
1m 21s
the patch passed

+1 :green_heart:
javac
1m 21s
the patch passed

+1 :green_heart:
shadedjars
11m  9s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  5s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 16s
hbase-common in the patch passed.

+1 :green_heart:
unit
2m 25s
hbase-client in the patch passed.

56m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3951

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux fd87ccc09f19 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7be9f26e40

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/testReport/

Max. process+thread count
242 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3951/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Model catalog - indicate whether model is private or public

Maybe with an icon?

a locked / unlocked padlock would be good?

yes, or locked padlock and book, as used for private and public collabs


cmd/compile: fix long RMW bit operations on AMD64 [1.16 backport]

Backport of #45242 :

Under certain circumstances, the existing rules for bit operations can produce code that writes beyond its intended bounds.

@pgavlin


Feature/setup workspace server api main

Description

Issues Resolved

Screenshot

Testing the changes

Check List

[ ] All tests pass

[ ] yarn test:jest
[ ] yarn test:jest_integration
[ ] yarn test:ftr

[ ] New functionality includes testing.
[ ] New functionality has been documented.
[ ] Update CHANGELOG.md
[ ] Commits are signed per the DCO using --signoff

Codecov Report
Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (9c192a3) 66.50% compared to head (5219fce) 55.30%.
 Consider uploading reports for the commit 46238e1 to get more accurate results

Additional details and impacted files
@@                   Coverage Diff                    @@
##           workspace-pr-integr       #4       +/-   ##
========================================================
- Coverage                66.50%   55.30%   -11.21%
========================================================
  Files                     3403     1183     -2220
  Lines                    65026    23660    -41366
  Branches                 10401     3917     -6484
========================================================
- Hits                     43243    13084    -30159
+ Misses                   19214     9968     -9246
+ Partials                  2569      608     -1961

Flag
Coverage Δ

Linux_1
?

Linux_2
55.30% <91.48%> (-0.02%)
:arrow_down:

Linux_4
?

Windows_1
?

Windows_2
?

Windows_3
?

Windows_4
?

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

Files
Coverage Δ

packages/osd-ui-shared-deps/index.js
100.00% <ø> (ø)

...lication/capabilities/capabilities_service.mock.ts
100.00% <ø> (ø)

src/core/public/core_system.test.mocks.ts
100.00% <100.00%> (ø)

src/core/public/core_system.ts
91.95% <100.00%> (+0.38%)
:arrow_up:

src/core/public/doc_links/doc_links_service.ts
100.00% <ø> (ø)

src/core/public/mocks.ts
18.18% <ø> (-40.91%)
:arrow_down:

src/core/public/plugins/plugin_context.ts
44.44% <ø> (ø)

...c/core/public/workspace/workspaces_service.mock.ts
100.00% <100.00%> (ø)

...e/server/capabilities/capabilities_service.mock.ts
75.00% <ø> (ø)

...c/core/server/capabilities/capabilities_service.ts
100.00% <ø> (ø)

... and 10 more

... and 2507 files with indirect coverage changes

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