text:
fix bug mmclassification issues 661

https://github.com/open-mmlab/mmclassification/issues/661
Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Please describe the motivation of this PR and the goal you want to achieve through this PR.
Modification
Please briefly describe what modification is made in this PR.
BC-breaking (Optional)
Does the modification introduce changes that break the backward compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here and update the documentation.
Checklist
Before PR:

[ ] Pre-commit or other linting tools are used to fix the potential lint issues.
[ ] Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

[ ] If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects, like MMDet or MMSeg.
[ ] CLA has been signed and all committers have signed the CLA in this PR.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Please sign the CLA so we can review this PR.

Hi @xiefeifeihu ！First of all, we want to express our gratitude for your significant PR in the mmpretrain project. Your contribution is highly appreciated, and we are grateful for your efforts in helping improve this open-source project during your personal time. We believe that many developers will benefit from your PR.
We would also like to invite you to join our Special Interest Group (SIG) private channel on Discord, where you can share your experiences, ideas, and build connections with like-minded peers. To join the SIG channel, simply message moderator— OpenMMLab on Discord or briefly share your open-source contributions in the #introductions channel and we will assist you. Look forward to seeing you there! Join us ：https://discord.gg/raweFPmdzG
If you have WeChat，welcome to join our community on WeChat. You can add our assistant ：openmmlabwx. Please add "mmsig + Github ID" as a remark when adding friends：）
Thank you again for your contribution❤

authors: CLAassistant Ezra-Yu OpenMMLab-Assistant-004 xiefeifeihu

repo: open-mmlab/mmclassification


text:
The speed when evaluating the result using the 'bbox'/'coco' format

I make the dataset with coco format and use 'bbox' format to evaluate the result.
But I find the speed of evaluation is very slow, nearly 3 hours.
I want to know where is the problem and how to boost it?
Following is the results:
Evaluating bbox...
Loading and preparing results...
DONE (t=12.14s)
creating index...
index created!
Running per image evaluation...
Evaluate annotation type *bbox*
DONE (t=8601.13s).
Accumulating evaluation results...
DONE (t=187.50s).

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 450.80.02    Driver Version: 450.80.02    CUDA Version: 11.0     |
|-------------------------------+----------------------+----------------------+
| 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  GeForce RTX 208...  Off  | 00000000:3B:00.0 Off |                  N/A |
| 51%   78C    P2   240W / 250W |   1161MiB / 11019MiB |     84%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  GeForce RTX 208...  Off  | 00000000:AF:00.0 Off |                  N/A |
| 49%   76C    P2   212W / 250W |   1229MiB / 11019MiB |     85%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

How large is your val dataset? The coco api uses CPU to calculate the mAP so it may be very slow when there are a lot of images and objects.

source: gharchive/issue

authors: Lausen-Ng RangiLyu

repo: open-mmlab/mmdetection

license_type: permissive

license_source: github-api


text:
HLS_search: wrong results with snap_search

working with branch=master and action=hls_search. I am creating a small file (random or uniform data)  of n bytes and search one char. Expect n hits on uniform data and 0..n hits on random data
for size in 1 2; do
char=$(cat /dev/urandom|tr -dc 'a-zA-Z0-9'|fold -w 1|head -n 1)     # random char to search for
cat /dev/urandom|tr -dc 'a-zA-Z0-9'|fold -w ${size}|head -n 1 >${size}.rnd   # random ASCII data
cmd='print("A" * '${size}', end="")'; python3 -c "$cmd" >${size}.uni              # uniform data
count=$(fgrep -o $char ${size}.rnd|wc -l);                                                      # expected chars in file
snap_search -m2 -p${char} -i${size}.rnd -E${count} -t500 -v                          # random search
snap_search -m2 -pA -i${size}.uni -E${size} -t500 -v                                      # uniform search
done
The test fails, as soon as it expects >0 hits:
snap_search -pA -i1.uni -E1
INFO:Connecting to host 'hdcl070.boeblingen.de.ibm.com' port 16384
Start Step1 (Copy source data from Host to DDR) ..............
INITIALIZATION : move 1 bytes from Host mem to DDR
Step 1 took 9466297 usec
Searching : iteration number 0 1
Start Step3 (Do Search by hardware, in DDR) .......
Naive method (1)
dsize = 1 - psize = 1
warn: Verification failed expected 1 but found 0 patterns

Good corner case! I'll have a look to that

ok this is corrected and Jörg tested it ok

authors: bmesnet joergkayser

repo: open-power/snap

license_source: bigquery


text:
Unable to connect Robot ROS1 free_fleet client and PC ROS2 free_fleet server using Pocket Wifi.

Operating system and version:
PC: Ubuntu20.04, galactic robot: UbuntuMATE20.04, noetic

How to install RMF
I installed RMF following the guide in the link below.
https://github.com/open-rmf/free_fleet

Description of the bug
I started free_fleet_client on my robot's PC and free_fleet_server on my PC according to barebones example, but I can't connect.
I have confirmed the ping connection and port connection between the robot and the PC.
Both the robot and PC set ROS_DOMAIN_ID=0 and opened ports 7400~8000, which would be used by DDS, to check the connection.
Pocket Wifi is used as a common network.
Steps to reproduce the bug
PC: ROS_DOMAIN_ID=0, open ports 7400~8000 and start ff_examples_ros2 fake_server.launch.xml
　Robot: ROS_DOMAIN_ID=0, open ports 7400-8000 and run ff_examples_ros1 fake_client.launch.
　No connection.
Expected behavior
The free_fleet_client running on the robot is registered in the log of free_fleet_sever.
Actual behavior
No log is registered and no communication is established.
Additional information
Network settings were confirmed at the following link.
http://wiki.ros.org/ja/ROS/NetworkSetup
　The following link was used as a reference for opening the port.
https://docs.ros.org/en/foxy/Concepts/About-Domain-ID.html
　A Raspberry Pi 4 Model B is used as the robot PC.

Hello there! Unfortunately I am unable to recreate this issue without the same hardware at hand. Some questions before I look further into it,

Does this setup work when these 2 machines are on a different wifi?
Does this setup work when these 2 machines are on a different pocket wifi?
Does basic pub sub using ROS 1 or ROS 2 across this same network work? This will give us more information whether it is something that needs tweaking on the network level, cyclonedds or free fleet.
If the above works, could you try your setup using basic pub sub on cyclonedds, https://github.com/eclipse-cyclonedds/cyclonedds/tree/master/examples?

Some things to note,

since one of the machines is using ROS 1, setting ROS_DOMAIN_ID will not do anything, that is only useful for communications between ROS 2 machines.

I will be removing the bug label as this is not related to free_fleet's implementation or our usage of cyclonedds, but rather the requirement of using a Pocket Wifi instead.

Thanks for the reply.
I was able to confirm the connection by inactivating the firewalls on the robot PC and ROS2PC.

authors: aaronchongth suztakur


text:
The result of the failed optimization is either Input bitseq incorrect or RECHECK

When I want to explore whether the optimization suggestions given by vsyncer are based on the implementation of the synchronization primitive, or whether the optimization suggestions of the primitive are based on the call in the invocation scenario, I try to define multiple locks such as lock1 and lock2, and pass the locks as variables to the lock() and unlock() functions, and call the run() function, but the result is  stuck in 'RECHECK'.

In addition, when I implement multiple types of locks in client code and call their respective lock() and unlock() in run(), the result is Input bitseq incorrect.

The code is placed in a compressed package for reference.
vsyncer_problem.zip

I'm only using the Vsyncer default configuration during the optimization process，and optimize with
vsyncer optimize -A -1 examples/xxxlock.c
depending on the configuration, the Dat3M backend will also check the case where pthread_create fails. But Vsyncer's default model checker is GenMC, I don’t know whether this configuration is used by VSyncer.

Another thing: we never really ran genmc on RISC-V. You don't need to run vsyncer inside your target machine. You can run that on a normal Intel CPU if you prefer. The model checking happens at the builtin atomic level, which is mapped by the compiler to the target architecture when the real program is compiled.

Yes, I modified the lock for examples, but I also had no problem running examples/ttasklock.c locally. In screenshot one, my bitseq is shorter than yours because I ran lock() and unlock() in it multiple times. If you run lock() and unlock() only once, you can get optimization results. Screenshot 2 may be due to the fact that multiple locks are implemented in the same .c file.
When I run it in Ubuntu22, I still get the above error.

The code is placed in a compressed package for reference.
vsyncer_problem.zip

license: MIT


text:
Bug: The recommendation card in the user profile redirects to the 404 page

Describe the bug
Clicking on a recommendation card on the user profile page opens a new tab, redirecting the user to the page-not-found (404).
The redirected link is as follows:
https://app.opensauced.pizza/repo_name/dashboard/filter/recent
Steps to reproduce

Go to the recommendation tag in the user profile;
Click on one of the recommendations cards;
It redirects to the 404 page.

Do you have any images or screen captures?
https://github.com/open-sauced/app/assets/65237061/994cef61-bbfe-4713-8ed4-512556448c5b
Browsers
Other (add additional context)
Additional context (Is this in dev or production?)
production - Brave
Code of Conduct

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

Contributing Docs

[X] I agree to follow this project's Contribution Docs

Thanks for opening this is work that is in progress #3040.
Just a heads a @zeucapua we will want to link to repo pages here in the future.

Opened a PR now that the feature flag is removed for repo pages.

authors: bdougie lmscunha

repo: open-sauced/app


text:
fix: language interests are accessible now

