HADOOP-18332: remove rs-api dependency as it conflicts with jsr311-api

Description of PR
Relates to https://issues.apache.org/jira/browse/HADOOP-18332 - rs-api jar seems to cause conflicts with jsr311-api jar (latter is needed by jersey-core 1.19)
How was this patch tested?
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

@pjfanning could you please create PR against branch-3.3 in parallel? I think this would be more beneficial to branch-3.3 than trunk. On HADOOP-18033, it's still being discussed if we should only consider branch-3.3 for this PR because HADOOP-15984 anyways requires javax.ws.rs-api (and hence, Jackson 2.13).

@virajjasani I created https://github.com/apache/hadoop/pull/4552 for the 3.3 branch

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m 38s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+0 :ok:
shelldocs
0m  1s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 39s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
28m 21s

trunk passed

+1 :green_heart:
compile
26m 28s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
23m 20s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
mvnsite
23m 19s

trunk passed

+1 :green_heart:
javadoc
11m 13s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
8m 33s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
shadedclient
43m 29s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 35s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
37m  8s

the patch passed

+1 :green_heart:
compile
27m 32s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
27m 32s

the patch passed

+1 :green_heart:
compile
23m 24s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

-1 :x:
javac
23m 24s
/results-compile-javac-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 generated 1 new + 2674 unchanged - 2 fixed = 2675 total (was 2676)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
23m 20s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
10m 52s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
8m 12s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
shadedclient
44m 47s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
1082m 28s
/patch-unit-root.txt
root in the patch passed.

+1 :green_heart:
asflicense
2m 19s

The patch does not generate ASF License warnings.

1406m 15s

Reason
Tests

Failed junit tests
hadoop.fs.http.server.TestHttpFSServer

hadoop.yarn.server.nodemanager.webapp.TestNMWebServices

hadoop.yarn.server.nodemanager.containermanager.TestContainerManagerRecovery

hadoop.yarn.server.TestMiniYarnCluster

hadoop.yarn.server.timelineservice.security.TestTimelineAuthFilterForV2

hadoop.yarn.server.timelineservice.TestTimelineServiceClientIntegration

hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageEntities

hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowRunCompaction

hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowRun

hadoop.yarn.server.timelineservice.storage.TestTimelineWriterHBaseDown

hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesHBaseStorage

hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageApps

hadoop.yarn.server.timelineservice.storage.flow.TestHBaseStorageFlowActivity

hadoop.yarn.server.timelineservice.storage.TestTimelineReaderHBaseDown

hadoop.yarn.server.timelineservice.storage.TestHBaseTimelineStorageDomain

hadoop.yarn.server.timelineservice.documentstore.TestDocumentStoreTimelineReaderImpl

hadoop.yarn.server.timelineservice.documentstore.reader.cosmosdb.TestCosmosDBDocumentStoreReader

hadoop.yarn.server.timelineservice.documentstore.collection.TestDocumentOperations

hadoop.yarn.server.timelineservice.documentstore.TestDocumentStoreTimelineWriterImpl

hadoop.yarn.server.timelineservice.documentstore.writer.cosmosdb.TestCosmosDBDocumentStoreWriter

hadoop.yarn.server.timeline.webapp.TestTimelineWebServicesWithSSL

hadoop.yarn.server.timeline.webapp.TestTimelineWebServices

hadoop.yarn.server.applicationhistoryservice.webapp.TestAHSWebApp

hadoop.yarn.server.applicationhistoryservice.TestApplicationHistoryServer

hadoop.yarn.server.timeline.security.TestTimelineAuthenticationFilterForV1

hadoop.yarn.server.applicationhistoryservice.webapp.TestAHSWebServices

hadoop.yarn.server.resourcemanager.TestRMRestart

hadoop.yarn.server.resourcemanager.metrics.TestCombinedSystemMetricsPublisher

hadoop.yarn.server.resourcemanager.TestRMHATimelineCollectors

hadoop.yarn.server.resourcemanager.metrics.TestSystemMetricsPublisherForV2

hadoop.yarn.server.resourcemanager.TestResourceTrackerService

hadoop.yarn.server.resourcemanager.metrics.TestSystemMetricsPublisher

hadoop.yarn.server.timelineservice.reader.TestTimelineReaderServer

hadoop.yarn.server.timelineservice.storage.TestFileSystemTimelineReaderImpl

hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServices

hadoop.yarn.server.timelineservice.reader.TestTimelineUIDConverter

hadoop.yarn.server.timelineservice.reader.TestTimelineReaderWebServicesACL

hadoop.yarn.server.timelineservice.collector.TestPerNodeTimelineCollectorsAuxService

hadoop.yarn.server.timelineservice.collector.TestTimelineCollector

hadoop.yarn.server.timelineservice.storage.TestFileSystemTimelineWriterImpl

hadoop.yarn.server.timelineservice.collector.TestNMTimelineCollectorManager

hadoop.yarn.applications.distributedshell.TestDSTimelineV10

hadoop.yarn.applications.distributedshell.TestDSTimelineV15

hadoop.yarn.applications.distributedshell.TestDSWithMultipleNodeManager

hadoop.yarn.applications.distributedshell.TestDSTimelineV20

hadoop.yarn.client.TestApplicationMasterServiceProtocolForTimelineV2

hadoop.yarn.client.api.impl.TestYarnClient

hadoop.yarn.client.api.impl.TestYarnClientImpl

hadoop.yarn.api.records.timeline.TestTimelineRecords

hadoop.yarn.api.records.timelineservice.TestTimelineServiceRecords

hadoop.yarn.util.timeline.TestShortenedFlowName

hadoop.mapred.TestMRTimelineEventHandling

hadoop.mapreduce.jobhistory.TestJobHistoryEventHandler

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4547

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux 5e722710f376 4.15.0-175-generic #184-Ubuntu SMP Thu Mar 24 17:48:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / c11b0ee41932e889e9190e70656839721afe8c71

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/1/testReport/

Max. process+thread count
2380 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-applicationhistoryservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-tests hadoop-mapreduce-project/hadoop-mapreduce-client hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timeline-pluginstorage hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/hadoop-yarn-server-timelineservice-hbase-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase-tests hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-router hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-services/hadoop-yarn-services-core hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/1/console

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.

Closing in favour of https://github.com/apache/hadoop/pull/4544

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 58s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+0 :ok:
shelldocs
0m  1s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 44s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
30m 56s

trunk passed

+1 :green_heart:
compile
28m 59s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
23m 58s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
mvnsite
20m 51s

trunk passed

+1 :green_heart:
javadoc
9m 49s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
8m 45s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
shadedclient
42m 31s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 45s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
39m 14s

the patch passed

+1 :green_heart:
compile
28m  5s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
28m  5s

the patch passed

+1 :green_heart:
compile
24m 11s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

-1 :x:
javac
24m 11s
/results-compile-javac-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 generated 4 new + 2674 unchanged - 2 fixed = 2678 total (was 2676)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
20m  9s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
9m 19s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
8m 23s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
shadedclient
44m  1s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
1106m 39s

root in the patch passed.

+1 :green_heart:
asflicense
2m 21s

The patch does not generate ASF License warnings.

1431m 47s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4547

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux 3aeb47be2b12 4.15.0-175-generic #184-Ubuntu SMP Thu Mar 24 17:48:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 276508d428fbed07bfb610f5149c38b139a5d7ae

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/2/testReport/

Max. process+thread count
2386 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-applicationhistoryservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-tests hadoop-mapreduce-project/hadoop-mapreduce-client hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timeline-pluginstorage hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/hadoop-yarn-server-timelineservice-hbase-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase-tests hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-router hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-services/hadoop-yarn-services-core hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/2/console

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.

@ayushtkn I had those changes ready to commit before I closed this PR - I've merged them now - we'll see how this build goes

Nothing major changing so the build should stay clean.
@pjfanning can you reopen the branch-3.3 PR as well and add these changes?

If the build comes clean, on a quick look I am +1 on this. Please give a check or let me know if someone intends to do so and needs time, I will hold this further

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 50s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+0 :ok:
shelldocs
0m  1s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 11s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
28m 20s

trunk passed

+1 :green_heart:
compile
28m 41s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
21m 46s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
mvnsite
19m 44s

trunk passed

+1 :green_heart:
javadoc
8m 32s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
7m 34s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
shadedclient
38m 42s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 42s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
43m 10s

the patch passed

+1 :green_heart:
compile
24m 26s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
24m 26s

the patch passed

+1 :green_heart:
compile
21m 42s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

-1 :x:
javac
21m 42s
/results-compile-javac-root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07.txt
root-jdkPrivateBuild-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07 generated 1 new + 2674 unchanged - 2 fixed = 2675 total (was 2676)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
19m 31s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
javadoc
8m 22s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
7m 31s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
shadedclient
40m 12s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
1052m 38s