Description
Originally, there was a <LanguagePill /> component who's parent element was a div with an onclick.
Now there is a <LanguagePill /> component which is just a pill, and now there is also a <LanguageSwitch /> which is accessible.
The <LanguageSwitch /> is used everywhere the was used and the newcomponent is used on the user profile page where a` wraps it.
Note that the icons in the language pills no longer have alt text as these icons are decorative. I've set them to blank alt text to represen that.
What type of PR is this? (check all applicable)

[ ] 🍕 Feature
[x] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Related Tickets & Documents
Fixes #2366
Mobile & Desktop Screenshots/Recordings
Visually it'll look the same, so you can view them in Storybook:

LanguageSwitch component
LanguagePill component

Before
https://github.com/open-sauced/app/assets/833231/be28dc53-71a4-4ff1-9ca2-48b1cf315f19
https://github.com/open-sauced/app/assets/833231/057353e0-8438-41f1-86de-8df529d95466
After
https://github.com/open-sauced/app/assets/833231/410a58e7-c874-4ab0-92fa-5040ef1d18bd

Steps to QA

Ensure you're logged in
Go to the settings page
Use the tab key to navigate the form. When you get to the interests section, each interest you tab to gets a focus state and if you press the space bar, it selects that interest.
If you tab to the update interests button and press the spacebar, it'll update your interests.

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[x] 📕 storybook
[ ] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

Maybe a different issue, but are we worries about the accessibility of this white on orange color palette:

Ran this through firefox's accessibility tool real quick and it pops up as inaccessible for text standards

Yeah, that's a separate issue in regards to colour contrast. This issue was specific to not being able to tab or have focus states.

source: gharchive/pull-request


text:
Show number of downloads

[x] Installed node with version >= 8 (node -v)
[x] Checked other issues

Describe your problem
Since now the download is serial show the progress for each download
IIC3524 Downloaded file (x/total)

Attach log
Paste the full log when running sincding sync

Work in #32

repo: open-source-uc/sincding

license: mit


text:
Improve key/value pairs in headers

In the Headers node, key/values are represented like this currently:
headers:
  key_a: value_a
  key_b: value_b
  api-key: 1234

The key name appear as a node name, on the left hand side (LHS).
Issue 1: This most likely adds some constraints on the name itself, due to yaml.
Can key names that include special characters be represented ?
Issue 2: The key name can not be substituted with environment variables.
This is a concern for keys like api-key, where the exact key name to use can be vendor dependent: it is highly desirable to abstract this away.
Proposed solution:
headers:
  - key:
    name: key_a
    value: value_a
  - key:
    name: "key_b#from%Hell$$" <-- fixes issue 1
    value: value_b
  - key:
    name: ${VENDOR_AUTH_KEY_NAME} <-- fixes issue 2
    value: ${VENDOR_AUTH_KEY_TOKEN}

This model change is a pre-requisite to later support secrets, as discussed in https://github.com/open-telemetry/opentelemetry-configuration/pull/69#discussion_r1480663248

Issue 1: This most likely adds some constraints on the name itself, due to yaml.

I'm pretty sure yaml allows keys to be contain character besides control characters. Can include the key in double quotes and escape if needed. The key_b#from%Hell$$ doesn't appear to need to be contained in double quotes to be valid.

Issue 2: The key name can not be substituted with environment variables.

Hmm.. I want to be careful with this because this argument could potentially be applicable in a lot of places, and encourage us to module using object arrays instead of maps, which is a much less intuitive user experience.

This is a concern for keys like api-key, where the exact key name to use can be vendor dependent: it is highly desirable to abstract this away.

This intersects with this conversation. If we choose to flatten header configure to a comma separated list of key value pairs, then its perfectly possible to do this:
headers: "key_a=value_a,${VENDOR_AUTH_KEY_NAME}=${VENDOR_AUTH_KEY_TOKEN}"

Moved to "TODO" column. I think we need to make a decision on this one way or another before stabilizing. With #106 merged, we can now reasonably add an alternative way to specify OTLP exporter headers to support OTEL_EXPORTER_OTLP_HEADERS and this use case:
tracer_provider:
  processors:
    - batch:
        exporter:
          otlp:
            headers:
              key1: value1
           headers_list: "${VENDOR_AUTH_KEY_NAME}:${VENDOR_AUTH_KEY_TOKEN}"

But we still might consider accepting this as a preferred way to represent general mappings in config. For one thing, it goes a long way to ensuring that all property keys are able to follow our snake case naming convention. We may want to formalize guidance against having user provided, unbound property keys - even if they are possible to express in YAML.
Note that kubernetes manifest use something similar to this issue's suggested syntax to express env vars.

I've opened a #115 with to switch to this recommendation.

authors: jack-berg marcalff


text:
Error in console when attempting to checkout through frontend

Bug Report
0.7.0-beta
Symptom
When attempting to check out through the frontend, clicking the 'Place order' button causes the following:
[Error] Failed to load resource: the server responded with a status of 500 (Internal Server Error) (checkout, line 0)
Unhandled Promise rejection: – "JSON Parse error: Unexpected identifier \"Internal\"" – "; Zone:" – "<root>" – "; Task:" – "Promise.then" – "; Value:" (2)
SyntaxError: JSON Parse error: Unexpected identifier "Internal" — _app-51ff14db9a601587.js:6:3346
"parse@[native code]
@http://localhost:8080/_next/static/chunks/pages/_app-51ff14db9a601587.js:6:3345
u@http://localhost:8080/_next/static/chunks/main-818050cf9ea3098e.js:1:94521
@http://localhost:8080/_next/static/chunks/main-818050cf9ea3098e.js:1:95804
d@http://localhost:8080/_next/static/chunks/pages/_app-51ff14db9a601587.js:13:79000
e@http://localhost:8080/_next/static/chunks/pages/_app-51ff14db9a601587.js:13:79198
run@http://localhost:8080/_next/static/chunks/434.5d13c09717162b96.js:1:4235
@http://localhost:8080/_next/static/chunks/434.5d13c09717162b96.js:19:2728
runTask@http://localhost:8080/_next/static/chunks/434.5d13c09717162b96.js:1:4846
@http://localhost:8080/_next/static/chunks/pages/_app-51ff14db9a601587.js:6:169210
w@http://localhost:8080/_next/static/chunks/434.5d13c09717162b96.js:1:11424
promiseReactionJob@[native code]"

Logs for frontend service:
Error: 13 INTERNAL: failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp: lookup paymentservice on 127.0.0.11:53: no such host"
    at Object.callErrorFromStatus (/app/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client.js:189:52)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:365:141)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:328:181)
    at /app/node_modules/@grpc/grpc-js/build/src/call-stream.js:187:78
    at processTicksAndRejections (node:internal/process/task_queues:78:11) {
  code: 13,
  details: 'failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp: lookup paymentservice on 127.0.0.11:53: no such host"',
  metadata: Metadata {
    internalRepr: Map(1) { 'content-type' => [Array] },
    options: {}
  }
}
Error: 14 UNAVAILABLE: No connection established
    at Object.callErrorFromStatus (/app/node_modules/@grpc/grpc-js/build/src/call.js:31:26)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client.js:189:52)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:365:141)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:328:181)
    at /app/node_modules/@grpc/grpc-js/build/src/call-stream.js:187:78
    at processTicksAndRejections (node:internal/process/task_queues:78:11) {
  code: 14,
  details: 'No connection established',
  metadata: Metadata { internalRepr: Map(0) {}, options: {} }
}

Maybe this is just config related, but it seems like frontend server isn't able to connect to the payment service.

It seems like this is due to the payment service failing to start.

repo: open-telemetry/opentelemetry-demo


text:
[go services]: workaround: disable grpc metrics

Changes
Due to a memory leak with high cardinality in the rpc.server.duration metric generated by the Go SDK, this adds a Metric View to disable those metrics in the checkout and productcatalog services. When the Go SDK is fixed, we should undo this change.
Merge Requirements
For new features contributions please make sure you have completed the following
essential items:

[x] CHANGELOG.md updated to document new feature additions
[ ] Appropriate documentation updates in the docs
[ ] Appropriate Helm chart updates in the helm-charts

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

@puckpuck, is there already a Go issue that could be added here as a reference?

authors: mviitane puckpuck


text:
Fix 'frontend' currently not working

Fixed the alpine base image as the npm version has a newer major version. See topic: https://github.com/open-telemetry/opentelemetry-demo/issues/601
Fixes #601.
Changes
Fixed alpine base image, to make npm dependency for major version 9.x again work.

@tommyziegler could you take a look at the comment https://github.com/open-telemetry/opentelemetry-demo/pull/605#discussion_r1028437017?


text:
Create dependabot.yml

I'm gonna regret this but it's also the only way to stay on top of this for new releases.

This is good but https://github.com/renovatebot/renovate does support Elixir and may be a better option.

Oh. It does show up when you search. I initially ruled it out because neither language was listed in "Language Support". I'll check it out

Ok. I'll look into renovate more since it appears we can do a custom manager to handle erlang

I'm going to close this in favor of getting renovate set up.

authors: bryannaegele tsloughter


text:
Resource doesn't use env detector to detect OTEL_RESOURCE_ATTRIBUTES

What version of OpenTelemetry are you using?
0.20.0
What version of Node are you using?
v15.11.0
Please provide the code you used to setup the OpenTelemetry SDK
const opentelemetry = require('@opentelemetry/api');
const { BasicTracerProvider, ConsoleSpanExporter, SimpleSpanProcessor } = require('@opentelemetry/tracing');

const provider = new BasicTracerProvider();

provider.register();
const tracer = opentelemetry.trace.getTracer('example-basic-tracer-node');

What did you expect to see?
Resource attributes contain any key-values provided in OTEL_RESOURCE_ATTRIBUTES.
What did you see instead?
Setting env didn't do anything.

From Spec

The SDK MUST extract information from the OTEL_RESOURCE_ATTRIBUTES environment variable and merge this, as the secondary resource, with any resource information provided by the user, i.e. the user provided resource information has higher priority.

Since EnvDetector.detect is an async function, it can't be used inside a constructor.
@open-telemetry/javascript-approvers & @open-telemetry/javascript-maintainers What do you think about adding a init/create factory function to Resource?

What do you think about adding a init/create factory function to Resource?

I believe there was a lot of debate around this in this PR: https://github.com/open-telemetry/opentelemetry-js/pull/1484
The last answer of daniel there sums it up well but overall this should be handled at the spec level

Thanks for linking the prior work and discussion.

I encountered the same problem and ended up writing a sync version of the resource detectors I am using:
https://github.com/aspecto-io/opentelemetry-ext-js
Hope we can find a good solution for that which can be implemented in the SDK as using the async resource detectors is sometimes inevitable (for a small amount of the usecaes), but is practically very problematic for otel setup

authors: blumamir lonewolf3739 vmarchaud

repo: open-telemetry/opentelemetry-js


text:
fix(tracing): use globalErrorHandler when flushing fails

Fixes https://github.com/open-telemetry/opentelemetry-js/issues/1617
Short description of the changes
Use the global error handler https://github.com/open-telemetry/opentelemetry-js/pull/1514 when span flushing fails in the BatchSpanProcessor instead of causing an unhandled rejection.

@vmarchaud something like this? You link points to the shutdown method, but the change in BatchSpanProcessor only affects the export. I also wrapped the export in the SimpleSpanProcessor or should I also wrap shutdown in both processors?

@johanneswuerbach Yeah sorry i linked to wrong line :/
I dont think we need to wrap shutdown right now, at least no one complained about this behavior, we'll see in the future.
I'm good with the PR now, even though i would like that we report the actual error that the exporter had but for now this is fine.

@open-telemetry/javascript-approvers I agree with @johanneswuerbach that this is important to fix and release asap, it's common best practices to exit the process when there is an unhandledRejection so most app will crash any time an exporter fails :/

@obecny the problem in this case is that outside of forceFlush no method is actually exposing that state, so I would doubt that somebody build a (working) retry mechanism at this layer.
One call site where this method is currently called is:
https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-tracing/src/export/BatchSpanProcessor.ts#L93, which is called by onEnd, which returns nothing https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-tracing/src/export/BatchSpanProcessor.ts#L60. Another call site is https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-tracing/src/export/BatchSpanProcessor.ts#L122, where the promise rejection is completely ignored any also not returned.
While I'm not sure what the desired future is, there is https://github.com/open-telemetry/opentelemetry-js/issues/1569, which sounds like retry should be implemented at the exporter layer and not here.

@obecny the problem in this case is that outside of forceFlush no method is actually exposing that state, so I would doubt that somebody build a (working) retry mechanism at this layer.
One call site where this method is currently called is:
https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-tracing/src/export/BatchSpanProcessor.ts#L93, which is called by onEnd, which returns nothing https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-tracing/src/export/BatchSpanProcessor.ts#L60. Another call site is https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-tracing/src/export/BatchSpanProcessor.ts#L122, where the promise rejection is completely ignored and the result also not returned.
While I'm not sure what the desired future is, there is #1569, which sounds like retry should be implemented at the exporter layer and not here.

then why not in line 93 do something like this:
this._flush().catch(e => {
  globalErrorHandler(.............
});

and then line 122 should also have the same what line 93.
the flush is used also in shutdown - after your change the shutdown will never raise an error.

@vmarchaud / @dyladan would that also be okay? We generally see tracing as best-effort so we don't care about errors, but I'm happy to wrap the catch those errors in our apps.

@vmarchaud / @dyladan would that also be okay? We generally see tracing as best-effort so we don't care about errors, but I'm happy to wrap the catch those errors in our apps.

I don't think @obecny is suggesting you wrap the error in your app, but wrap it in shutdown where _flush is called.
I think the way the PR has it now is fine. The global error handler changed error behavior in a lot of places already and this is just one more.

If someone already build a mechanism to retry again in case result is FAILED_RETRYABLE the whole logic will be gone.

@obecny note that the spec for span processors does not return the result type https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#interface-definition
Also see in the spec https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#exportbatch

Any retry logic that is required by the exporter is the responsibility of the exporter.
Returns: ExportResult:
ExportResult is one of:

Success - The batch has been successfully exported. For protocol exporters this typically means that the data is sent over the wire and delivered to the destination server.
Failure - exporting failed. The batch must be dropped. For example, this can happen when the batch contains bad data and cannot be serialized.

The RETRYABLE vs NON_RETRYABLE failure has been removed from the spec completely and should be removed in another PR.

@vmarchaud / @dyladan would that also be okay? We generally see tracing as best-effort so we don't care about errors, but I'm happy to wrap the catch those errors in our apps.

I don't think @obecny is suggesting you wrap the error in your app, but wrap it in shutdown where _flush is called.

shutdown is called by "end user". Because the shutdown returns Promise the user should expect that this will be either resolved or rejected with information about error . If we change the logic that the shutdown will never be rejected then we are changing the api that someone might be already using differently or someone might want to take advantage of resolve/reject when building its own solution - we don't know it yet. So I'm against changing this behaviour just to silence the error.
It might be not the scope of this PR but maybe we should have a discussion how exactly we want to handle such cases. And then also think about our api changes if we want this or not. I don't want to decide in this particular case, that's why I'm suggesting to resolve this in a way that the original api of shutdown will still behave the same but for unhandled cases (line 93 the global error handler will be used).
As a user I would be really surprised why suddenly I don't see a bug from a method I just called that wasn't successful.

@vmarchaud / @dyladan would that also be okay? We generally see tracing as best-effort so we don't care about errors, but I'm happy to wrap the catch those errors in our apps.

I don't think @obecny is suggesting you wrap the error in your app, but wrap it in shutdown where _flush is called.

shutdown is called by "end user". Because the shutdown returns Promise the user should expect that this will be either resolved or rejected with information about error . If we change the logic that the shutdown will never be rejected then we are changing the api that someone might be already using differently or someone might want to take advantage of resolve/reject when building its own solution - we don't know it yet. So I'm against changing this behaviour just to silence the error.
It might be not the scope of this PR but maybe we should have a discussion how exactly we want to handle such cases. And then also think about our api changes if we want this or not. I don't want to decide in this particular case, that's why I'm suggesting to resolve this in a way that the original api of shutdown will still behave the same but for unhandled cases (line 93 the global error handler will be used).
As a user I would be really surprised why suddenly I don't see a bug from a method I just called that wasn't successful.

👍 seems reasonable to me.

Updated the PR, let me know if that looks better :-)

Would it be possible to get this into v0.12.1 patch release (happy to cherry-pick) or do we need to wait for v0.13.0?

authors: dyladan johanneswuerbach obecny vmarchaud


text:
How to handle gRPC repo w.r.t. attribution/licensing

Hello,
I recently created opentelemetry-instrumentation-grpc (Ruby gem forthcoming) which is mostly just a fork of much of the opentelemetry-instrumentation-gruf code.
I had a few questions:

How would folks prefer attribution to be given?
I didn't preserve the copyright notices at the top of the files as it's not in the open-telemetry org. That said, I'm happy to restore them should that be preferred--I'm not sure what the policy is w.r.t. in-code copyright notices & forking
Is my choice of MIT license acceptable? Or does it need to maintain the same license as in this repo (Apache 2 IIRC)?

I would have opened a PR to just add the code to this repo but I wasn't sure if I could commit to maintaining it (which the contributing guidelines request).
Thank you!

Hi @hibachrach! Thank you for these questions!
I'm really not sure what the answers are and will bring them up in our next SIG meeting.
If you'd like to join the meeting to be part of the discussion, here's a link to our Google Group, and the calendar invite should be sent to you after you join.
We meet Tuesdays at 9:00AM PT.

Hi @hibachrach,
First off, thank you for building this gem! gRPC instrumentation has been wanted for a long time (see https://github.com/open-telemetry/opentelemetry-ruby-contrib/issues/10), and I'm excited to see it come together.
We talked about your questions during the SIG yesterday and would like to welcome the gem into the opentelemetry-ruby-contrib repo, even if you're unable to meet the maintaining commitments outlined in the contributing guidelines.
Is there any level of engagement you'd be willing to commit to? Are there specific requirements you feel uncomfortable about fulfilling? (We're fine either way, and looking for feedback since these guidelines are relatively new)
Despite our preference to bring opentelemetry-instrumentation-grpc into opentelemetry-ruby-contrib, this is not an obligation.
If you'd prefer to keep the gem separate, we understand that too.
To answer your questions, the safest legal path would be to retain the Apache 2.0 license, keep the license headers, and add your additional copyrights to the headers on the files you modified.
There is also an Apache 2 NOTICE file you could use as well. Here's an example from apache httpd, and here's a file with retained copyright.
Google Open Source has some additional recommendations on this topic: https://opensource.google/documentation/reference/copyright#files_derived_from_third_party_code

First off, thank you for building this gem! gRPC instrumentation has been wanted for a long time (see https://github.com/open-telemetry/opentelemetry-ruby-contrib/issues/10), and I'm excited to see it come together.

Happy to help in any small way I can 😄

Is there any level of engagement you'd be willing to commit to? Are there specific requirements you feel uncomfortable about fulfilling? (We're fine either way, and looking for feedback since these guidelines are relatively new)

I'm happy to try to help to the extent that I'm able with bugs but I only incidentally work with this code as it pertains to my company's system. I also know I get burnt out doing dev work in my free time when it's my primary job at work so I don't want to say one thing and do another. I can therefore commit primarily to trying, lol.

Great! Thank you so much!

I'm happy to try to help to the extent that I'm able with bugs...

That makes a lot of sense. Committing to trying works for me! 😄

Hi @hibachrach! Checking back in on this! Anything we can do to help?

Hey sorry, have just had a busy personal life recently. Going to take a look at this this weekend.

authors: hibachrach kaylareopelle


text:
Add factory and config for attributes processor

#144

Codecov Report

Merging #152 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #152      +/-   ##
==========================================
+ Coverage   73.05%   73.11%   +0.06%
==========================================
  Files          95       96       +1
  Lines        5789     5803      +14
==========================================
+ Hits         4229     4243      +14
  Misses       1350     1350
  Partials      210      210

Impacted Files
Coverage Δ

processor/attributekeyprocessor/factory.go
100% <100%> (ø)

Continue to review full report at Codecov.

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

authors: MohamedElqdusy codecov-io

repo: open-telemetry/opentelemetry-service


text:
Allow SDK repo website_docs to use images from a local resource directory

Overwrite the hugo template to support this, since the theme doesn't do it by default.

I'll probably close this out as well, since we've moved most languages to be in-repo and we'd like that to be the case for the remaining ones. It's probably better to just focus on pulling in Go and Ruby than enable this for them.

authors: cartermp shelbyspees


text:
Iconography.zip should contain icons only, not diagrams

Fix #664

I am not sure why we need the zip really :)

We currently need it because there is a link to it on the page footer. We can remove that or have it don’t differently but until then we need it, I raised a follow up ticket here:
https://github.com/open-telemetry/opentelemetry.io/issues/1693

authors: jkowall svrnm


text:
[Tracker Issue] List of Prometheus issues in the Collector

https://github.com/open-telemetry/opentelemetry-collector/issues?q=is%3Aissue+is%3Aopen+prometheus+label%3Aarea%3Aprometheus

Duplicate issue.

repo: open-telemetry/wg-prometheus


text:
ether_type value in ethernet header configuration is set to default instead of the value provided in configuration

The ether_type value set by the user is 2048(0x0800), but the value is defaulting to 65535(0xFFFF) on the wire
Test:

def test_plvision_issue(api):
    api = snappi.api(location="https://127.0.0.1:443", ext="ixnetwork")
    config = api.config()

    tx, rx = config.ports.port(
        name="tx", location="otg-novus100g.lbj.is.keysight.com;1;5"
    ).port(name="rx", location="otg-novus100g.lbj.is.keysight.com;1;6")

    flow = config.flows.flow(name="f1")[-1]
    flow.tx_rx.port.tx_name = tx.name
    flow.tx_rx.port.rx_name = rx.name

    f = config.flows[0]
    f.packet.ethernet().custom()
    eth, payload = f.packet[0], f.packet[1]
    eth.src.value = "00:CD:DC:CD:DC:CD"
    eth.dst.value = "00:AB:BC:AB:BC:AB"
    eth.ether_type.value = 2048

    payload.bytes = "45000056006600004006af92c0a800010a00000104d20050000000000000000050022000c3d50000000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d"

    print(config)
    api.set_config(config)```

@shramroy can you please close this issue if it has been resolved.

The fix is available from the Ixia-c release v0.0.1-2738.

authors: ankur-sheth ashutshkumr shramroy

repo: open-traffic-generator/ixia-c


text:
Bump lit versions to the 1.0 stable releases

lit-html bumped to 1.0.0
lit-element bumped to 2.0.1 (That was the version which uses 1.0.0 of lit-html)

thxxxx :heart:

authors: daKmoR stramel

repo: open-wc/open-wc


text:
Conversation recording bug in chat mode

Bug Report
Description
Bug Summary:
The conversation recording functionality in chat mode captures the LLM's responses as part of the user's input, resulting in repetition of the LLM's output.
Steps to Reproduce:

Start a call
with the LLM using speakers and a mic (i.e., not headphones)
Observe that the LLM's responses are being recorded as part of the conversation from the user's end.

Expected Behavior:
In chat mode, the conversation recording should only capture the user's input and not include the LLM's responses. The LLM's output should be displayed separately and not be treated as part of the user's input.
Actual Behavior:
In chat mode, the conversation recording captures both the user's input and the LLM's responses. This results in the LLM's output being included in the conversation as if it were coming from the user's end, leading to repetition of the LLM's responses.
Environment

Open WebUI Version: v0.3.7