root in the patch passed.

+1 :green_heart:
asflicense
2m 18s

The patch does not generate ASF License warnings.

1359m 53s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4547

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint shellcheck shelldocs

uname
Linux<PHONE_NUMBER>2f 4.15.0-175-generic #184-Ubuntu SMP Thu Mar 24 17:48:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / b847d71a135ae4c2037309649df899bba815fa3d

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/4/testReport/

Max. process+thread count
3143 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-applicationhistoryservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-tests hadoop-mapreduce-project/hadoop-mapreduce-client hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timeline-pluginstorage hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/hadoop-yarn-server-timelineservice-hbase-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase-tests hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-router hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-services/hadoop-yarn-services-core hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp hadoop-client-modules/hadoop-client-runtime hadoop-client-modules/hadoop-client-minicluster . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4547/4/console

versions
git=2.25.1 maven=3.6.3 shellcheck=0.7.0

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

This message was automatically generated.


Package snapshot releases?

We currently package the "stable" 1.14.x series of Cairo releases. But there is also the 1.15.x "snapshot" series, which may not be "stable" but is at least formalized enough that there are numbered releases. The latest releases of the librsvg package rely on these snapshots, so we can't package them until something in the 1.15.x series or beyond gets packaged.
Anyway, the question is whether we should only package stable releases or start tracking the snapshots. I tend to think that we should stick with the stable series, but I wanted to bring the matter up for discussion.

We can add them to the dev label. Though we haven't really formalized it well. ( https://github.com/conda-forge/conda-forge-enhancement-proposals/pull/3 ) There is a separate question about how we package things that depend on dev labels. Not sure what the answer is offhand.

OK @conda-forge/cairo , there are several packages of interest to me that are blocking on the 1.15.x series of Cairo, so I would like to start packaging that series under a dev branch. Any concerns, etc?

Probably want to change the label they get uploaded to as well. As an example, please look at this commit.

Thanks for the pointer. The way to make that happen is to manually edit the various CI files?

Yeah that commit is less insightful than I would have hoped. Should only need to edit conda-forge.yml. Re-rendering will add it to the other CI files.

I have a branch that implements the desired changes, I think, and passes CI. Should I just push it to the feedstock repo?

Pulled the trigger.

Errr, it looks like conda-smithy is no longer handling the channels: targets: construction. The files generated in .ci_support still specify conda-forge main as the target after rerendering and, based on my reading of the current conda-smithy source, I have trouble seeing how the information in conda-forge.yaml would make it into those files. @scopatz?
And @conda-forge/core can someone please manually relabel the 1.15 Cairo packages on anaconda.org to the "dev" label? Thanks.

Ah, conda-smithy #886.

And @conda-forge/core can someone please manually relabel the 1.15 Cairo packages on anaconda.org to the "dev" label? Thanks.

Done.

Thanks @ocefpaf.


2018 Q4 OKRs Planning

Ref: https://github.com/ipfs/pm/issues/698

2018 Q3 Retrospective Document. Please complete this ASAP.
Previous OKR Planning for reference
2018 Q4 OKR Spreadsheet

@vasco-santos, @jacobheun et al, you know the drill :)

With the fairly short Q3 we had with all the great events in July, we have some OKRs that need to get carried over into Q4. Here's an outline of my thoughts for focus in Q4.
Q4 Objectives
Debug-ability and Stability
The State Machine updates for libp2p-switch and libp2p will be wrapping up soon. These updates will introduce some error standardization to libp2p, but the work needs to continue.
Standard Errors (from Q3)
Standardize connection errors and add them to the ipfs initiative, #1406
This must be done to make the implementation successful.
Implement in interface-connection modules
By leveraging standard errors for all modules implementing the connection interface, the libp2p-switch connection state machines will be better able to respond to the errors appropriately.
Fatal codes could terminate connections outright and not cause libp2p or switch to crash the node. Unstable connections could be reported up to libp2p and the connection manager to handle. The connection manager could make decisions on which connections to keep, and/or potentially add dialing backoffs for connections (network outage, a restarting peer, etc).
Network Visualization
Being able to visualize the network can also be a useful tool for finding issues with the network. As libp2p's Connectivity Magic gets better and better, it would also be really helpful for people to be able to see differences in the network with things like Delegated Routing, the DHT and Circuit Relay enabled/disabled. That could provide a much clearer understanding of the intent and use of these components.
Interop Testing (Global libp2p OKR)
Libp2p Daemon
In order for interoperability between the libp2p implementations to be easily updated by each team, we need to ensure that libp2p daemons exist for each of them. Initial work has started on the go daemon, and we need to get this going for js very soon.
Connectivity Magic
Complete DHT and IPNS work from Q3

DHT interop with GO
IPNS over Pubsub
IPNS over DHT

Formalize NAT Spec
Aside from running out of time for NAT Traversal work, the other blocker for getting this completed is formalizing the NAT Spec, https://github.com/libp2p/specs/pull/64, so that we can continue with the implementation of the NAT Manager. Completing the Spec will also help provide more guidance for any community members that might want to work on completing the implementation.
JS-IPFS Support for Delegated Routing
Refs support for the js-api
Right now, delegated routing is reliant on go-ipfs as js-ipfs doesn't currently support refs. It would be nice to see the refs implementation added to js-ipfs so we could get the API updated for Delegated Routing Support. This would enable users to better support their own ipfs infrastructures and rely less on the dht for browser/mobile nodes, and provide us with more opportunities to take load off the gateway nodes and distribute that throughout the network
Note: I have made some updates to the js-ipfs-api to support delegated routing. If refs support was added to js-ipfs, it would be a fairly low effort to finish the api support.

As we had several events and holidays during the last quarter, several OKRs from the previous quarter were not finished and I think they should be a priority for the next quarter.
IPNS in JS Land
The main implementation of IPNS is already released and the IPNS over Pubsub is ready for review. With the work done in IPNS over Pubsub, the IPNS over DHT will not need a big extra effort. However, it needs the DHT to be ready first.
Awesome DHT Endeavour
Since the DHT is a really important part of libp2p, I consider that we should get it ready to be enabled by default in IPFS. For this, we also need to guarantee the full interoperability with go. Accordingly, we should have an OKR to have a fully interoperable DHT enabled by default in js-ipfs.
Note: There is currently any example for using the DHT in GO nor JS, and we should provide it as well.
References:

js-ipfs#856
interop#36

Analyse and Improve DHT Performance
As stated before, DHT is a core concept of libp2p and after we get it enabled by default and fully interoperable with go, we should start analyzing its behavior and performance. Accordingly, I think that the next step should be to test it with a large network and scale it.
Daemon and Interoperability
I think that this should be one of the main focus of the next quarter. Go team already started their implementation and once they have their own daemon and we have ours, we should start the interop tests, which I consider crucial right now. As rust-libp2p is also on its way, we have to guarantee the same behavior accross all implementation to get libp2p a first class project.
References:

go-libp2p-daemon

Error handling
Providing a stable, reliable and performant libp2p is crucial for the developers' productivity, as well as to the community engagement. This way, I believe that this effort now will be important in the long run, since it will decrease considerably the time needed for diagnosing current and future problems.
Since the last quarter that we are having an effort to have error handling into a better consideration, but there is much to be done and we should refactor the errors sooner, at least for the most error prone modules.
Network visualization tool
This tool did not have any relevant progress last quarter, but it is an important aspect of debuggability for a complex network. We should have it as a OKR as well.

@mgoelzer in terms of exposing APIs to downstream users you are completely right!
After some thoughts, taking into consideration that go-libp2p is the reference implementation if we only have a daemon for it, we can test the interoperability from every single other implementation with it. For instance in IPFS land, it is possible to use an in proc node with js-ipfsd-ctl, without the need for a daemon. It is important pointing out that the programatic interface needs to be exactly the same, in order to be transparent in the interop tests which type of node we are dealing it.
However, if we intend to have a CLI for libp2p as well, daemons for both will ease the general "testing" interface, but will need a considerable higher time.

@mgoelzer we'll make sure to move these over the sheet. We like to discuss them openly in PRs as it's much easier than a spreadsheet and also improves visibility and opportunity to contribute for community members.
In regards to the daemon, our highest priority on the JS side of things is interop testing. As you mentioned, having daemons for each implementation makes things much easier and increases the likelihood that each working group go/js/rust, will contribute to them. The current interop tests for IPFS only really get used by the JS team, because it's all in JS.
The daemon would also make it much easier to spin up go/js/rust nodes via IPTB for better testing of simulated networks.
I agree that we should focus language bindings and exposed APIs to go-libp2p, as the reference implementation, to minimize support needs and focus enhancement efforts.