Ollama (if applicable): I'm running this with aphrodite

Operating System: Ubuntu 22.04

Browser (if applicable): Firefox 127.0.2 (64-bit)

Reproduction Details
Confirmation:

[x ] I have read and followed all the instructions provided in the README.md.
[x ] I am on the latest version of both Open WebUI and Ollama.
[ ] I have included the browser console logs.
[ ] I have included the Docker container logs.

Logs and Screenshots
Browser Console Logs:
[Include relevant browser console logs, if applicable]
Docker Container Logs:
[Include relevant Docker container logs, if applicable]
Screenshots (if applicable):

Installation Method
Docker
Additional Information
I've observed this issue consistently across multiple conversations with the LLM. It obviously works fine with headphones. I've tried restarting the chat interface and reloading the page, but the behavior remains the same. Any guidance on how to address this issue would be appreciated.

This doesn't seem to happen on mobile with chrome on android.
It still does happen with chrome on Windows 11. I have also noticed that even if the call has ended, the app, both on phone and on desktop, continues recording indefinitely.

repo: open-webui/open-webui


text:
Circular dependency in approving links to update operation-key

When a NewApplication  enters the ApplicationLayer , after RO approves the application , it will send regard-application to all the TinyApplicationControllers(TAC) including ApplicationLayerTopology(ALT).
consequently ,

As a callback , ALT will send Redirect-topology-change-information to the NewApplication  to get the LTP and FC details.
As a callback , NewApplication will send update-all-ltps-and-fcs. This step will work fine only if operation-server of the update-all-ltps-and-fcs in ALT consists of the default operation-key. (if the OperationKeyManagement(OKM) is operating in reactive/protection mode)

How NewApplication will get the latest operation-key ?
In ALT , add-operation-client-to-link  service should be used to create a link between the operation-client in NewApplication  and the operation-server in the ALT.
This will initiate a callback(regard-updated-link) to the OKM to update operation-key in the client side.
But , without the LTP details of the NewApplication in the ALT's control-construct list , it is not possible to perform the add-operation-client-to-link.
So , here we have a circular dependency,

NewApplication requires the latest operation-key to perform update-all-ltps-and-fcs in the ALT
To update the operation-key , OKM requires the link details from ALT.
To update link details to the OKM , ALT requires the LTP details of the NewApplication.

A possible proposal could be providing the latest operation-key of the "update-ltp-and-fcs" service when the NewApplication is approved and regarded to the OKM application.

Potential Solution:
Instead of a callback with the newApplication addressing update-all-ltps-and-fcs in ALT, the redirect-topology-change-information request, which is sent from the ALT to the new application, shall be answered with the same content of the update-all-ltps-and-fcs request by the new application.
(The response body can be send without having the operation key, which would have been necessary to address update-all-ltps-and-fcs at ALT.)

Pull-request openBackhaul/ApplicationPattern#324 has been opened for solving this problem.
Problem will be tracked and solved in openBackhaul/ApplicationPattern#305.

authors: PrathibaJee openBackhaul

repo: openBackhaul/ApplicationLayerTopology


text:
Response code of recordServiceRequest

Hello,
I experimented with out implementation of /v1/list-applications-abbreviation, which calls the ExecutionAndTraceLog API recordServiceRequest.

I am getting this error log:
recordServiceRequest - record service request with body {"x-correlator":"550e8400-e29b-11d4-a716-446655440000","trace-indicator":"1.3.1","user":"User Name","originator":"Resolver","application-name":"ApplicationAbbreviationExtractor","application-release-number":"1.0.0","operation-name":"/v1/list-applications-abbreviation","response-code":200,"timestamp":"2022-12-02T15:08:48+01:00","stringified-body":"{}","stringified-response":"[{"application-name":"OldRelease","application-name-abbreviation":"OR"},{"application-name":"NewRelease","application-name-abbreviation":"NR"},{"application-name":"RegistryOffice","application-name-abbreviation":"RO"},{"application-name":"TypeApprovalRegister","application-name-abbreviation":"TAR"},{"application-name":"ExecutionAndTraceLog","application-name-abbreviation":"EATL"},{"application-name":"OamLog","application-name-abbreviation":"OL"},{"application-name":"AdministratorAdministration","application-name-abbreviation":"AA"},{"application-name":"ApplicationLayerTopology","application-name-abbreviation":"ALT"},{"application-name":"OperationKeyManagement","application-name-abbreviation":"OKM"},{"application-name":"CurrentController","application-name-abbreviation":"CC"}]"} failed with response status: 204
Looking at the implementation in the EATL, there seems to be no possibility to return the response code 200 "OK". Instead it returns 204 on success, which is interpreted as a failure in the onf-code-model-ap:

I guess the fix would be to interpret the 204 response as success.

Response code 204 of EaTL://v1/recordServiceRequest should be fine.
No, flaw seen in the specifications.

Many thanks for indicating the problem.
I would like to explain the following things ,

The service /v1/record-service-request is responding with 204 as per the expectation in the OAS. So , both specification and the implementation of EATL is fine.
Then why we see the failure “recordServiceRequest - record service request with body …………….. failed with response status: 204” in the console window ?
In the onf-core-model-ap\applicationPattern\services\ExecutionAndTraceService.js ,  a console log is writing this error message for the response other than 200.
This console log needs to be corrected.

Created a new issue in ApplicationPattern repository to solve this problem https://github.com/openBackhaul/ApplicationPattern/issues/453. So , closing this issue.
Please have a look into the newly created issue as well and let us know your comments.

authors: MFMentopolis PrathibaJee openBackhaul

repo: openBackhaul/ExecutionAndTraceLog


text:
LpSpec::__Pac attribute to be set on IsReadOnly:=False

UML to be corrected
+yang.4 already fixed

HybridMwStructureLpSpec:_hybridMwStructure_Pac has been set on IsReadOnly false.

repo: openBackhaul/hybridMwStructure


text:
Add NUTS sub-country region classification

This PR adds three yaml-files (and a script to generate them) with the disaggregation of countries following the 'Nomenclature of Territorial Units for Statistics' (NUTS) used by Eurostat.
implementing second part of #3

added a stylized example in the readme how to turn the yaml-file into a hierarchical dictionary

the xlsx source file used to generate the NUTS-region classification is available in a separate branch danielhuppmann:attachment/nuts-regions for future reference (see the regions/data folder)

adding myself as assignee ex-post for completeness

repo: openENTRANCE/nomenclature


text:
Performance of the file copy

The following are two execution logs of the File Copy process.
time="2021-10-22T16:19:33.467959Z" level=debug msg="Before UpdateFileSystem" package=runner
time="2021-10-22T16:19:33.468005Z" level=debug msg="Before ExecuteCommand" package=runner
time="2021-10-22T16:19:33.468014Z" level=debug msg="Before fetching Allocations" package=nomad
time="2021-10-22T16:19:33.565683Z" level=debug msg="Before fetching Info about allocation" package=nomad
time="2021-10-22T16:19:33.654211Z" level=debug msg="Before executing in allocation" package=nomad
time="2021-10-22T16:19:34.070807Z" level=debug msg="After executing in allocation" package=nomad
time="2021-10-22T16:19:34.070842Z" level=debug msg="After ExecuteCommand" package=runner
time="2021-10-22T16:19:34.070863Z" level=debug code=204 duration=602.977863ms method=PATCH path=/api/v1/runners/10-a3723825-3340-11ec-9b4e-8c8caab4d49a/files user_agent=PostmanRuntime/7.28.4

time="2021-10-22T16:25:40.730183Z" level=debug code=200 duration="113.003µs" method=POST path=/api/v1/runners user_agent=PostmanRuntime/7.28.4
time="2021-10-22T16:25:42.783385Z" level=debug msg="Runner started" id=10-ef013367-3343-11ec-89eb-8c8caab4d49a package=runner
time="2021-10-22T16:25:54.208628Z" level=debug msg="Before UpdateFileSystem" package=runner
time="2021-10-22T16:25:54.208668Z" level=debug msg="Before ExecuteCommand" package=runner
time="2021-10-22T16:25:54.208677Z" level=debug msg="Before fetching Allocations" package=nomad
time="2021-10-22T16:25:54.295403Z" level=debug msg="Before fetching Info about allocation" package=nomad
time="2021-10-22T16:25:54.383728Z" level=debug msg="Before executing in allocation" package=nomad
time="2021-10-22T16:25:54.837629Z" level=debug msg="After executing in allocation" package=nomad
time="2021-10-22T16:25:54.837688Z" level=debug msg="After ExecuteCommand" package=runner
time="2021-10-22T16:25:54.837726Z" level=debug code=204 duration=629.181328ms method=PATCH path=/api/v1/runners/10-776f23f2-3341-11ec-9b4e-8c8caab4d49a/files user_agent=PostmanRuntime/7.28.4

The file copy process consists of three requests to Nomad.
First, all allocations of the runner are loaded, then all information about the essential allocation is loaded and only then can the Exec command of the Go Library be executed.
I see a good chance that we can save the first two requests by keeping a reference to the Nomad object. (In the case of Poseidon's Execute Route, this even has twice the influence.)
But if we look at the logs, we see that the first two requests take only 175 ms, while the third request takes 454 ms. So for 70 per cent of the duration, I see little potential for savings.

This PR only contained time stamps to ease debugging with the file copy performance. Since we've gained additional monitoring capabilities in the mean time (including detailed Sentry logs) and haven't noticed any further issue with the performance of the file copy operation, we can close this PR.

repo: openHPI/poseidon


text:
Switch source of GR scraper

https://www.gr.ch/DE/institutionen/verwaltung/djsg/ga/coronavirus/_layouts/15/GenericDataFeed/feed.aspx?PageID=26&ID=g_1175d522_e609_4287_93af_d14c9efd5218&FORMAT=JSONRAW
is not beeing updated anymore.
New data source via GR website:
https://services1.arcgis.com/YAuo6vcW85VPu7OE/arcgis/rest/services/Fallzahlen_Total_Kanton/FeatureServer/0/query?where=1%3D1&objectIds=&time=&resultType=none&outFields=Eingangs_Datum%2CAnzahl_Fälle_total__kumuliert_%2CVerstorbene__kumuliert_%2CHospitalisiert_Total&returnHiddenFields=false&returnIdsOnly=false&returnUniqueIdsOnly=false&returnCountOnly=false&returnDistinctValues=false&cacheHint=false&orderByFields=Eingangs_Datum&groupByFieldsForStatistics=&outStatistics=&having=&resultOffset=&resultRecordCount=&sqlFormat=standard&f=pjson

Mapping of variables:
||openZH/covid_19 repo|GR source||
|ncumul_conf|Anzahl_Fälle_total__kumuliert_|

To be clarified: How do we get the hospitalisation data?


text:
Thames-Coromandel District Councils (TCDC), New Zealand

https://services5.arcgis.com/MYtLmLEStmKgdmln/arcgis/rest/services/Property_Information/FeatureServer/0

duplicate of #3842

authors: andrewharvey justinelliotmeyers

repo: openaddresses/openaddresses


text:
Potential data source for Missouri

A number of Missouri counties and munis seem to work with this vendor for parcel and 911 address mapping:
https://bentongis.integritygis.com/Geocortex/Essentials/REST/sites
Not all of them are publicly accessible. The ones I could view map layers for were:
Counties

Bates
Benton
Camden
Chariton
Christian
Cooper
Dade
Dallas
Dekalb
Holt
Lawrence
Livingston (alt)
McDonald
Newton
Polk
Pulaski
Ralls
Ray
Saline
Warren (alt)
Worth

Municipalities

Bolivar
Centralia
Smithville

These all look like ArcGIS REST endpoints to me (thought they're being served up over Geocortext; not sure if that messes with anything). Most seem to have parcels and address points, with a few exceptions. Hope this helps and is usable! I can take another pass at this and try to extract out the parcel/address point endpoints for each.

Just stumbled on #2564 which discusses a statewide address DB, which would likely supersede this source as more accessible and authoritative. But leaving this here for now, in case it can help supplement!


text:
Can we customize OPENAI_BASE_URL, just like we defined OPENAI_API_KEY?

cat .env

OPENAI_API_KEY=sk-rxxxx
OPENAI_ORGANIZATION=
OPENAI_REQUEST_TIMEOUT=30
OPENAI_BASE_URL=api.openai.com/v1

It would be great to have a way to do this more conveniently.
Currently need to use the factory method on the underlying PHP client https://github.com/openai-php/client?tab=readme-ov-file#services

authors: MichaelCrowcroft chudaozhe

repo: openai-php/laravel


text:
How to normalize the data in table of Appendix to obtain Figure 3 in paper?

Dear Author,
I am replicating your results recently, and a little confused about Figure 3 in the paper, how the data, specifically the in the table of Appendix (e.g. success rate of agents, adversaries in Table 4) can be normalized to get that 'histogram'. Now I think that if that normalized value is computed referred to the maximum value of one column? or what is exactly the score of an agent? Please give me some hints.
Thank you in advance sincerely!

hi,have you ever find the answer？i also want to know what the agent score is

repo: openai/maddpg


text:
Update README.md

Add instruction for installation error: https://github.com/openai/whisper/discussions/160

When you really want to be in the contributors list

authors: ExtReMLapin szpasztor

repo: openai/whisper


text:
Add Replicate demo and API

Hey @jongwook! 👋
This PR includes the files for the demo on replicate https://replicate.com/openai/whisper,
thanks again for acknowledging the demo!

Hi Chenxi, thanks for building the demo page. I've been trying to keep this repo minimal with the core components only and directing third-party integrations to the show and tell page. This would allow preventing overcrowding of the root directory and README.md.
Would you mind posting the link and/or introduction to that page instead?

authors: chenxwh jongwook


text:
[Redfish]SNMP test ValueError: The HTTP status code was not valid.

I am testing SNMP via Redfish, And the following error is displayed in the results of multiple test cases:

I wonder if there are any additional requirements for testing SNMP via Redfish？

@prkatti1 @meghagn12345  Can u respond ?

If you are trying to add SNMP manager which is already present, then it will show this error.

@allen810118 does the above information help ?

@meghagn5 I have not yet any subscriptions.

allen@allen:~$ curl -k -H "X-Auth-Token:${bmc_token}" -X GET https://${bmc}/redfish/v1/EventService/Subscriptions/
{
"@odata.id": "/redfish/v1/EventService/Subscriptions",
"@odata.type": "#EventDestinationCollection.EventDestinationCollection",
"Members": [],
"Members@odata.count": 0,
"Name": "Event Destination Collections"
}

and I tried to create a subscription based on your curl command, but it seems that it was not successful.

allen@allen:~$ curl -k -H "X-Auth-Token:${bmc_token}" -X POST https://${bmc}/redfish/v1/EventService/Subscriptions -d '{"Destination": "snmp://10.6.6.6:162", "SubscriptionType": "SNMPTrap", "Protocol": "SNMPv2c"}'
{
"Destination@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The value 'snmp://10.6.6.6:162' for the property Destination is of a different format than the property can accept.",
"MessageArgs": [
"snmp://10.6.6.6:162",
"Destination"
],
"MessageId": "Base.1.11.0.PropertyValueFormatError",
"MessageSeverity": "Warning",
"Resolution": "Correct the value for the property in the request body and resubmit the request if the operation failed."
}
]
}

I'm not sure if this is due to the same error as what happened with the robot file?

@allen810118
as error says it is property value error, means the IP or port number which you are passing is not valid as per this error.

@allen810118 as error says it is property value error, means the IP or port number which you are passing is not valid as per this error.

But this set of IP and Port is obtained from reference to the "test_bmc_snmp_trap.robot" .
I directly used it without making any modifications to the original code, but it seems to be invalid.
And as far as I know, ports 161 and 162 should be used by SNMP Manager, there shouldn't be any errors.
Do you have any suggestions for this?

Tried with same command, it is working fine.
curl -k -H "X-Auth-Token:${bmc_token}" -X POST https://${bmc}/redfish/v1/EventService/Subscriptions -d '{"Destination": "snmp://10.6.6.6:162", "SubscriptionType": "SNMPTrap", "Protocol": "SNMPv2c"}'
{
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The resource has been created successfully.",
"MessageArgs": [],
"MessageId": "Base.1.13.0.Created",
"MessageSeverity": "OK",
"Resolution": "None."
}
]
}

Tried with same command, it is working fine.
curl -k -H "X-Auth-Token:${bmc_token}" -X POST https://${bmc}/redfish/v1/EventService/Subscriptions -d '{"Destination": "snmp://10.6.6.6:162", "SubscriptionType": "SNMPTrap", "Protocol": "SNMPv2c"}' { "@Message.ExtendedInfo": [ { "@odata.type": "#Message.v1_1_1.Message", "Message": "The resource has been created successfully.", "MessageArgs": [], "MessageId": "Base.1.13.0.Created", "MessageSeverity": "OK", "Resolution": "None." } ] }