My 2 cents having landed in IPFS-land 2 years ago, but I'm going to be quite opiniative and probably controversial here:
I think that supporting more than one daemon is somewhat wasteful.
Do we have interface and interop tests because we need a js-ipfs daemon (I think we don't) or, as Jacob put, it's the other way around? I think this chicken-and-egg problem colapses over itself, leaving js-ipfs as a JS embedded API and remote client. I think these two should be the focal point of js-ipfs.
=> Less codebase to maintain and bundle.

@jacobheun Completely agree about better to discuss in Github issues.  My job is just to make sure that these items eventually get logged in a Google sheet, since this is how PL as an organization wants to track goal across all projects that it sponsors.  So, I believe we're in agreement here.
On the libp2p daemon stuff:

My initial perspective is that daemons in every language makes sense for testing (IPTB), but there should be some canonical daemon for external consumers (java bindings, python bindings, etc).
I didn't mean to say that the go libp2p daemon must be the canonical one, just that something should be canonical.  I could see a case for a Node.js daemon being canonical, or Rust for that matter.
I need to think a little more about @pgte 's comment.  Pedro, when I say "a daemon" in this thread, I mean a libp2p daemon, i.e., totally uncoupled from IPFS.  The reason I think we want this is because we have users who want to build on top of libp2p alone (like Ethereum 2.0 or Polkadot).  Apologies if I'm misunderstanding your comment.

With our ultimate goal being to reliably test and verify that different implementations of libp2p are able to intercommunicate, and properly support the same feature sets (private networks, dht, transports, crypto, etc), how do we efficiently and effectively create these test suites?
One option, which is being proposed, is to have the daemons for that. This would allow for an agnostic approach to testing.
go-libp2p has its own motivations for creating their daemon.
I am completely open to other options for interop tests between the libp2p implementations, but we need to have it. We want libp2p to be useable and useful to users on its own, and I think interop testing is an important part of that.
Are there other recommendations or ideas on how to approach this?

I've committed a first pass of the OKRs to the markdown file for review. I went ahead and added my thoughts on assignments as well, please feel free to recommend different assignments!

Mike, it would be great if you could take on a KR to augment the team, namely: Onboard 3 new contributors to the js-libp2p team

@diasdavid Yes, happy to own that one.

I will add that KR to this list @mgoelzer

Please try to provide any remaining feedback/questions/comments today. I will be moving this over to the Spreadsheet first thing tomorrow in preparation for our OKR meetings later this week.

All OKRs have been moved to the Q4 planning sheet.  OKRs will be locked on October 4th, if you have any feedback before then, please feel free to comment here or on the spreadsheet.

Let's make sure to give one last pass on the OKRs taking https://github.com/Agoric/PlaygroundVat/issues/8 into account. There are multiple things there that are already part of the plan but there are also others that should be quick wins (Ed25519 keys and TCP Hole punching) that we can incorporate.

I've added a few line items to the sheet for discussion:

the connection manager supports dial backoffs
Add support for TCP Hole Punching
Users can configure libp2p to use Ed25519 crypto keys instead of RSA

The biggest constraint right now is the availability @vasco-santos and I have. The crypto updates should be fairly quick, barring any surprises, so I think we could fit that in.
Hole Punching and connection manager updates will take a bit more effort, but are potentially accomplishable.

Yes! I think the Ed25519 integration seems easy to achieve.
The other two are not straightforward for me and I am not sure of the time I would need for them.

The biggest constraint right now is the availability @vasco-santos and I have

One of my KRs is to onboard more JS engineers this quarter.  So, help is on the way.  If we feel stuff like TCP hole punching is beyond what we can manage this quarter, let's push it to the backlog (by opening issues and leaving them in Waffle's backlog).  Worst thing we can do is just ignore or forget about Agoric's feedback, because it's really thoughtful and well-reasoned.

Just reposting this from line level comments for better visibility around completion assumptions.

As it stands, with our availability and the priority order, I think realistically the network visualization tool, nat traversal spec and error handling won't be completed. I think error handling will improve for code we'll be working in, but additional efforts to improve existing code will take a back seat. I think these are good for stretch goals though.


[BUG] Add-PnPTeamsTeam throwing Authentication Method is not allowed

Reporting an Issue or Missing Feature
I am using a certificate authentication method which is created using the Register-PnPAzureADApp with Connect-PnPOnline. When I try to user Add-PnPTeamsTeam with a modern team site is created using New-PnPSite -Type "TeamSite" -Title $siteTitle -Alias $groupAlias -IsPublic -Wait
I am getting Authentication method not allowed as shown
[DBG]: PS C:\Projects\DOF-M365Provisioning>  Add-PnPTeamsTeam
Add-PnPTeamsTeam: {"odata.error":{"code":"10005","message":{"lang":"en-US","value":"Authentication method is not allowed."}}}
Expected behavior
I am expecting the Add-PnpTeamsTeam cmdlet to complete.
Steps to reproduce behavior
Connect-PnPOnline -URL "https://$($tenantName)-admin.sharepoint.com" -ClientId $appRegistrationClientIdValue -Thumbprint $certThumbprintValue -Tenant $tenantIdValue
$tenantSite = New-PnPSite -Type "TeamSite" -Title $siteTitle -Alias $groupAlias -IsPublic -Wait
$tenantSiteUrl = $($tenantSite.Url)
Connect-PnPOnline -URL $tenantSiteUrl -ClientId $appRegistrationClientIdValue -Thumbprint $certThumbprintValue -Tenant $tenantIdValue
Add-PnPTeamsTeam
What is the version of the Cmdlet module you are running?
PnP.Powershell 1.4.0
Which operating system/environment are you running PnP PowerShell on?

[x] Windows
[ ] Linux
[ ] MacOS
[ ] Azure Cloud Shell
[ ] Azure Functions
[ ] Other : please specify

@prawnz - This is a known issue for app-only context.  You can use this command only with delegated permissions and user context due to limitations of SharePoint APIs.
If you wish you use app-only context, would suggest that you use
New-PnPMicrosoft365Group cmdlet and use -CreateTeam parameter. It does the same thing but uses Graph endpoints which support app-only scenarios.

@gautamdsheth all good.. will use your suggested method.

@gautamdsheth all good.. will use your suggested method.

When I try to use New-PnPMicrosoft365Group with the parameter -CreateTeam I get this error
Failed
Empty Payload. JSON content expected. (Empty Payload. JSON content expected.)

But the O365 group and teamsite is created correctly.
I use the command in an Azure RunBook with the PnP PowerShell Version 1.4.0.

uuh sorry, an update to 1.5.0 solves the problem

I am facing the same issue with PnP.PowerShell version 1.5.0
I have added all the details in this issue


Update test coverage in travis run to include all files and enforce minimum coverage of 80%

Interesting! I think we should give this a try and see how it goes.
+1.

Cool, let me know if you think 80% is too harsh - the idea is to make sure people add tests when they add new code :) If it does work well for everyone we can increase the minimum as our coverage goes up.

+1, this is great.

What level of test coverage are we at now?  Assuming we are at less than 80% -- which I venture that we are -- isn't this going to fail every TravisCI run until we get above 80%?

We should be at exactly 80% now when including all files - you can see in the details of the travis run on this PR.

Awesome, I'll merge.

On the Travis bot, my PR is getting an error that suggests not that my coverage is to low but that there's something wrong with our coverage configuration?
0.61s$ nosetests --with-coverage --cover-package ga4gh --cover-inclusive --cover-min-percentage 80
usage: nosetests [-h]
nosetests: error: unrecognized arguments: --with-coverage --cover-package ga4gh --cover-inclusive --cover-min-percentage 80
The command "nosetests --with-coverage --cover-package ga4gh --cover-inclusive --cover-min-percentage 80" exited with 2.

From https://travis-ci.org/ga4gh/server/builds/48106520#L453

Even though nosetests -h lists --cover-inclusive, if I include that in the locally command line it fails (with the same error message seen on Travis); if I remove it from the command line it succeeds.

Error messages cleared up (both locally and on the Travis server) once I'd merged with master. No problem here, I guess.


Why do we have code of the form:

if (isinstance(data,
np.ma.masked_array) and
ma.count_masked(data) == 0):
data = data.data
Is there some functional difference between an ndarray and a masked_array with no masked values?

It's my belief this is a mistaken approach.
This should be using "np.ma.is_masked()" instead.

Good point, but the intention of my question was to ask why we are bothering to unmask the array at all. If an ndarray and a masked_array with no mask are functionally equivalent, what's the point?

If an ndarray and a masked_array with no mask are functionally equivalent, what's the point?

I'm not totally sure, but I suspect there could be significant performance differences.
For instance, whenever you assign things into a masked array you need to be checking for np.ma.masked values.
It's quite possible that this is a negligible problem, but I think we should be careful.
Having said all that, I do think that it's awkward and irritating that when you subdivide a cube by indexing you can get some masked and some unmasked sub-cubes.
I think I'd like to consider changing that.
On a related matter: @marqh just found that there is a test that wrapping a masked array with no masked points produces a cube with a matching masked data array.
So I think that is evidence that is a previous definite design decision, not some coincidence.

i find this behaviour hard to justify in my mind
however, our testing is widely peppered with assumptions that this will take place
i would be happy to investigate further and gather some assessments of processing time and memory overhead
if we want to change this, we can; i'd just like a little caution, as this was done with explicit intent by Iris devlopers

Relates somewhat to #2046.
Closing this as obsolete.


Fixed invalid polish e-mail validation msg translation

Polish translation for „Enter valid email” was copied over from "Enter
a valid username.", producing confusing and incorrect error message
for validate_email validator.

Thanks for the report, but translations are handled at Transifex so this should be fixed there. See https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.


Move vendor deviation

Moving vendor deviation post subint configuration
"This code is a Contribution to the OpenConfig Feature Profiles project ("Work") made under the Google Software Grant and Corporate Contributor License Agreement ("CLA") and governed by the Apache License 2.0. No other rights or licenses in or to any of Nokia's intellectual property are granted for any other purpose. This code is provided on an "as is" basis without any warranties of any kind."


Migrating from 0.9.4 to latest version of objection.js cause models break

We are using objection.js version 0.9.4 in our TypeScript Backend Project. Now we want to upgrade it to latest to leverage new features. While moving to latest version, the biggest issue i face is that it doesn't allow non empty constructor.  It was allowed earlier.
Below is our demo model class which is using a parameterized constructor.
export class DemoModel extends Model {

    /**
     * The app consent table
     */
    public static tableName = 'tables';

    /**
     * Relationship of current model with others
     */
    public static relationMappings = {

    };

    public constructor(jsonObj: Partial<DemoTable>) {
        super();
        Object.assign(this, jsonObj);
    }
}

Now we need to keep empty constructor and we can use fromJson method to create model. But I have many models in project. And its leading to lots of changes. I am looking for quick workaround if there is any. Pls suggest

See the change log. There are a lot of breaking changes between 0.9.4 and the current version.


unit_holder(engine): periodically update status

Signed-off-by: lance6716<EMAIL_ADDRESS>
What problem does this PR solve?

Issue Number: ref  #5504
What is changed and how it works?
as title
Check List
Tests

Unit test

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
`None`.

Codecov Report

Merging #6187 (2986fb7) into master (ef587e6) will decrease coverage by 0.4257%.
The diff coverage is 71.5297%.

Flag
Coverage Δ

cdc
63.7827% <74.2796%> (-0.9019%)
:arrow_down:

dm
51.8571% <48.4127%> (-0.0321%)
:arrow_down:

engine
62.6686% <72.4928%> (+0.1347%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #6187        +/-   ##
================================================
- Coverage   58.4193%   57.9935%   -0.4258%
================================================
  Files           711        706         -5
  Lines         84205      83361       -844
================================================
- Hits          49192      48344       -848
- Misses        30540      30671       +131
+ Partials       4473       4346       -127

https://github.com/pingcap/tiflow/pull/6187/commits/61c2c65a80841028507472dedc024887613bb749
@GMHDBJD ptal

@GMHDBJD PTAL

@GMHDBJD PTAL

/merge

/run-leak-test


SCHISM changes

I have squashed all of these commits into one to encapsulate the changes made for SCHISM support, and will be deleting the feature/schism branch. If you want to do more SCHISM work, please make a new branch off of develop


Can you make this market maker to have option for long only or short only

The bot is good but it needs to have option for long only and short only depending on how the user wants it to be,

I figured it out


tgHillyTerrain is (still) compiler dependent

My integration test which observes how far a tetraspine robot travels on hills is giving different values on buildbot and my local machine. Tests on flat ground (spinesTest) are passing.
My computer: Dist travelled 5.19875
Buildbot: Dist travelled 5.37786
If you update to the latest version of master, can you post your values here (bin/build.sh -g)? Versions of g++ are also appreciated.

I have GCC 4.8.2 locally. Doing a build of the head now, and I'll let you know if I get conflicting values. If I do, I'll update locally to 4.8.4 and let you know if that resolves it.

I appear to be getting the same values as you did (5.19875) on my system with GCC 4.8.2.
gcc -v: https://gist.githubusercontent.com/PerryBhandal/0e66351f5a2770a1e0a4/raw/7aeb7016d710d734de5fec9e86dc5a731e141d89/gistfile1.txt
Output from build.sh -g: https://gist.githubusercontent.com/PerryBhandal/23e0bbf50c7d3fc32d0c/raw/3638aff6f588d3ec20641987f1e17739623c0497/gistfile1.txt
uname -a: Linux perry-laptop 4.0.4-040004-generic #201505171336 SMP Sun May 17 17:37:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Here's the info from the BB box:
root@ntrt:/# gcc -v; uname -a
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Linux ntrt 2.6.32-26-pve #1 SMP Mon Oct 14 08:22:20 CEST 2013 x86_64 x86_64 x86_64 GNU/Linux

A little more info after some digging: The old (sequential impulse) solver doesn't have this problem. I suspect upgrading to Bullet 2.83 might solve this issue.

Could we disable the problematic test in the meantime? We'll eventually want to sort the issue out, but in the meantime with the BuildBot flagging our builds as failing, we might overlook a new problem that arises in subsequent commits.

Perry - seems like a good idea, especially with all of the changes we
discussed last Tuesday.
On Sat, Sep 5, 2015 at 1:53 PM, Perry Bhandal<EMAIL_ADDRESS>wrote:

Could we disable the problematic test in the meantime? We'll eventually
want to sort the issue out, but in the meantime with the BuildBot flagging
our builds as failing, we might overlook a new problem that arises in
subsequent commits.
—
Reply to this email directly or view it on GitHub
https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/163#issuecomment-137994191
.

HillsTest has been disabled, and BuildBot has returned to a passing state.
Thanks Brian.


Use primary-color instead of label color when focused for material theme

Why
Requested by Stitch.
Slack thread
How
Use primary color for label when the input is focused.

This wont need a new version release though right? Because it's just styling updates on the hosted inputs.

Technically this will effect people already using the material theme, however, this is the approach that @nevflynn wanted to take rather than introducing further config variables which I think makes sense.


Automated cherry pick of #5689: Use Traceflow API v1beta1

Cherry pick of #5689 on release-1.14.
#5689: Use Traceflow API v1beta1
For details on the cherry pick process, see the cherry pick requests page.

/test-all


Get-IntuneWin32AppAssignment (v.1.4.3) missing usefull data from result, which was available in 1.4.1

Hi,
When I am using the Get-IntuneWin32AppAssignment -ID the result is missing very useful data, like ID, groupid, and<EMAIL_ADDRESS>Based on the new result I cannot replicate the assignment in a different application.
new result:
Type                         : #microsoft.graph.groupAssignmentTarget
AppName                      : test1234
FilterID                     :
FilterType                   : none
Intent                       : required
GroupMode                    :
DeliveryOptimizationPriority : notConfigured
Notifications                : hideAll
RestartSettings              :
InstallTimeSettings          : @{useLocalTime=False;
startDateTime=2024-02-26T14:08:40Z;
deadlineDateTime=2024-02-26T14:08:40Z}
Old Result
id       : 0572d602-8962-432b-aa93-61b27f743303_1_0
intent   : required
source   : direct
sourceId :
target<EMAIL_ADDRESS>deviceAndAppManagementAssignmentFilterId=;
deviceAndAppManagementAssignmentFilterType=none;
groupId=0572d602-8962-432b-aa93-61b27f743303}
settings<EMAIL_ADDRESS>notifications=hideAll; restartSettings=;
deliveryOptimizationPriority=notConfigured; autoUpdateSettings=;
installTimeSettings=}
Thanks for looking into this!

This should be fixed with 1.4.4 that I just committed to the repo. I'm going through the most recent issues here to see if there's something that I should attend to before release it on PowerShellGallery. So if you want to try, grab the latest function files and replace it with what you have installed locally in the modules folder, to see if it works better now.

1.4.4 is out now, please verify if the issue still persist. Reopen the issue if there's still a problem :)


Using useSupabaseClient inside a composable then used in plugin is breaking

I'm trying to load some user roles and permission data when the Nuxt page first loads. I'm doing this in a roles.ts plugin.
import { useUserRoles } from "~/composables/resources/useUserRoles";
import { useSupabaseUser } from "#imports";
import type { Tables } from "~/types/supabase";