May I ask what versions of openbmc and automation test you used when testing with this command?
Last week during testing, I found that different versions yield different results. This may be the reason why I am unable to execute the command.

@allen810118  can you please share me the version where you were hitting this issue.

@meghagn5 The openbmc versions we use are all following version 2.12.0.

@allen810118 this code is working fine for us and we are not facing an issue , we also tested it manually & it is working fine consistently.
If you are facing the issue manually also means, please open a defect against SNMP.

Hi all, I have a simulate issue
Test "Configure SNMP Manager On BMC And Verify" on version v4.0_stable, test result was failed.
But this test item result on version 3.0_stable was passed.
I checked the log, and found the error reason is "No JSON object could be decoded".
Then I noticed that POST request content was "body=data=10.6.6.6&data=162". This was not json object.
And test on version 3.0_stable, POST request was correct that content was "body={"data": ["10.6.6.6", 162]} ".
Those different contents ware created by python or utility robot files?
On v4.0_stable test environment, used "Python 3.8.10".
How do I check the test environment is correct for testing?

repo: openbmc/openbmc-test-automation


text:
Update Openbmctool to 1.05

Provides several updates as follows:

Update the Policy Table for missing entries, including addressing issue #26
Fix the health check and fru status commands to pull powersupplies back in.
Adds a natural sort for improved readability of some of the command output.

The RPM build scripts look pretty sketchy, but I guess we can improve them over time.

authors: amboar thalerj

repo: openbmc/openbmc-tools


text:
Respect publication channels listprovider more

While we were already getting information on publications from the respective listprovider for the event details, we were not putting all of it to use, for example ordering. Also, the event table did not have access to this information at all. This should fix that.
Helps with #409.
Screenshots, as the effects are rather unnoticeable without making changes to the listprovider.

This PR over in the main repository may also be of interest: https://github.com/opencast/opencast/pull/5956

I have tested this PR on our side with an Annotation Tool publication. Now the name is displayed correctly in the publications (before it was just named "Custom"):

authors: Arnei snoesberger

repo: opencast/opencast-admin-interface


text:
Add maven wrapper

The Maven wrapper is handy if you need to install the necessary Maven version but cannot upgrade/downgrade or don't want to install Maven at all.

[ ] have a concise title
[ ] close an accompanying issue if one exists
[ ] be against the correct branch
[ ] include migration scripts and documentation, if appropriate
[ ] pass automated tests
[ ] have a clean commit history
[ ] have proper commit messages (title and body) for all commits

Is it out of scope to "grep-and-replace" mvn with ./mvnw, especially in the documentation?

@mtneug agree with you, and easy enough to do in a spare minute.  Since I made the changes someone else (you?) should probably review.  Basic ./mvnw work seems to work just fine in my testing.

authors: geichelberger gregorydlogan mtneug

repo: opencast/opencast


text:
Documentation: Inbox

Document the InboxScannerService. Otherwise it may go entirely unnoticed by opencast administrators.

@lkiesow Thanks for the review. The "requested changes" feature by GitHub is nice, though I cannot automatically apply them.
I noticed there is no page dedicated to the REST API in the docs (neither admin nor developer).


text:
Requirements could not be resolved

Steps required to reproduce the problem

Follow the installation steps. In my case, I ran the following commands on an Ubuntu 14.04 t2.micro instance:

sudo apt-get update
sudo apt-get install -y git apache2 php5-cli php5-intl
cd /var/www
git clone https://github.com/opencfp/opencfp.git
cd opencfp
export CFP_ENV=production
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('SHA384', 'composer-setup.php') === 'e115a8dc7871f15d853148a7fbac7da27d6c0030b848d9b3dc09e2a0388afed865e6a3d6b3c0fad45c48e2b5fc1196ae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
script/setup

Expected Result

Project is set up.

Actual Result

Script fails with this output:

==> Installing dependencies...
Cannot create cache directory /home/ubuntu/.composer/cache/repo/https---packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/ubuntu/.composer/cache/files/, or directory is not writable. Proceeding without cache
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for intervention/image 1.5.13 -> satisfiable by intervention/image[1.5.13].
    - intervention/image 1.5.13 requires ext-gd * -> the requested PHP extension gd is missing from your system.
  Problem 2
    - Installation request for codeclimate/php-test-reporter v0.2.0 -> satisfiable by codeclimate/php-test-reporter[v0.2.0].
    - codeclimate/php-test-reporter v0.2.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
  Problem 3
    - Installation request for guzzle/guzzle v3.8.1 -> satisfiable by guzzle/guzzle[v3.8.1].
    - guzzle/guzzle v3.8.1 requires ext-curl * -> the requested PHP extension curl is missing from your system.
  Problem 4
    - Installation request for satooshi/php-coveralls v0.6.1 -> satisfiable by satooshi/php-coveralls[v0.6.1].
    - satooshi/php-coveralls v0.6.1 requires ext-curl * -> the requested PHP extension curl is missing from your system.

  To enable extensions, verify that they are enabled in those .ini files:
    - /etc/php5/cli/php.ini
    - /etc/php5/cli/conf.d/05-opcache.ini
    - /etc/php5/cli/conf.d/10-pdo.ini
    - /etc/php5/cli/conf.d/20-intl.ini
    - /etc/php5/cli/conf.d/20-json.ini
    - /etc/php5/cli/conf.d/20-readline.ini
  You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.

For OpenCFP to function, you will need the gd and curl PHP extensions installed because we use both intervention/image and other packages that require them. Let me know if you need any help installing extensions and I may be able to advise.

Hi @mdwheele! Thanks for the quick response. I am a PHP noob, so any help would be very much appreciated.

@castillobg, I pulled down an Ubuntu box ubuntu/trusty64 which should be roughly equivalent to what you were working with on AWS (I assume).
vagrant@vagrant-ubuntu-trusty-64:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:        14.04
Codename:       trusty

Here's my session from that base box to get OpenCFP dependencies installed. I'm assuming you have a database server somewhere you can continue towards migrating if only dependencies were able to be installed. If not, lemme know and I can try to help with that as well.
sudo apt-get install git apache2 php5 php5-cli php5-intl php5-gd php5-mcrypt php5-curl
cd /var/www
git clone https://github.com/opencfp/opencfp.git
cd opencfp
export CFP_ENV=production
// Install composer...
script/setup

This worked as expected. So pretty much, you should be able to sudo apt-get install php5-gd php5-curl php5-mcrypt and be good to continue. That said, to get everything else wired up (setting up Apache and MySQL), DigitalOcean has a really good article that will do a much better job than I at pointing you in the right direction: https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-14-04
Hope all is well, good luck!

@mdwheele thanks so much fortaking the time to do this!

Whoops! Missed this reply. It's all good, bud. No worries! 😄

authors: castillobg mdwheele

repo: opencfp/opencfp


text:
Zig-zag forecast: Satellite variable delay

We find that the forecasts over predict on the hour, and under predict on the half hour

This might becasue satellite image are available on the hour
Detailed Description
The forecasts at 00:15 have 15 minute delay of satellite data, but the forecast at 00:45 have 45 minutes of delay of data.
This leads to some zig-sag effects in the 0 hour forecast
Context

good to have smooth forecasts that look relastic

Possible Implementation

[x] recursive CNN (done)
[x] train on 30 mins and 60 mins gap in data (done)
[x] only use satellite images from 60 minutes ago - unfortunately this did not help
[ ] Check NWP shape
[x] Check when Satellite data appears. It should be around 12.15.
[ ] Save one batch to s3, so we can investigate

Satellite data, at 12.07 UTC we have thte satellite data up to 12.00 UTC ready to use in AWS s3

By looking at the batches, I can see that the satellite data has lots of zeros in it.
batch for predicting at

16:00 has 15% zeros
15:30 has 62% zeros

I've deployed a fix to the satellite consumer to keep more data, hopefully tomorrow we will solve the zig zag problem

Think this is now sovled, bu waiting for a sunny day

repo: openclimatefix/PVNet


text:
make cost_and_grad function

cost_and_grad function takes in X, Y and theta ( initialize it with zero vector of required shape) and outputs the cost (or error) and grad vector( derivative of cost function with respect to theta initialized to zero vector).
Cost function should be that of average squared difference.

@opencodbot claim

@opencodebot claim

@opencodebot claim

repo: opencodeiiita/Machine-Learning


text:
Create the FAQ Page

Create the FAQ page. For this  you have to  create a accordion similar to mongoDB  faq page and you can use placeholder data (Lorem ipsum...)  for now.
You have to create a component of accordion in components > elements

Create a folder in elements folder
Create a file index.js in that folder and work in that
Then import that component in faq page in pages folder and place there

claim

Congratulations!. You have 48 hours for this task.
Happy Contributing!!

repo: opencodeiiita/SaveMyForm-Frontend


text:
A new organization using groups

Thought it would be a good idea to create a PR to discuss this in particular (and maybe already merge it to make further work easier):
This PR creates an explicit thematic sorting for our documentation using the groups feature (more on that here: https://docs.gitbook.com/content-editing/pages-structure#using-groups). Internal was moved to be the last group of pages because I think it's the less interesting of them for the person who is looking for help immediately.
This doesn't change any  file except SUMMARY.md.

Fiscal hosts need their own section, not under Financial Contributors. It's a seperate thing.

"Expenses & Getting Paid" is also a seperate thing, not a type of Financial Contribution.

@alanna and @jaskirat2000 I addressed the changes you requested:

Fiscal Hosts and Expenses & Getting Paid now have their own group of pages
Pages related to Core Contributors were moved to Internal

And a final suggestion:

Moving Values from The Open Collective Way to About. Community Guidelines is already a part of About so it seems fitting to put it there.

authors: alanna contraexemplo

repo: opencollective/documentation


text:
Typos on https://opencollective.com/foundation/edit/virtual-cards

some typos on https://opencollective.com/foundation/edit/virtual-cards
Originally posted by @kaylarep in https://github.com/opencollective/opencollective/issues/4312#issuecomment-922085944
should say:
Use a virtual card to spend from your collective's budget. You can request multiple cards (review the host's policy to see how many). Your fiscal host will create the card for you and assign it a limit and a merchant. You will be notified by email once the card is assigned. Learn more (+link to https://docs.opencollective.com/help/expenses-and-getting-paid/virtual-cards)

@kaylarep : Thanks for reporting the issue. I've corrected it; we'll deploy to production next week. 😉

authors: SudharakaP kaylarep

repo: opencollective/opencollective


text:
Date picker design update

The latest design acknowledges the new Timezone picker. The tooltip content has also been updated.
See https://www.figma.com/file/KinuveYf4WUlRIXzMTnmIsmO/[OC-Design]-Lab?node-id=12357%3A180443

The tooltip content is such:

By default, all dates are filtered according to your local timezone. Switching to UTC will indicate that the dates provided match the coordinated universal time format, also used to generate email reports

Feel free to edit it! :)