export default defineNuxtPlugin(async () => {
  const user = useSupabaseUser();
  const { load, loadRolePermissions } = useUserRoles();

  const rolesState = useState<Tables<"user_roles"> | null>("user-role", () => null);
  const rolePermissionsState = useState<Tables<"role_permissions">[] | null>("user-role-permissions", () => null);

  async function loadRoleData () {
    if (user.value) {
      const role = await load();

      if (role.value) {
        if (role.value.error) {
          if (role.value.error.code === "PGRST116") {
            throw createError({
              message: "User does not have a role defined",
              statusMessage: "Missing user role"
            });
          } else {
            throw createError({
              message: "Unable to load role for user: " + role.value.error.message
            });
          }
        }

        if (role.value.data) {
          rolesState.value = role.value.data;
        } else {
          console.warn("No roles found");
        }
      } else {
        console.warn("Could not load roles for user: " + user.value.id);
      }
    }
  }

  async function loadPermissions (role: string) {
    const permissions = await loadRolePermissions(role);

    if (permissions.value) {
      if (permissions.value.error) {
        if (permissions.value.error.code !== "PGRST116") {
          throw createError({
            message: "Unable to load permissions for role: " + permissions.value.error.message,
            statusMessage: "Missing permissions"
          });
        } else {
          console.warn("Role does not have permissions defined");
        }

        return null;
      }

      rolePermissionsState.value = permissions.value.data;
    } else {
      console.warn("Could not load permissions for role: " + role);
    }
  }

  async function loadData () {
    await loadRoleData();
    if (rolesState.value?.role) {
      await loadPermissions(rolesState.value.role);
    } else {
      console.warn("Could not load permissions without a role");
    }
  }

  watch(user, async (val) => {
    if (val) {
      await loadData();
    } else {
      rolesState.value = null;
      rolePermissionsState.value = null;
    }
  });

  await loadData();
});

This plugin has been using the following composable:
import type { Database } from "~/types/supabase";

export function useUserRoles () {
  const client = useSupabaseClient<Database>();
  const user = useSupabaseUser();

  async function load () {
    const { data } = await useAsyncData("user-role", async () => {
      if (user.value) {
        const { data, error } = await client
          .from("user_roles")
          .select("*")
          .eq("user_id", user.value.id)
          .single();

        return { data, error };
      }

      return null;
    });

    return data;
  }

  async function loadRolePermissions (role: string) {
    const { data } = await useAsyncData("user-role-permissions", async () => {
      const { data, error } = await client
        .from("role_permissions")
        .select("*")
        .eq("role", role);

      return { data, error };
    });

    return data;
  }

  return {
    load,
    loadRolePermissions
  };
}

I originally started by just making a call to load data from the user-role table. This was working fine. I would refresh the page and the data would be loaded on the server and included in the __NUXT_DATA__ payload.
However, when I added a second call to load permission data from a different table, the page would return a 500 error A composable that requires access to the Nuxt instance was called outside of a plugin, Nuxt hook, Nuxt middleware, or Vue setup function.
I'm a bit confused as to why the plugin breaks when I include the second load call. The code above will work if you comment out the await loadPermissions(rolesState.value.role); line in the loadData function of the plugin.

I'm not sure about this one but I feel that it might be caused because of this... as you call it, you await loadPermissions which awaits loadRolePermissions and that one is only inside of the composable.

Hi @matt-clegg
Try to not use useAsyncData in your plugins, this composable should be used only inside Pages or components.
As you are using useState, you can leverage this to know if the store has been filed during SSR for hydration.

Thanks for the reply @Atinux, useAsyncData was the culprit, thanks!


StateBasedEndorsement Policy is missing the nOutOf..

With the change to the new protobuf libraries, and it's different API, the nOutOf was missed from statebased KeyEndorsementPolicy

for PR see #377

Fixed in Release 2.5.2


fix: Some attestations are downloaded twice via the "getAllAttestations" script

What does this PR do?
Related ticket
Fixes #572
Type of change

[ ] Chore
[X] Bug fix
[ ] New feature
[ ] Documentation update

Check list

[ ] Unit tests for any smart contract change
[ ] Contracts and functions are documented

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

Project coverage is 93.63%. Comparing base (8502ea4) to head (58fb150).

Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #573   +/-   ##
=======================================
  Coverage   93.63%   93.63%
=======================================
  Files          20       20
  Lines         330      330
  Branches       76       76
=======================================
  Hits          309      309
  Misses         10       10
  Partials       11       11

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


Add test creating two content filter topics with the same topic name

This PR adds the proper test in rclcpp that checks for a successful creation of two content filter topics for the same topic name.

Related PR https://github.com/eProsima/rmw_fastrtps/pull/29

Closed in favor of https://github.com/ros2/rclcpp/pull/2546


Failures on Support digit separators

There are new test failures on Support digit separators.
The tests
coverage/package:front_end/src/source/source_compilation_unit.dart Fail (expected Pass)

are failing on configurations
cfe-unittest-asserts-release-linux

// @srawlins

Thanks, @a-siva . Is there a way to see these failures?

I found a log: https://dart-ci.appspot.com/log/front-end-linux-release-x64/cfe-unittest-asserts-release-linux/26061/coverage/package:front_end/src/source/source_compilation_unit.dart


Unregister a specific Notification Handler

Related to #46

LGTM! @vandewilly I added the -race flag to the go test in #49
Could you please make sure to use the new handlersMutex to protect access to the handlers...
If you make that small change, I think we can get this merged 🎉
Thanks for your contribution

Good catch, @dave-tucker ! Please, take a look on the new patch set.

Thanks for the contribution @vandewilly 🌟


test: Migrate CI to GitHub Actions [SDK-4452]

By submitting a PR to this repository, you agree to the terms within the Auth0 Code of Conduct. Please see the contributing guidelines for how to create and submit a high-quality PR for this repo.
Description
This pull request replaces our current CircleCI continuous integration suite for auth0-react with a new workflow using GitHub Actions.
References
Please see internal ticket SDK-4452.
Testing
This pull request replaces our continuous integration suite with one built in GitHub's native Actions ecosystem. It aligns with other migrations taking place across our repositories.
Checklist

[x] I have added documentation for new/changed functionality in this PR or in auth0.com/docs
[x] All active GitHub checks for tests, formatting, and security are passing
[x] The correct base branch is being used, if not the default branch

@adamjmcgrath I've updated the publish step to only reference the express-oauth2-jwt-bearer path.

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:

@frederikprijck Updated, thanks.


ENH: Add check to ensure latest fsaverage folder is used

Closes #2832
This sets a minimum_fs_version to ensure an FS7 recon-all compatible fsaverage is available.
Also bumps nipreps dependencies to the latest compatible versions.

Does this fix replace fsaverage dirs with the newest version or just warn when they aren't present?

I think just warn.

Nope, the fix will clear the old dirs and copy them again
https://github.com/nipreps/niworkflows/pull/739

Cool, thanks!


How do I change to default a Schematic file

Hi, I opened a schematic file with my note pad, and now when I try to put the file into my server files it doest recognizes it, and all the schematics I download are notepad files now, how do i make them schematic files again!!! pls help

You have to change the ending of the file to .schematic


TypeError: hashconnect.authenticate is not a function

following readme page to test authenticate
const resp = await hashconnect.authenticate(topic, accountId)
TypeError: hashconnect.authenticate is not a function
How to access authenticate method from
const { HashConnect } = require("hashconnect")

We have recently released an update for authenticate(), please try again
https://github.com/Hashpack/hashconnect#authenticate


dns/bind: Do not add the update-policy if the zone type is secondary

I have a bunch of secondary configured in the BIND Plugin. If I make a change through the web interface, the named.conf file at /usr/local/etc/namedb/named.conf will be regenerated from the /usr/local/opnsense/service/templates/OPNsense/Bind/named.conf template.
/usr/local/bin/named does not allow updates on the secondary zone as they should be done to the primary zone. Hence named throws an error:
/usr/local/etc/namedb/named.conf:93: option 'update-policy' is not allowed in 'secondary' zone 'xx.xx.xx.in-addr.arpa'
In the secondary zone configuration block, 'update-policy' seems not to be allowed - this is a snippet from the generated name.conf file:
zone "xx.xx.xx.in-addr.arpa" {
        type secondary;
        primaries { yy.yy.yy.yy key "key.dyn.zz.zz.zz"; };
        file "/usr/local/etc/namedb/secondary/xx.xx.xx.in-addr.arpa.db";
        allow-transfer {
                ns_notify;
        };
        allow-query {
                ns_query;
        };
        update-policy {
                grant rndc-key zonesub ANY;
        };
};

Here is the patch that fixes it:
Y@Z:/usr/local/opnsense/service/templates/OPNsense/Bind % diff named.conf.org named.conf
183c183
< {%      if domain.allowrndcupdate is defined and domain.allowrndcupdate == "1" %}
---
> {%      if domain.allowrndcupdate is defined and domain.allowrndcupdate == "1" and domain.type != 'secondary' %}