This has been implemented as the PeriodFilter in

authors: Betree aminakazi


text:
Donation Receipt Appears in Host Currency Instead of Collective Currency

Describe the bug
It seems that for certain collectives in the platform such as this one, https://opencollective.com/bitcoin-design-foundation where the collective currency is EUR and the host currency is USD, all the donation receipts seems to appear in USD while the numeric amount is in EUR. For example here's a sample receipt;

This is for the contribution; https://opencollective.com/bitcoin-design-foundation/contributions/711594 which is in EUR.
To Reproduce
Steps to reproduce the behavior:

Go to any contribution for a collective which is in a different currency than host
Download the receipt to see the discrepancy

Expected behavior
The receipt should display the correct currency of the collective

Reported at, https://opencollective.freshdesk.com/a/tickets/294190 and at slack; https://opencollective.slack.com/archives/C0429NTTABF/p1700732375681179

I'm going to fix the root cause for this issue in https://github.com/opencollective/opencollective-pdf/pull/973. The PR also ships a fix to make sure we always retrieve the host from the transaction rather than account.host, as the host may have changed since the transaction was made.
The idea of displaying receipts in the collective's currency requires some more thinking: we've always displayed this document in the host currency (with the original amount/exchange rate displayed in the table). I'm afraid we could break some host's expectations if we switch this; i.e. are all hosts allowed to generate invoices in a different currency?

authors: Betree SudharakaP


text:
RT-1.4 ATE Native ACL Fix

"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."
b/328335952

Pull Request Functional Test Report for #2774 / 163cc95d612c17a661b2a032deb652ac22e05f70
No tests identified for validation.
Help

Pull Request Test Coverage Report for Build 8179303431
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 53.035%

Totals

Change from base Build 8170851593:
0.0%

Covered Lines:
1730

Relevant Lines:
3262

💛  - Coveralls

authors: MarcCharlebois OpenConfigBot coveralls

repo: openconfig/featureprofiles


text:
OC-26.1 | remove deviation and fix verification

Made below changes:

Remove deviation
In verification for ntpServer NI , right now got and want are switched, so fixed it.

Pull Request Test Coverage Report for Build 9421953520
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.5%

Totals

Change from base Build 9421468745:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls


text:
[CVAT-UI] Fixed AAM bug: #1750

Motivation and context
Fixes a bug reported by community and internal data annotation team
How has this been tested?
Manual testing
Checklist

[x] I submit my changes into the develop branch
[x] I have added description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[x] I have linked related issues (read github docs)
[x] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2020 Intel Corporation
#
# SPDX-License-Identifier: MIT

Resolve #1750
Resolve #1614

Pull Request Test Coverage Report for Build 5926

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 65.826%

Totals

Change from base Build 5911:
0.0%

Covered Lines:
10917

Relevant Lines:
16181

💛  - Coveralls

authors: bsekachev coveralls

repo: opencv/cvat


text:
Persist counter settings

@tdurand
Currently playing with the video file processing mode #88 ... one thing which drives me a bit nuts from an usability point of view, is that every time my counter settings are gone on restart. Is there any way to load the last counter settings on start up?
(Or save these settings aside the data results ... so that one can re-load them?)

Right now none of these things are built in, but it's not that hard to add this.. everything is in place to do so..  (you could with the API , there is a get areas and register areas endpoint : https://opendatacam.github.io/opendatacam/apidoc/#api-Counter )
What default would be nice ? Latest counter settings ?
I may dedicate some time to opendatacam at the end of the week, or early next week.

Great to hear! :)

What default would be nice ? Latest counter settings ?

Yes, having the "last counter settings" load on default ... would already be ok and from the usability a big improvement.

Ok, should work now on v2.1 which I'm releasing later today

authors: b-g tdurand

repo: opendatacam/opendatacam


text:
Change codeflare-sdk allowed updates

As codeflare-sdk is under heavy development, version requirements should be less restrictive, from ~=0.7.1 (allowing only 0.7.z) to ~=0.7 (allowing 0.y).
@anishasthana would that be ok with you?

I think so! @dimakis fyi

Putting this on hold for the moment, waiting for a new codeflare-sdk release to test properly.

authors: anishasthana guimou

repo: opendatahub-io-contrib/workbench-images


text:
RHOAIENG-2787: Let ArgoCD create namespace, rather than using ACM Policy

JIRA: https://issues.redhat.com/browse/RHOAIENG-2787
This is a preparatory commit for RHOAIENG-2787, as not needing to use ACM Policy will make things a little easier for non-ACM cases.
Description
This works as expected as long as the namespace is specified in the GitOps repo, and has the correct argocd.argoproj.io/managed-by label value.
We already had the namespace specified in the GitOps repo, but we didn't include the label.
More information on this label can be found here:
https://docs.openshift.com/gitops/1.11/argocd_instance/setting-up-argocd-instance.html
How Has This Been Tested?

Created both example applications through ACM successfully, and noticed that they were created as expected on the edge clusters
Deleted both of the apps successfully on the ACM hub cluster, and noticed that all of the resources, including the namespaces, were deleted on the edge clusters.

Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

/test

/test test-ai-edge

/lgtm

authors: LaVLaS grdryn

repo: opendatahub-io/ai-edge


text:
System Test suite  + kind workflow to add them to ci

The issue resolved by this Pull Request:
Resolves https://github.com/opendatahub-io/data-science-pipelines-operator/issues/285
Description of your changes:
Test suite is introduced as its own isolated pagic.
It is platform agnostic, and can be ran against a dev cluster (see readme) or via command line, or kind cluster for pr testing (see attached workflow).
Test suite uses ginkgo/gomega. It uses client-go to verify changes in cluster, and basic rest calls to verify changes to the api server.
There are some basic tests included:

verify dspa pod count, and successfully deployment of component pods
test pipeline fetch
test pipeline upload
test experiments list fetch

These tests should give an easy stepping stone for more advanced testing/extensions.
Testing instructions
See readme in the pr
Checklist

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384
An OCP cluster where you are logged in as cluster admin is required.
To use this image run the following:
cd $(mktemp -d)
git clone git@github.com:opendatahub-io/data-science-pipelines-operator.git
cd data-science-pipelines-operator/
git fetch origin pull/384/head
git checkout -b pullrequest bb197177276a8e4209a9643f436407cfd88598ca
make deploy IMG="quay.io/opendatahub/data-science-pipelines-operator:pr-384"

More instructions here on how to deploy and test a Data Science Pipelines Application.

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Systest nomenclature is incorrect, everything will need to be renamed to integration.

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

/unhold

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-384

/lgtm

authors: HumairAK dsp-developers rimolive


text:
[Bug]: GH Actions/CI on the PR failing

Is there an existing issue for this?

[X] I have searched the existing issues

Deploy type
Standalone DSPO (without ODH)
Version
kfpv2
Environment
GH Actions/workflows.
Current Behavior
The GH action checks on PRs to this repository are failing.
This is the test case failing among unit tests:
--- FAIL: TestNestedLoop (0.78s)
    --- FAIL: TestNestedLoop/{yamlPath:testdata/nestedloop_ir.yaml_platformSpecPath:_tektonYAMLPath:testdata/nestedloop.yaml} (0.78s)
FAIL
	github.com/kubeflow/pipelines/backend/src/v2/compiler/tektoncompiler	coverage: 76.7% of statements
FAIL	github.com/kubeflow/pipelines/backend/src/v2/compiler/tektoncompiler	2.606s
?   	github.com/kubeflow/pipelines/backend/src/v2/config	[no test files]
?   	github.com/kubeflow/pipelines/backend/src/v2/controller	[no test files]

And for the integration tests, the pipeline gets created but run creation fails:
  Status of flip-coin run: RUNNING
  Status of flip-coin run: FAILED
 =====   flip-coin FAILED =====
/home/runner/work/data-science-pipelines/data-science-pipelines/sdk/python/kfp/client/client.py:158: FutureWarning: This client only works with Kubeflow Pipeline v2.0.0-beta.2 and later versions.
  warnings.warn(
Are you sure you want to delete run 0d2172e5-c15a-494c-bb8e-5a8ab8e04ba5? [y/N]: Run 0d2172e5-c15a-494c-bb8e-5a8ab8e04ba5 deleted.
e2e test FAILED

Find an example test PR with the CI checks failed here: https://github.com/opendatahub-io/data-science-pipelines/pull/152
Expected Behavior
All the CI checks should pass.
Steps To Reproduce
No response
Workaround (if any)
No response
Anything else
No response

/lgtm
/approve

/approve cancel

authors: DharmitD rimolive

repo: opendatahub-io/data-science-pipelines


text:
Remaining CNBi Phase 1 work

The following are the remaining tasks for CNBi Phase 1 Pipelines
Tasks:

[ ] #129
[ ] #175
[ ] Merged CNBi Phase 1 to main branch currently being delivered as part of Dashboard 2 work.
[ ] Add feature flag to turn on Pipelines version of CNBi.  This will disable CNBi imagestream version if this flag is enabled.

This is out of date to the current process -- we'll log new issues to cover any future goals.

authors: andrewballantyne dlabaj

repo: opendatahub-io/odh-dashboard


text:
Support Caikit Serving Runtime with REST

Closes #2058
Description

Support Caikit with REST
How Has This Been Tested?

Deploy this template
Deploy a new kserve model (I used demo-models/flan-t5-small-caikit/flan-t5-small-caikit in rhods-public)
Do an inference:

> export KSVC_HOSTNAME=$(oc get ksvc <inference-name>-predictor -n <namespace> -o jsonpath='{.status.url}' | cut -d'/' -f3)
> curl -k --json '{
    "model_id": "flan-t5-small-caikit",
    "inputs": "At what temperature does liquid Nitrogen boil?"
}' https://${KSVC_HOSTNAME}/api/v1/task/text-generation