CC @jriberg

LGTM

Merged, thanks!

Thx :)


ELECTRON-600 (Implement Native Encryption for AESGCMEncrypt & AESGCMDecrypt)

Description
Implement Native Encryption for AESGCMEncrypt & AESGCMDecrypt ELECTRON-600
Related PRs
List related PRs against other branches/repositories:

branch
PR

SFE-Packages
link

SFE-Client-App
link

QA Checklist

[X] Unit-Tests
ELECTRON-600 — Unit Tests.pdf

[X] Automation-Tests
ELECTRON-600 — Spectron.pdf

@KiranNiranjan can you look at the conflicts please?


How to attach a file from the file system?

I would like to be able to attach a zip file as an attachment, but cannot see an example of how to do this.

I see I can just read the file into a Data object.
Closing..


Add better argument validation

Now, the input and output paths are validated by argparse, not our main method.


Document new cpu_reserve_full_mhz vSphere feature

Implementation PR: https://github.com/cloudfoundry/bosh-vsphere-cpi-release/pull/384

This is waiting for the CPI release to add the version


Add in ability to turn off introspection

We heavily restrict places the extension can be called but it would be great to turn of introspection on production.

closed in #13


[AL0122][AL0133] Cannot convert from DotNet

Based on Business Central Wave 2 (BC15) we are creating an OnPremises solution which uses an external DotNet functionality (for Barcodes). Until now without problems.
Newer AL compiler (sandbox & BC16) showed errors, which now also occurs with Cumulative Update 1.
Business Central Plattform 37769, Application 37793 (BC15, CU1)
Microsoft (R) AL Compiler version <IP_ADDRESS>932 (al-4.0.194000.vsix)
We add the external DotNet and Standard DotNet (System.Drawing) in dotnet.al:
dotnet
{
    assembly("TECIT.TBarCode")
    {
        ...
        type("TECIT.TBarCode.Barcode"; "Barcode")
        {
        }
     ...
    assembly("System.Drawing")
    {
        Version = '<IP_ADDRESS>';
        Culture = 'neutral';
        PublicKeyToken = 'b03f5f7f11d50a3a';

        type("System.Drawing.Rectangle"; "Rectangle")
        {
        }

        type("System.Drawing.Bitmap"; "Bitmap")
        {
        }
       ...
      }

If we now try to assign the DotNet values by:
local procedure ConvertTBarCodeToBase64Bmp(TBarCode: DotNet Barcode): Text;
var
    Bitmap: Dotnet Bitmap;
begin
    Bitmap := TBarCode.DrawBitmap();

this results in an error:
Cannot implicitly convert type 'DotNet "System.Drawing.Bitmap"' to 'DotNet "System.Drawing.Bitmap"' (AL0122)
and:
    local procedure SetBoundingRectangle(TBarCode: DotNet Barcode; width: Integer; height: Integer)
    var
        Rect: DotNet Rectangle;
    begin
        TBarCode.BoundingRectangle := Rect.Rectangle(0, 0, width, height);
    end;

which results in another error:
Argument 1: cannot convert from 'DotNet "System.Drawing.Rectangle"' to 'DotNet "System.Drawing.Rectangle"' (AL0133)
Quite important to mention:
those errors only show up in Visual Studio Code (starting with BC15, CU1).
We create our apps by PowerShell directly with alc.exe (<IP_ADDRESS>932) without an error message.

Are you seeing this error for other types?

We are only using one external DotNet and there are only those two assignments between a system library and this external function.

Hi @ralf-escher! Thanks for reporting this issue, I'm looking into it. It would be of great help if you could provide a ZIP file with a small repro here. If this is not possible, you can also reach out to me personally on<EMAIL_ADDRESS>if you don't want to discuss in public. Thanks!

@JohanStenberg100 : thanks to your advice to build a repo for this issue, we experienced that it wasn't that easy. Means: we had no errors at the beginning.
After using our .vscode/settings.json we found out, that the problem was the usage of the System.Drawing library.
To add the "System.Drawing" assembly we did extend the al.assemblyProbingPaths by C:/Windows/assembly. Upgrading to runtime 4.1 this leads to the described errors.
Since we did add the System.Drawing.dll to the .netpackages folder (so we could compile within a docker container) this probing path (C:/Windows/assembly) is no longer necessary which solves our problems.
I would prefer the extend the probing path. But that didn't worked with the container.

Hi @ralf-escher ! The NST automatically searches the following paths: the Add-Ins folder, the server's bin folder, the global assembly cache(GAC) (C:/Windows/assembly on most machines) . As far as I understand, this assembly is in the GAC, so you should not need to extend the probing paths in the container.
Is my understanding correct that this issue has been resolved for you?

We are somehow confused.
If I remove C:/Windows/assembly from the probing path and the System.Drawing.dll from the .netpackages folder then we get errors that those DotNet elements from System.Drawing couldn't be found (AL0185).
If I add the  C:/Windows/assembly to the probing path it can find the System Drawing DotNet elements but then shows that convert from DotNet error again (AL0122,AL0133).
Therefore I need to add the System.Drawing.dll to the .netpackages folder or do any other solutions exists?

Hi again @ralf-escher, we suspect there's an issue when using multiple different versions of a DLL with the same name.

Your first option will not work, since then you simply don't have the DLL.
Your second option will probe and likely find a version of your DLL which is not the same version as the one your barcode solution uses.
If you add the DLL manually, I suspect you pick the correct version and then you don't experience the issue.

You could compare the version of what you are putting into the .netpackages folder and what you can find in your GAC (C:/Windows/assembly), do you see a difference?

I did switch the apperance of C:/Windows/assembly to work like a normal folder to extract the System.Drawing.dll [Stackoverflow]. Therefore it is the same version.
Since you agree to the third option we are happy for the moment. ☺
(maybe there will be native support for 2D barcodes? :wink:)

Good that you were able to unblock yourself! We will still take an extra look on this to make sure you can reliably use the GAC in the future.
Regarding native support for barcodes you can try our ideas forum :).
Thanks again, I'll close this issue now.


Tried dash2.5，seem like only one page can be registered

Hi @sylvoslee
Converting from a the dash-labs pages plug-in to the pages feature in dash 2.5 requires 3 steps:

remove import dash_labs as dl  or upgrade dash-labs to V1.1.0
There is a conflict between dash-labs versions less than 1.1.0 when running a pages app in dash 2.5

change:
app = Dash(__name__, plugins=[dl.plugins.pages])
to:
app = Dash(__name__, use_pages=True)

change:
dl.plugins.page_container
to:
dash.page_container

Let me know how it goes!  The new dash docs with the pages feature will be ready soon.

Hi @sylvoslee.  Thanks for reporting.  There is an issue with pages in dash 2.5 for for anyone on Windows.  There is a pull request to fix this - patch is coming soon.

@sylvoslee dash 2.5.1 has been released :confetti_ball:

another question, how to get the hash value of the url

You can use the  hash prop of dcc.Location

Why can't  pass hash value to layout function like query?
def layout(day=days[0], **other_unknown_query_strings):
    return html.Div(
        [
            dcc.Dropdown(
                id="dropdown",
                options=[{"label": x, "value": x} for x in days],
                value=day,
                clearable=False,
            ),
            dcc.Graph(id="bar-chart"),
        ]
    )


Regenerate Lua bindings when needed

Obidog should generate a hash of the generated bindings, GitHub Actions will then compare the current hash with the previous one (stored somewhere in the repository ?). If the hash is different, GitHub Actions will replace the bindings with the newly generated ones and clang-format them. It will then create a pull request to merge the new bindings (and also update the documentation).

Duplicate of #404


change: use regional endpoint for STS in builds

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

CodeBuild passed: https://us-west-2.console.aws.amazon.com/codesuite/codebuild/projects/sagemaker-mxnet-serving-container-pr/build/sagemaker-mxnet-serving-container-pr%3A71450fb5-92ef-47e6-b714-ae91406a86af/log?region=us-west-2
(will separately investigate CB not reporting back)


Remove repeated information in same sentence

Minor edit to setuptools docs on PEP 517
Summary of changes
Removed a repeated part of the sentence in the setuptools docs. Does not touch any code.

Thanks for noticing and caring enough to send a PR.


ResonanceMolSupplier potentially stuck in infinite loop

Description:

RDKit Version: 2019.03.2
Platform: Ubuntu 18.04

ResonanceMolSupplier takes an extremely long time (or possibly is stuck in an infinite loop) when trying to process the Mol object with SMILES string
ClC1=NC(NC2=CC=CC3=C2C(=O)C2=CC=CC=C2C3=O)=NC(NC2=CC=CC3=C2C(=O)C2=CC=CC=C2C3=O)=N1

from rdkit.Chem import MolFromSmiles
from rdkit.Chem.rdchem import ResonanceMolSupplier

m = MolFromSmiles(insert_smiles_string_here)
sup = ResonanceMolSupplier(m)
next(sup)

I'm going to label this as a bug, there should be some max number of resonance structures to prevent this behavior.  This might take some time to resolve, however.

Here is a more detailed reason why I consider this a bug:
>>> insert_smiles_string_here="ClC1=NC(NC2=CC=CC3=C2C(=O)C2=CC=CC=C2C3=O)=NC(NC2=CC=CC3=C2C(=O)C2=CC=CC=C2C3=O)=N1"
>>> m = MolFromSmiles(insert_smiles_string_here)
>>> sup = ResonanceMolSupplier(m)
>>> for i,m in enumerate(sup):
...   print(Chem.MolToSmiles(m))

This code hangs in that the user can't terminate after, say, 1000 structures are generated.

it's true that a limit can be useful to avoid infinite loops

@ptosco : I just noticed that this is still here and seems to still be a problem.
I just tried @tawe141's sample molecule like this and got a hang:
In [2]: m = Chem.MolFromSmiles('ClC1=NC(NC2=CC=CC3=C2C(=O)C2=CC=CC=C2C3=O)=NC(NC2=CC=CC3=C2C(=O)C2=CC=CC=C2C3=O)=N1')

In [3]: suppl = Chem.ResonanceMolSupplier(m,maxStructs=10)

In [4]: next(suppl)

Trying with the SMILES O=C(Nc1ccc(Nc2ccc(NC(=O)c3ccccc3)c4C(=O)c5ccccc5C(=O)c24)c6C(=O)c7ccccc7C(=O)c16)c8ccccc8 leads to similar behavior (though there the memory used grows for quite a while).
Is this something you'd be able to look at?

@greglandrum Yes, I'll try and take a look over the weekend.

maybe also a memory leak somewhere ?


[Feature] Progress Bar widget

Summary
Users need a widget to display the progress of a long-running task

This is already an issue in #2519

@areyabhishek I need to reopen this because it's an individual piece of work. So estimating and prioritizing needs to happen on this task while referencing details from there. Ideally, we should keep issues related to a single piece of work

@Nikhil-Nandagopal is this or this an apt example for this?

@somangshu yes they are

@techbhavin here is the Figma link for progress bar widget https://www.figma.com/file/mxIUUL3LM363xWInQnhjDW/New-Widgets-Exploration?node-id=44%3A3054

Feature requirements
Using the progress bar Appsmith developers should be able to:

Set the progress bar to be indeterminate in progress, signifies that some process is running, whose progress cannot be determined.
Set the value dynamically by binding a "progress" property
Set the fill colour of the progress bar.
Set the label to be visible or invisible, depending on whether they want a textual value displayed for the progress.

Other details

Value should be in percentage. Hence, it should be validated to have a number value between 0 and 100.

The progress bar is for display purposes only, as a result it may not have any action triggers at the moment. This is open for discussion if we have a valid use-case.


Client validation error when server generating  token

System Info
text-generation-inference version: v0.8.2
text-generation version (python client): 0.6.0
gpu: nvidia A100 40G
text-generation-launcher env:
> text-generation-launcher --env
2023-06-12T09:13:08.093676Z  INFO text_generation_launcher: Runtime environment:
Target: x86_64-unknown-linux-gnu
Cargo version: 1.69.0
Commit sha: 5fde8d99919f3c81e1fd414aa11d2148680baea6
Docker label: sha-5fde8d9
nvidia-smi:
Mon Jun 12 09:13:07 2023
   +---------------------------------------------------------------------------------------+
   | NVIDIA-SMI 530.30.02              Driver Version: 530.30.02    CUDA Version: 12.1     |
   |-----------------------------------------+----------------------+----------------------+
   | GPU  Name                  Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
   | Fan  Temp  Perf            Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
   |                                         |                      |               MIG M. |
   |=========================================+======================+======================|
   |   0  NVIDIA A100-PCIE-40GB           Off| 00000000:00:06.0 Off |                    0 |
   | N/A   26C    P0               38W / 250W|  18937MiB / 40960MiB |      0%      Default |
   |                                         |                      |             Disabled |
   +-----------------------------------------+----------------------+----------------------+

   +---------------------------------------------------------------------------------------+
   | Processes:                                                                            |
   |  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
   |        ID   ID                                                             Usage      |
   |=======================================================================================|
   +---------------------------------------------------------------------------------------+
2023-06-12T09:13:08.093834Z  INFO text_generation_launcher: Args { model_id: "bigscience/bloom-560m", revision: None, sharded: None, num_shard: None, quantize: None, trust_remote_code: false, max_concurrent_requests: 128, max_best_of: 2, max_stop_sequences: 4, max_input_length: 1000, max_total_tokens: 1512, max_batch_size: None, waiting_served_ratio: 1.2, max_batch_total_tokens: 32000, max_waiting_tokens: 20, port: 8080, shard_uds_path: "/tmp/text-generation-server", master_addr: "localhost", master_port: 29500, huggingface_hub_cache: Some("/data"), weights_cache_override: None, disable_custom_kernels: false, json_output: false, otlp_endpoint: None, cors_allow_origin: [], watermark_gamma: None, watermark_delta: None, env: true }

(The last line of text_generation_launcher: Args seems not correct, we run text-generation-inference in a kubernetes pod and pass args through containers.args)
The real args can be found in the info endpoint:
{
	"model_id": "/data",
	"model_sha": null,
	"model_dtype": "torch.float16",
	"model_device_type": "cuda",
	"model_pipeline_tag": null,
	"max_concurrent_requests": 128,
	"max_best_of": 2,
	"max_stop_sequences": 4,
	"max_input_length": 1000,
	"max_total_tokens": 2048,
	"waiting_served_ratio": 1.2,
	"max_batch_total_tokens": 32000,
	"max_waiting_tokens": 20,
	"validation_workers": 2,
	"version": "0.8.2",
	"sha": "19c41824cb11ba1a3b60a2a65274d8c074383de3",
	"docker_label": "sha-19c4182"
}

Information

[X] Docker
[ ] The CLI directly

Tasks

[x] An officially supported command
[ ] My own modifications

Reproduction
When the text-generation-inference service generate a <unk> token (which does not have a 'logprob' and I don't know why), The text-generation python client will raise a validation error.
...
  File "d:\workspace\myproj\venv\Lib\site-packages\text_generation\client.py", line 150, in generate
    return Response(**payload[0])
           ^^^^^^^^^^^^^^^^^^^^^^
  File "pydantic\main.py", line 341, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 1000 validation errors for Response
details -> tokens -> 0 -> logprob
  none is not an allowed value (type=type_error.none.not_allowed)
...

The corresponding code lay in text_generation/types.py:
# Generated tokens
class Token(BaseModel):
    # Token ID from the model tokenizer
    id: int
    # Token text
    text: str
    # Logprob
    logprob: float # <-- this field
    # Is the token a special token
    # Can be used to ignore tokens when concatenating
    special: bool

# `generate` details
class Details(BaseModel):
    # Generation finish reason
    finish_reason: FinishReason
    # Number of generated tokens
    generated_tokens: int
    # Sampling seed if sampling was activated
    seed: Optional[int]
    # Decoder input tokens, empty if decoder_input_details is False
    prefill: List[InputToken]
    # Generated tokens
    tokens: List[Token]
    # Additional sequences when using the `best_of` parameter
    best_of_sequences: Optional[List[BestOfSequence]]

# `generate` return value
class Response(BaseModel):
    # Generated text
    generated_text: str
    # Generation details
    details: Details

Expected behavior
This error occurs during deserialization of the Response object.
As the response code is 200, I suppose the client should not raise an error?
Maybe we should make 'logprob' optional?

The last line of text_generation_launcher: Args seems not correct

What do you mean?
The logprob should always have a value. If it does not something is going wrong, hence the validation error. I will investigate a bit on my side.

We are passing some configuration through command line args, for example --max-input-length 1000 --max-total-tokens 2048, which is reflected in the $BASE_URL/info endpoint, but not in the text-generation-launcher --env command.
After some thinking I think it is the correct behavior as the text-generation-launcher --env command reflects the environment not the running process. Sorry for my misleading description.

It seems that this happends when using a very low temperature.
For example, when using temperature 10e-3, The server will respond correctly.
> curl -X POST -H "content-type: application/json" -d '{"inputs": "The sky is blue because", "parameters": {"temperature": 0.001, "max_new_tokens":20}}' "http://localhost:8080/generate"
{"generated_text":" the Earth's atmosphere scatters sunlight in all directions. The scattering is caused by the molecules and particles in"}

However, if I change the temperature to 10e-4, the server will respond empty.
> curl -X POST -H "content-type: application/json" -d '{"inputs": "The sky is blue because", "parameters": {"temperature": 0.0001, "max_new_tokens":20}}' "http://localhost:8080/generate"
{"generated_text":""}

If you set a temperature of 10e-4, why not simply use greedy decoding?

I'm new on text generation tasks but I want to lower the "creativity" of the model and stick to stable outputs, and according to my limited knowledge I should set a low temperature (when using openai I can set the temperature to 0).
But the issue is not about that, it is text-generation-server generates none logprob while the python client of text-generation does not allow that.

I'm new on text generation tasks but I want to lower the "creativity" of the model and stick to stable outputs

You should not use any temperature then and stick to greedy decoding.

But the issue is not about that

The issue seems to be about that. If you push the temperature too low, it will cause float overflow and result in nan logprobs.

Thank you for the advice, I will try greedy encoding.
For this issue, I mean if nan logprobs means something goes wrong, maybe we can return http status 400 or something from the server side, with an error message if possible, instead of 200. What do you think?


Header and child item could clicked together

I have a problem when I want to click on the header, the child item go to click as well. It occurs when a child there were behind header

at that picture when i want to just click the Header "A", the child on behind the header go to click as well

It works in the sample - please compare your implementation to the sample or link to a fork that demonstrates the behavior.

okay i already recheck my code, and i place wrong code in my project.
But I got other bug, so I made little change on RecyclerItemClickListener mGestureDetector
    public RecyclerItemClickListener(Context context, OnItemClickListener listener) {
        mListener = listener;
        mGestureDetector = new GestureDetector(context, new GestureDetector.SimpleOnGestureListener() {
            @Override
            public boolean onDown(MotionEvent e) {
                Log.i("TAG","onDown");
                return super.onDown(e);
            }

            @Override
            public void onShowPress(MotionEvent e) {
                Log.i("TAG","onShowPress");
                super.onShowPress(e);
            }

            @Override public boolean onSingleTapUp(MotionEvent e) {
                Log.i("TAG","onSingleTapUp");
                return true;
            }

            @Override
            public void onLongPress(MotionEvent e) {
                Log.i("TAG","onLongPress");
                super.onLongPress(e);
            }

            @Override
            public boolean onSingleTapConfirmed(MotionEvent e) {
                Log.i("TAG","onSingleTapConfirmed");
                return super.onSingleTapConfirmed(e);
            }
        });
    }

and when i click on sticky header, i got :
07-03 00:01:37.063  25983-25983/com.example.frankywijanarko.myapplication I/TAG﹕ onDown
07-03 00:01:37.243  25983-25983/com.example.frankywijanarko.myapplication I/TAG﹕ onShowPress
07-03 00:01:37.747  25983-25983/com.example.frankywijanarko.myapplication I/TAG﹕ onLongPress

And when i click on the child, i got :
07-03 00:09:14.159  25983-25983/com.example.frankywijanarko.myapplication I/TAG﹕ onDown
07-03 00:09:14.231  25983-25983/com.example.frankywijanarko.myapplication I/TAG﹕ onSingleTapUp
07-03 00:09:14.459  25983-25983/com.example.frankywijanarko.myapplication I/TAG﹕ onSingleTapConfirmed

how to prevent long press on sticky header??

i already got solution for this


ReferenceError: SchemaObject is not defined

Hello!
I was trying to find unknown features, and got this as result:
/Users/liyushen/Documents/code/lottie-docs/docs/scripts/lottie_explain.js:1576
    module.exports = { SchemaData, SchemaObject };
                                   ^
ReferenceError: SchemaObject is not defined
    at Object.<anonymous> (/Users/liyushen/Documents/code/lottie-docs/docs/scripts/lottie_explain.js:1576:36)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Module._load (node:internal/modules/cjs/loader:922:12)
    at Module.require (node:internal/modules/cjs/loader:1105:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (/Users/liyushen/Documents/code/lottie-docs/tools/unknown_features.js:4:15)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)

Node.js v19.3.0

And my python virtual environment seems fine:

It seems like there is no SchemaObject in lottie_examplain.js. I wonder which part did I do is wrong and how to fix this?

It used to be a class but got removed, I'm going to clean it up


Test caching mechanisms in Harbor

Can we reconfigure some pods to pull from harbor which acts as a cache?
Can we cache OCI artifacts (such as helm charts)?
How is caching configured on harbor? Is it possible to automatically apply configuration to many harbor instances?

[ ] Can we reconfigure some pods to pull from harbor which acts as a cache?
Yes, tested for both public and private harbor cache projects

[ ] Can we cache OCI artifacts (such as helm charts)?
Yes, pulled from Azure public ACR

[ ]  How is caching configured on harbor? Is it possible to automatically apply configuration to many harbor instances?
TBD


Padding and windowing

Can someone briefly explain how they have implemented padding and windowing?

I added points of data equal to 0 until it reached a number of 2^n points of data. Then used a hanning window (asked Bard for little help).


roles/network_resolved: do not disable systemd-resolved

The systemd-resolved service is required by libvirt. The service will works even if no DNS server is defined.

can you please detail the problem? or do you have a link to the bug?

can you please detail the problem? or do you have a link to the bug?

Libvirt can manage VMs network and use dnsmasq to setup a DHCP server for VMs.
This dnsmasq fails if there is no /etc/resolv.conf file.
Dec 11 10:16:50 adv-ecu-579 dnsmasq[1136]: directory /etc/resolv.conf for resolv-file is missing, cannot poll
Dec 11 10:16:50 adv-ecu-579 dnsmasq[1136]: FAILED to start up
Dec 11 10:16:50 adv-ecu-579 libvirtd[1038]: internal error: Child process (VIR_BRIDGE_NAME=virbr0 /usr/bin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/lib>
                                            dnsmasq: directory /etc/resolv.conf for resolv-file is missing, cannot poll

The /etc/resolv.conf is created by systemd-resolved so if it is stopped, there is no /etc/resolv.conf file.
Keeping systemd-resolved is the easy way to solve the issue. I guess it should also be possible to modify the dnsmasq configuration generated by libvirt to remove the DNS management part and keep only the DHCP.

On my setup, /etc/resolv.conf is a link to a non-existing ../run/systemd/resolve/stub-resolv.conf.
And all I get in libvirtd log is a simple Unable to find 'dnsmasq' binary in $PATH: No such file or directory.
I don't think we need to keep systemd-resolved running all the time, we just need to create any empty /etc/resolv.conf file at setup.

On my setup, resolved is disabled and stopped, and /etc/resolv.conf is a link to a non-existing ../run/systemd/resolve/stub-resolv.conf. And all I get in libvirtd log is a simple, benignUnable to find 'dnsmasq' binary in $PATH: No such file or directory. I don't think we need to keep systemd-resolved running all the time, we just need to create any empty /etc/resolv.conf file at setup. Or at least condition resolved to the need of having dnsmasq (which I'm pretty sure won't be a production need...)

Create an empty /etc/resolv.conf should fix the issue as well.
Regarding dnsmasq it is used for internal network with IPs managed by libvirt.
We don't have this use case in our case, but the libvirt creates some default network which use dnsmasq (at least on Yocto).
So, we have two options:

support the usecase: install dnsmasq and create an empty /etc/resolv.conf.
not support the usecase: remove dnsmasq and the default network.

To me, I think we can drop this usecase. What do you think @insatomcat?

I can't recall if it's something I did something for or if it's by default, but on debian the "default" libvirt network is inactive at deployment (I checked on the CI):
admin@ci1deb12:~$ virsh net-list --all
 Name      State      Autostart   Persistent
----------------------------------------------
 default   inactive   no          yes

Do not having dnsmasq is not a problem, and we do not install the package.
If you ask me it works well as is, so maybe you can make yocto not having dnsmasq as well.


wip: fix wrong result of 0 / decimal and 0 % decimal

What is changed and how it works?

Issue Number: Close #15631
What's Changed:

Related changes

PR to update pingcap/docs/pingcap/docs-cn:
Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Side effects

Performance regression

Consumes more CPU
Consumes more MEM

Breaking backward compatibility

Release note
None

/run-idc-jenkins-ci-test

retest


Updates for Observability 1.6

Description
Update samples for Observability 1.6.
GitHub Issues
List the GitHub issues impacted by this PR:

GitHub Issue #

https://github.com/dell/csm/issues/885

Checklist:

[X] I have performed a self-review of my own code to ensure there are no formatting, vetting, linting, or security issues
[ ] I have verified that new and existing unit tests pass locally with my changes
[X] I have not allowed coverage numbers to degenerate
[ ] I have maintained at least 90% code coverage
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have maintained backward compatibility

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

operatorconfig/moduleconfig/common/version-values.yaml needs changes as well.

Need to make more changes.