Test Impact

No automated testing
Request review criteria:

Self checklist (all need to be checked):

[X] The developer has manually tested the changes and verified that the changes work
[X] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[X] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

@Xaenalt this is the preliminary work for the issue, once we have the final image we ca review and merge this!

Maybe we'll need a follow up, but merging with the current images

/lgtm

/approve


text:
10544: Removing project note.

Removes a note from the Working on data science projects title. The note is not applicable from the upcoming version.
Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

LGTM

authors: BSynRedhat grainnejenningsRH


text:
GitHub Actions: Packaging

GitHub Actions - Packaging

The GitHub action CI/CD that is added in PR https://github.com/opendcs/rest_api/pull/55 adds the WAR's and jetty standalone tarballs packages to the GitHub Actions artifacts.

authors: adamkorynta dezidizon


text:
Question: How do I integrate knn plugin to my existing Elastic Search OSS?

I am already using an existing elastic search OSS distribution for our document similarity usage. I want to use knn plugin  to my existing ES OSS deployment.  I am ok to build knn feature from source and attach it to my ES OSS, if that is needed.
Is it possible to do that?

Hi @mtikmani,
Yes definitely possible. Assuming your Elasticsearch version is 7.8.

You need to build zip distribution of the plugin first.

-> check out k-NN package and branch opendistro-1.9
-> ./gradlew build
You would notice opendistro-knn-1.9.0.0.zip in build/distributions/ folder.
-> create a folder opendistro-knn in plugins folder under ES dir and unzip the contents in this folder.

Add library to the java path
You would notice libKNNIndexV1_7_3_6.so file in folder jni/release. Set the absolute path to this library in the jvm.options file. Add-Djava.library.path=<path_to_lib_file>   to the jvm.options file to make the library discoverable to Elasticsearch's JVM.
Example :- -Djava.library.path=/tmp/k-NN/jni/release/

Thanks @vamshin : I will try it out.  Can I use ES OSS 7.6 instead of OSS 7.8 or does it have to be OSS 7.8 only?

Hi I'm trying to install on ES version 7.9 by following the steps mentioned by @vamshin but I'm running into the following issue during the build. Pls help suggest what I can do to work around this?
Pls let me know if further information is required.
Tests with failures:
 - com.amazon.opendistroforelasticsearch.knn.index.KNNIndexShardTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.index.KNNVectorFieldMapperTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.plugin.stats.suppliers.KNNCounterSupplierTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.index.codec.KNN86Codec.KNN86CodecTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.plugin.scripts.KNNScoringUtilTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.index.KNNQueryBuilderTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.common.exception.KNNInvalidIndicesExceptionTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.index.KNNIndexCacheTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.index.KNNJNITests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.plugin.transport.KNNWarmupTransportActionTests.classMethod
 - com.amazon.opendistroforelasticsearch.knn.plugin.stats.KNNCounterTests.classMethod

11 tests completed, 11 failed
Finished generating test XML results (0.001 secs) into: /root/k-NN/build/test-results/test
Generating HTML test report...
Finished generating test html results (0.003 secs) into: /root/k-NN/build/reports/tests/test
:test (Thread[Execution worker for ':',5,main]) completed. Took 5.585 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':test'.
> There were failing tests. See the report at: file:///root/k-NN/build/reports/tests/test/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.5/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 9s
27 actionable tasks: 4 executed, 23 up-to-date

You try cmd: ./gradlew build -x test -x integTestRunner -x jacocoTestReport

authors: hoangpmb mtikmani stephen-leo vamshin

repo: opendistro-for-elasticsearch/k-NN


text:
Add new runners bootstrap and cleanup for rpm

This PR is to add new runners bootstrap and cleanup for rpm.
Instead of using EBS recycle, we would prefer to simply provision new VMs and bootstrap as GitHub runners for each integTest, and cleanup these runners once the test is complete.
Test Results:
https://github.com/opendistro-for-elasticsearch/opendistro-build/actions/runs/180588959

We will come back later in another PR to expand setup_runners.sh to all different amis, right now it is hard-coded to AL2, but the foundation is there for more customizations later.


text:
Discrete Laplace Mechanism

Related to #414

This PR is being subsumed by smaller PRs-- lipschitz mul float, bernoulli sampler adjustments in the rr sampler PR, tm chainer and log-time geometric samplers in separate PRs, etc.

Closing in favor of #493.

repo: opendp/opendp


text:
fix(linter): fix linter git hook

@commitlint/config-conventional is not installed by npx so we need to
install it before running @commitlint/cli.
since we're doing this, install @commitlint/cli which speeds up npx as
it no longer needs to pull it.

bors merge

bors merge

repo: openebs/Mayastor


text:
refactoring current metrics exporter implementation

This PR refactors current metrics exporter implementation by making it more modular, It makes adding more resource metrics easier.
This PR includes helm changes as well.

bors merge

repo: openebs/mayastor-extensions


text:
chore(alerting): changes on rules and alert config

This PR labels lvm alerts with service: openebs label. This way it helps alertmanager to bundle them with other openebs generated alerts.
We also add additional route to alertmanager for filtering openebs alerts. We have receiver also specific to openebs. Receiver is currently email only. User can set specifc values using --set commands.

This change won't be availble via this helm chart without releasing a new version.

repo: openebs/monitoring


text:
NDM stuck in container creating mode on WSL2

Hey, i am really new to this, so can somebody help me?
I am trying to use OpenEBS on my WSL2 on Windows 10, but it is stuck in container creating mode.
The error it gives: "MountVolume.SetUp failed for volume "udev" : hostPath type check failed: /run/udev is not a directory".
And here are my values for it: https://github.com/pukanszkypeter/progressive-architecture/blob/main/clusters/my-cluster/openebs.yaml
Everything else is running perfectly:

Is it a problem with the Windows WSL2 or what am i missing?
Thanks in advance!

NDM uses udev for fetching the devices connected to the machine. I think WSL2 does not support udev. May be you can try it on a linux VM on your machine.

authors: akhilerm pukanszkypeter

repo: openebs/openebs


text:
config(usage) Add env for analytics

Signed-off-by: Harsh Vardhan harsh.vardhan@mayadata.io

reviews @kmova


text:
feat(cluster-info): Add unit tests, refactor code and improve logic

What does this PR do?

This PR adds unit tests for cluster-info
This PR adds logic to handle all corner cases, and adds logic to determine the expected and currently present components for a engine to work.
Refactoring code.

Output

Codecov Report

Merging #101 (2753c75) into develop (6ce985b) will increase coverage by 1.83%.
The diff coverage is 91.30%.

@@             Coverage Diff             @@
##           develop     #101      +/-   ##
===========================================
+ Coverage    67.50%   69.34%   +1.83%
===========================================
  Files           22       23       +1
  Lines         1637     1745     +108
===========================================
+ Hits          1105     1210     +105
- Misses         524      527       +3
  Partials         8        8

Impacted Files
Coverage Δ

pkg/cluster-info/cluster-info.go
95.37% <91.30%> (ø)

pkg/util/k8s_utils.go
100.00% <0.00%> (+3.63%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: Abhinandan-Purkait codecov-commenter

repo: openebs/openebsctl


text:
OEQ-1811 - fix(selectUser test): remove findElement

Checklist

[x] the contributor license agreement is signed
[x] commit message follows commit guidelines
[x] tests are included
[ ] screenshots are included showing significant UI changes
[ ] documentation is changed or added

Description of change
I think the issue is when you input query in the user selector dialog, the result won't be rendered in the dom immediately, which causes the findElement to fail.

1

2

3

4

5

6 times. I think it's good enough.

FavouritesPowerSearchIntegration actually is not a new one. I have seen this before both in GitHub and Gitlab.

I can try to fix this in this MR.

I think I just asked Penghai two days ago if this test is new, and he said no. Is this FavouritesPowerSearchIntegration test @PenghaiZhang ?

FavouritesPowerSearchIntegration is an old test suite. It had been disabled for years until I brought it back recently. Yes it is a bit flaky.

Ah! In that case we can probably merge this MR. That can be fixed elsewhere.

authors: PenghaiZhang edalex-ian edalex-yinzi

repo: openequella/openEQUELLA


text:
A confused problem in the EXR to JPEG

Hi,
In the document , the normalization seems not correct.
    extrema = [im.getextrema() for im in rgbf]
    darkest = min([lo for (lo,hi) in extrema])
    lighest = max([hi for (lo,hi) in extrema])
    scale = 255 / (lighest - darkest)
    def normalize_0_255(v):
        return (v * scale) + darkest
    rgb8 = [im.point(normalize_0_255).convert("L") for im in rgbf]

it might be
    extrema = [im.getextrema() for im in rgbf]
    darkest = min([lo for (lo,hi) in extrema])
    lighest = max([hi for (lo,hi) in extrema])
    scale = 255 / (lighest - darkest)
    def normalize_0_255(v):
        return (v - darkest) * scale
    rgb8 = [im.point(normalize_0_255).convert("L") for im in rgbf]

I am not sure whether it is a bug. If not, I feel sorry to bother you.
Best,

The python "OpenEXR" module, and its documentation, is not part of this OpenEXR project: it is an independent effort. You could follow up with the developers here: https://pypi.org/project/OpenEXR/
For what it's worth, I agree with you that your proposed normalization seems more correct (issue #421 also discusses normalization of OpenEXR images)

authors: hqqxyy peterhillman

repo: openexr/openexr