text:
modify the counting way of ckpts

modify the counting way of ckpts

 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.

some ckpt files (including some log file) were stored in google drive, so the original method has some problems

Does it seem that the number of configs is fewer than the number of checkpoints?

fsaf, groie, legacy_1.x don't have the same number of configs and ckpt, and there are some models share the same config.
But now, there is no need to count config, I will remove later.

authors: CLAassistant ZwwWayne congee524


text:
Met version problems when I recover the st-gcn demo

I followed the st-gcn guide, install the required libraries. The last step is python mmskl.py pose_demo, but when I run this command, the screen shows like this:
(open-mmlab) yangyang@tensorsrv:~/mmskeleton$ python mmskl.py pose_demo
/dm0/home/yangyang/.conda/envs/open-mmlab/lib/python3.7/site-packages/Cython/Distutils/old_build_ext.py:41: UserWarning: Cython.Distutils.old_build_ext does not properly handle dependencies and is deprecated.
"Cython.Distutils.old_build_ext does not properly handle dependencies "
/dm0/home/yangyang/.conda/envs/open-mmlab/lib/python3.7/site-packages/mmcv/utils/registry.py:64: UserWarning: The old API of register_module(module, force=False) is deprecated and will be removed, please use the new API register_module(name=None, force=False, module=None) instead.
'The old API of register_module(module, force=False) '
Load configuration information from ./configs/pose_estimation/pose_demo.yaml
Pose estimation:
Traceback (most recent call last):
File "mmskl.py", line 123, in
main()
File "mmskl.py", line 117, in main
call_obj(**cfg.processor_cfg)
File "/dm0/home/yangyang/mmskeleton/mmskeleton/utils/importer.py", line 24, in call_obj
return import_obj(type)(**kwargs)
File "/dm0/home/yangyang/mmskeleton/mmskeleton/processor/pose_demo.py", line 78, in inference
model = init_pose_estimator(detection_cfg, estimation_cfg, device=0)
File "/dm0/home/yangyang/mmskeleton/mmskeleton/apis/estimation.py", line 20, in init_pose_estimator
device='cpu')
File "/dm0/home/yangyang/mmdetection/mmdet/apis/inference.py", line 33, in init_detector
model = build_detector(config.model, test_cfg=config.test_cfg)
File "/dm0/home/yangyang/mmdetection/mmdet/models/builder.py", line 48, in build_detector
return build(cfg, DETECTORS, dict(train_cfg=train_cfg, test_cfg=test_cfg))
File "/dm0/home/yangyang/mmdetection/mmdet/models/builder.py", line 20, in build
return build_from_cfg(cfg, registry, default_args)
File "/dm0/home/yangyang/.conda/envs/open-mmlab/lib/python3.7/site-packages/mmcv/utils/registry.py", line 167, in build_from_cfg
return obj_cls(**args)
TypeError: init() got an unexpected keyword argument 'num_stages'

https://github.com/open-mmlab/mmskeleton/issues/321

I found that the latest mmdet require pytorch >1.3, and the latest mmskeleton require pytorch ==1.2.0, so their requirements are conflict. My solution is roll back the mmdet to 1.2.0, in this version, mmdet require pytorch >=1.1。

source: gharchive/issue

repo: open-mmlab/mmskeleton

license_type: permissive

license_source: github-api


text:
Test to verify fadump.

This test configures fadump and tests fadump for smt 2, 4 and off.
Signed-off-by: Pavithra pavrampu@linux.vnet.ibm.com

Raised new PR.

source: gharchive/pull-request

repo: open-power/op-test


text:
LOs which seem to fit better in a general physics context

I am not too sure where to place the LOs from:

Section 1.1 (LOs 1.1.1 and 1.1.4)
Section 1.2
Section 1.7

since it feels that they would fit better in a general physics context.

Ok yes I agree they fit in a topic of general physics. I put a Topic in between Math and Vectors named Physics in General with subtopics of Units and Solving Problems, hopefully those LOs will fit in somewhere there.

license: MIT


text:
Feature: Insights/Lists - move date filter from individual charts to header

Type of feature
🍕 Feature
Current behavior
Right now, on Insight Pages there is no global date filter. The only filterable component is the repositories and contributors table, making it a bit confusing.
For the initial design of the list feature we wanted to do individual filters for each chart, but realized a global one would be better.
Suggested solution
Goal
Implement global date filter on Lists and Insight Pages.

Add the date filter to the header on every tab of the List and Insight pages
It should be usable on every tab (we can disable it on the reports tab until we figure out what we want to do with reports)
The state should persist as the user navigates the tabs. ie. If I'm on the Dashboard Tab and I select "30d", if I then navigate to the Contributors tab, the filter value should still be "90d"
filter values should be 7d / 30d / 90d  (it's currently 3m instead of 90d on some screens)
default value should be 30d

Mockups
These are quick mockups so alignment might not be perfect. Just align the filter vertically to the navigation tabs, and horizontally it should align to the right with the rest of the components on the page.
Insight pages:

Lists:

Additional context
No response
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

@nickytonline here's some mockups for the date filter on the list page!
It'd be great if we can also add it to insight pages to keep the consistency.

@nickytonline here's some mockups for the date filter on the list page!
It'd be great if we can also add it to insight pages to keep the consistency.

I have it in the list activity page, but I'll add it to the list pages tomorrow.

I've tackled this for the list pages.

@OgDev-01, at some point can you tackle this for the Insights pages? Thanks!

authors: isabensusan nickytonline

repo: open-sauced/app


text:
Bug: Bot accounts in contributor grids give a 404 when clicking on them.

Bot accounts in contributor grids give a 404 when clicking on them.

We should consider checking for  [bot] at the end of the username and generate a generic avatar (current one broken) and provide no link to an OpenSauced user profile page as they don't exist for bot accounts.

Hmmmm the [bot] accounts definitely exist in our users table and are fetchable by the API:

Could it be that the [ and ] are not getting properly escaped?

authors: jpmcb nickytonline


text:
feat: refactor ContributorsTable with TanStack Table

Description
Implement a new ContributorsTable MVP that uses TanStack Table to allow sorting and a new design, inline with WorkspaceIssuesTable and WorkspacePullRequestsTable components. This is added to repository pages to replace the previous Contributors component, and is ready to be replace it elsewhere in the app in future PRs.

Related Tickets & Documents
Closes #3624

Mobile & Desktop Screenshots/Recordings
https://github.com/user-attachments/assets/faa9eeb1-69ae-4206-b249-ec2623671ede

Steps to QA

Go to any repo page and click the "Contributors" tab
Scroll to the table and interact

Sort by OSCR (see URL for orderDirection query changing)
Pagination

Go to mobile view and expand on a contributor via the left button per row.

Tier (staff will fill in)

[ ] Tier 1
[ ] Tier 2
[x] Tier 3
[ ] Tier 4

[optional] What gif best describes this PR or how it makes you feel?

Nice!
When you select the sort on oscr, seems to do a full page refresh: is there no way to just refresh the data in the table?

There is a way! It was refreshing since the order direction was being set in the URL (for sharing purposes), but it was unnecessary. Will make the changes.

This is looking great, @zeucapua!
One thing, o mobile, it seems like we lose a lot of the table data.

Interesting, it should have a button on the left so you can expand the contributor row for more information. Is yours on safari?

It was the Activity that wasn't responsive! Reload the page and the graph will shrink, allowing the table to be responsive. Will put this into a new issue!
https://github.com/user-attachments/assets/cbcdf29d-be58-4207-8d75-1183863548c4

Design Update: @zeucapua and I did an extensive session to work out UX and UI design details for the table. Some interactions still have room for improvement (ie. selecting a user still shifts the table down in the page a bit), but it's in a spot where I'm comfortable shipping it with assurance that we aren't degrading the current experience.

authors: BekahHW isabensusan zeucapua


text:
Add navigation/filter

Navigation and filter submenu needs to be implemented on the page.

All CSS and elements can be found in the example Next App.

Code
Live site

@bdougie I would pick this.

Please review the CONTIBUTING.md for info on how to assign yourself to the issue.

this PR closes this issue: https://github.com/open-sauced/hot-sauce/pull/13

authors: JScrips bdougie kelvinsekx

repo: open-sauced/hot-sauce


text:
Support plugging in your own OpenTelemetry exporter

[as opposed to using an APM vendor's agent that wraps this project and embeds the vendor's exporter]
This is a bit tricky because the OpenTelemetry API and SDK that the agent use are shaded, so the exporter must be shaded as well to match.
There are (at least) two options for shading the user exporter:

Provide a tool that end users can run to shade the OpenTelemetry exporter that they want to use
Shade the OpenTelemetry exporter dynamically at runtime before loading it

What if we took the more painless route of using the native OpenTelemetry Collector protocol and have people use a collector "sidecar" to do the translation to the target protocol?

I think that allowing people to use OTel without a collector and sending to their vendor of choice is still very important. I'd hate to have to stand up a collector to do local development, for example.

I'm taking a stab at this. I'll implement some kind of prototype we can use as basis for further design. Please assign this to me!

I came up with a prototype design for this. Here are some of the considerations:
Early or late shading?
The best spot to load custom exporters seems to be in the TracerInstaller class under agent_tooling. Loading it in this context means that the OpenTelemetry API needs to be shaded. This can be done in three ways: At exporter build time, using some CLI tool on a vendor JAR or dynamically at runtime. Each approach has its pros and cons.
Exporter build time
This involves adding a mandatory list of relocation statements to the gradle script that builds the exporter. Since the OpenTelemetry API is brought in as a compileOnly, the only effect this would have is to change every reference to the API to a shaded one.
Pros

Easy to implement
Requires no additional code
Requires no costly processing at agent load time

Cons

Requires awareness of the auto agent from exporter developers (probably needed anyway, see below)
Exporters will have to be recompiled with a new version of their gradle script if the auto agent ever changes its shading.

CLI Tool
With this approach, we would provide a simple CLI tool that allows users to apply the required shading etc to any exporter JAR.
Pros

Relieves exporter developers from having to deal with auto agent specifics.
Requires no costly processing at agent load time

Cons

Doubtful that it's possible to completely relieve the exporter developers from any awareness of the auto agent, since we need a way to specify bootstrapping etc.
An additional tool to write and maintain

Runtime shading
Here, shading would be done at exporter load time and the exporter could be made completely unaware of the auto agent (restrictions apply, see below).
Pros

Relieves exporter developers from having to deal with auto agent specifics.
Exporters won't break if we change the shading rules.
No extra tools to run

Cons

Doubtful that it's possible to completely relieve the exporter developers from any awareness of the auto agent, since we need a way to specify bootstrapping etc.
Relatively difficult to implement
ByteBuddy doesn't seem to have this type class transformation functionality out-of-the-box (I could be wrong here). ASM has it, but don't want to drag in another bytecode manipulation package.
Processing could be quite costly and we're trying to reduce the load time.

Current design
Shared library
The exporter and the auto agent need to share a very small package in order to obtain a factory, share configuration etc. This is currently done through the exporter-support module in the auto agent. This should probably be moved to opentelemetry-java once we've nailed down the design.
The package contains two classes:
ConfigProvider a simple interface with basic getters that allows the exporter to read arbitrary configurations from the agent. A DefaultConfigProvider implementation exists that provides configurations from the agent config.
ExporterFactory interface that specifies the creation of a SpanExporter based on a ConfigProvider. The exporter project must implement an instance of this and map the configuration to the programmatic way of creating an exporter.
Bootstrapping
In order to be compatible, an exporter needs to provide two things (in addition to the factory described above).

A Bootstrap class. This can be any class that implements a getFactory() method.
A Ota-Bootstrap-Class proprety in the manifest that contains the fully qualified name of the bootstrap class.

The bootstrap procedure in the auto agent works as follows:

Read the ota.exporter.jar property
Create a URLClassLoader based on that property.
Load the MANIFEST.MF and extract the ``Ota-Bootstrap-Class``` property.
Using the newly created ClassLoader, try to load the class referred to by the manifest property.
Using reflection, call the getFactory() method to get a factory.
Construct a ConfigProvider
Call fromConfig() on the factory.
Register the exporter with the tracer.

Sample exporter
A sample exporter is available under the dummy-exporter module. It simply prints the spans to stdout. This exporter is needed for testing, but should probably be moved under an existing module.
Current code:
https://github.com/prydin/opentelemetry-auto-instr-java/tree/prydin-exporter-experiment

would the exporter-build-time option mean that non-auto-instrumentation users would have to deal with oddball packaging?

Good question! I think I would generate two separate jars. One standard jar with no weirdness and one that has the auto stuff in it. That's what I'm planning to do with the vendor specific one I'm working on now.

Of course, the special auto jar could be generated using a separate gradle task so it's not done by default, but the logic would be the same.

Cool. I looked at your dummy exporter. Seems like this is not a lot to ask of people who want their exporters to work auto-magically with the auto-instrumentation system. Would they also need to provide a standard configuration mechanism for their exporter?

All they have to do is to ready properties of their choice from the ConfigProvider they get passed. Then they can use builders or whatever they want to set it up. Like this:
public SpanExporter fromConfig(ConfigProvider config) {
    WavefrontSpanExporter.Builder b = WavefrontSpanExporter.Builder.newBuilder();
    String proxy = config.getString(PROXY, null);
    String url = config.getString(WAVEFRONT_URL, null);
    if (proxy != null) {
      if (url != null) {
        throw new IllegalArgumentException(
            "Settings " + PROXY + " and " + WAVEFRONT_URL + " are mutualy exclusive");
      }
      WavefrontSpanExporter.ProxyClientBuilder pb = b.proxyClient(proxy);
      pb.metricsPort(config.getInt(METRICSPORT, 2878));
      pb.tracingPort(config.getInt(TRACEPORT, 30000));
      pb.flushIntervalSeconds(config.getInt(FLUSH_INTERVAL, 5));
      return pb.build();
    } else if (url != null) {
      String token = config.getString(TOKEN, null);
      if (token == null) {
        throw new IllegalArgumentException(
            "Setting " + TOKEN + " must be specified for direct connections");
      }
      WavefrontSpanExporter.DirectClientBuilder db = b.directClient(url, token);
      db.flushIntervalSeconds(config.getInt(FLUSH_INTERVAL, 5));
      return db.build();
    } else {
      throw new IllegalArgumentException(
          "Either " + PROXY + " or " + WAVEFRONT_URL + " need to be specified");
    }
  }

The capability of configuring an exporter from some kind of config should, in my opinion, be inherent to opentelemetry-java at some point. But that's above my pay grade right now. :)

Hmm. It doesn't really make sense to have exporters have to depend on code in the auto-instrumentation project (ConfigProvider, etc). Can you make a proposal (issue) in the java project for having this ConfigProvider be a part of the SDK?

You're absolutely right! They should definitely be part of the SDK. I just had issues linking the auto instrumenter to an unreleased jar in my file system, so I resorted to this in order to produce a PoC. I forgot to mention that! Nothing should ever be dependent on the auto instrumenter in my opinion. It's a black box.

I will open an issue once we decide that this is the way forward. Let's discuss on the Thursday call!

Seems like this is not a lot to ask of people who want their exporters to work auto-magically with the auto-instrumentation system

This seems reasonable to me also.
One thought so far, can we use SPI / service loader instead to look up and instantiate the bootstrap class?

Doesn't a ServiceLoader require you to put a bunch of stuff in you META-INF? I wanted to make this configurable from system attributes and/or environment variables only.

Instead of requiring shading at all, could the exporter be wrapped in an adapter/bridge at load time?

Instead of requiring shading at all, could the exporter be wrapped in an adapter/bridge at load time?

Not sure I understand how that would work. Can you elaborate?

Re: ServiceLoader, it would just be used for the Bootstrap Class discovery (replacing the Ota-Bootstrap-Class MANIFEST entry). It wouldn't affect the configuration proposal.

Re: ServiceLoader, it would just be used for the Bootstrap Class discovery (replacing the Ota-Bootstrap-Class MANIFEST entry). It wouldn't affect the configuration proposal.

Hmmm... Yeah, that might actually work. Trying it out...

hits head I just realized that the ClassRemapper from ASM is available through ByteBuddy. OK, then the dynamic runtime shading thing isn't that hard to do I suppose.

Pushed code based on feedback from @trask, @tylerbenson and @jkwatson

Using the SPI pattern with ServiceLoader
Implemented runtime shading

Have a peek at https://github.com/prydin/opentelemetry-auto-instr-java/tree/prydin-exporter-experiment of you like!

This all sounds good to me. Can you submit a PR for more detailed review? Thx!

It sounds like remapping at load time is the way to go.  Nice job.  One thing to consider... what happens if the exporter exists on a user's classloader and isn't on the system classpath (eg spring boot jar)?

Initial implementation completed by #159 and #171

authors: jkwatson prydin trask tylerbenson


text:
Nginx OpenTelemetry module not setting span status to error when HTTP status_code is in the 5xx range

Describe your environment Describe any aspect of your environment relevant to the problem, including your platform, build system, version numbers of installed dependencies, etc. If you're reporting a problem with a specific version of a library in this repo, please check whether the problem has been fixed on main branch.
Nginx 1.21.6
opentelemetry module autoinstrumented from this image: registry.k8s.io/ingress-nginx/opentelemetry@sha256:40f766ac4a9832f36f217bb0e98d44c8d38faeccbfe861fbc1a76af7e9ab257f (but the current master branch has the same issue)
When Nginx Open Telemetry instrumentation is enabled using the otel_ngx_module.so module, the spans created from Nginx don't have a status, even if the HTTP status code is 500.
Here is an example location set to return 500:
location = /errorTest/ {
     opentelemetry on;
     opentelemetry_propagate;
     opentelemetry_trust_incoming_spans on;
     return 500 'Error !!';
}

And you can see the OpenTelemetry span data:

Attribute
Value

http.flavor
"1.1"

http.host
http host

http.method
"GET"

http.scheme
"http"

http.server_name

http.status_code
500

http.target
"/errorTest/"

http.user_agent
"Chrome/111.0.0.0 Safari/537.36"

net.host.port
80

net.peer.ip
peer ip

net.peer.port
54456

otel.library.name
"nginx"

span.kind
"server"

status.code
0

Resource
Value

service.name
"test_service"

telemetry.sdk.language
"cpp"

telemetry.sdk.name
"opentelemetry"

telemetry.sdk.version
"1.8.1"

I would expect, per the documentation from here and here to have the span status set as error (status.code = 2) instead of Unset (0).
Steps to reproduce
Start Nginx with OpenTelemetry module enabled, create a location in the default server with the following specs:
location = /errorTest/ {
     opentelemetry on;
     opentelemetry_propagate;
     opentelemetry_trust_incoming_spans on;
     return 500 'Error !!';
}

Make a call to the /errorTest location, then look for OpenTelemetry data to see that the span status is not set to Error.
What is the expected behavior?
When the http status is in the 5xx range, the span status to be set to Error.
What is the actual behavior?
Span status is not set in any scenario (regardles of the http status code)
Additional context
We are trying to export the OpenTelemetry data to Instana and due to missing Span status, the erroneous calls are not properly identified.

Any update or workaround for this? This feels like very basic missing functionality.

You can try using the otel-webserver-module instrumentation. I dont think they have this issue.

authors: aryanishan1001 ghitabot-vg sbquinlan


text:
[collector] Allow more flexibility around adding volumes/volumeMounts

The changes included here add more flexibilitly to opentelemetry-collector deployments when being consumed as a subchart. Having both volumes/volumeMounts and extraVolumes/extraVolumeMounts allows the owner of the subchart a space to add pre-defined volumes/volumeMounts. Giving the consumer the freedom to add more volumes/volumeMounts under extraVolumes/extraVolumeMounts fields.

@chunter0 please on an issue where we can discuss in depth the problem you're experiencing and how this PR solves it.

I opened https://github.com/open-telemetry/opentelemetry-helm-charts/issues/1168 for discussion
CC: @TylerHelmuth @JaredTan95 @povilasv


text:
[opentelemetry-collector] Add spanmetrics processor preset

Adds a spanmetrics processor preset.  Allows configuring the name of which exporter is used.
As it relates to https://github.com/open-telemetry/opentelemetry-helm-charts/pull/456 IDK if it will simplify the demo's values.yaml since the preset will need configured and the collector's config will still need to create the prometheus exporter and add it to the metrics pipeline, but its always nice to use presets where they exist.

@dmitryax I agree.


text:
ESM+Typescript not able to auto-instrument some things?

What happened?
Steps to Reproduce
Clone https://github.com/gas-buddy/gasbuddy
yarn
yarn build:all
yarn token-serv
Expected Result
Pino logs should include traces and spans.
Actual Result
Pino logs do not include traces and spans.
Additional Details
Included below
OpenTelemetry Setup Code
import { diag, DiagConsoleLogger, DiagLogLevel } from '@opentelemetry/api';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import * as opentelemetry from '@opentelemetry/sdk-node';

import type { DelayLoadServiceStartOptions } from '../types.js';

// For troubleshooting, set the log level to DiagLogLevel.DEBUG
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.DEBUG);

const sdk = new opentelemetry.NodeSDK({
  traceExporter: new opentelemetry.tracing.ConsoleSpanExporter(),
  instrumentations: [getNodeAutoInstrumentations()],
});

export default async function startWithTelemetry(options: DelayLoadServiceStartOptions) {
  await sdk.start();

  // We can't import things (express, pino, etc) before
  // telemetry has gotten its hooks in. So that's why
  // DelayLoadServiceStartOptions exists.
  const module = await import(options.service);
  const service = module.default;

  const { startApp, listen } = await import('../app.js');
  const app = await startApp({ ...options, service });
  app.locals.logger.info('OpenTelemetry enabled');

  await listen(app, async () => {
    await sdk.shutdown();
    app.locals.logger.info('OpenTelemetry shut down');
  });
}

package.json
{
  "name": "@gasbuddyrepo/service",
  "type": "module",
  "version": "1.0.0",
  "description": "An exploration of a modern GasBuddy service with Typescript support",
  "exports": "./build/index.js",
  "types": "./build/index.d.ts",
  "scripts": {
    "test": "jest",
    "lint": "eslint src",
    "build": "tsc -p tsconfig.json && yarn dlx chmodx build/bin/*",
    "watch": "tsc -p tsconfig.json -w --preserveWatchOutput",
    "clean": "npx rimraf ./build"
  },
  "author": "GasBuddy Developers <developers@gasbuddy.com>",
  "license": "UNLICENSED",
  "repository": {
    "type": "git",
    "url": "git@github.com:gas-buddy/gasbuddy.git"
  },
  "keywords": [
    "typescript",
    "gasbuddy"
  ],
  "engines": {
    "node": ">16"
  },
  "dependencies": {
    "@gasbuddyrepo/service": "^1.0.0",
    "@opentelemetry/api": "^1.2.0",
    "@opentelemetry/auto-instrumentations-node": "^0.32.1",
    "@opentelemetry/exporter-otlp-grpc": "^0.26.0",
    "@opentelemetry/sdk-node": "^0.33.0",
    "confit": "^3.0.0",
    "express": "^4.18.1",
    "express-openapi-validator": "^4.13.8",
    "pino": "^8.6.1",
    "read-pkg-up": "^9.1.0",
    "shortstop-dns": "^1.1.0",
    "shortstop-handlers": "^1.1.1",
    "shortstop-yaml": "^1.0.0"
  },
  "devDependencies": {
    "@types/confit": "^2.0.3",
    "@types/express": "^4.17.14",
    "@typescript-eslint/eslint-plugin": "^5.3.1",
    "@typescript-eslint/parser": "^5.3.1",
    "eslint": "^8.2.0",
    "eslint-config-airbnb-base": "^15.0.0",
    "eslint-config-airbnb-typescript": "^17.0.0",
    "eslint-plugin-import": "^2.25.3",
    "eslint-plugin-prettier": "^4.0.0",
    "prettier": "^2.5.1",
    "typescript": "^4.4.4"
  },
  "bin": {
    "start-service": "./build/bin/start-service.js"
  }
}

Relevant log output
@opentelemetry/api: Registered a global for diag v1.2.0.
Loading instrumentation for @opentelemetry/instrumentation-amqplib
Loading instrumentation for @opentelemetry/instrumentation-aws-lambda
No modules instrumentation has been defined, nothing will be patched
Loading instrumentation for @opentelemetry/instrumentation-aws-sdk
Loading instrumentation for @opentelemetry/instrumentation-bunyan
Loading instrumentation for @opentelemetry/instrumentation-cassandra-driver
Loading instrumentation for @opentelemetry/instrumentation-connect
Loading instrumentation for @opentelemetry/instrumentation-dns
Loading instrumentation for @opentelemetry/instrumentation-express
Loading instrumentation for @opentelemetry/instrumentation-fastify
Loading instrumentation for @opentelemetry/instrumentation-generic-pool
Loading instrumentation for @opentelemetry/instrumentation-graphql
Loading instrumentation for @opentelemetry/instrumentation-grpc
Loading instrumentation for @opentelemetry/instrumentation-hapi
Loading instrumentation for @opentelemetry/instrumentation-http
Loading instrumentation for @opentelemetry/instrumentation-ioredis
Loading instrumentation for @opentelemetry/instrumentation-knex
Loading instrumentation for @opentelemetry/instrumentation-koa
Loading instrumentation for @opentelemetry/instrumentation-lru-memoizer
Loading instrumentation for @opentelemetry/instrumentation-memcached
Loading instrumentation for @opentelemetry/instrumentation-mongodb
Loading instrumentation for @opentelemetry/instrumentation-mysql2
Loading instrumentation for @opentelemetry/instrumentation-mysql
Loading instrumentation for @opentelemetry/instrumentation-nestjs-core
Loading instrumentation for @opentelemetry/instrumentation-net
Loading instrumentation for @opentelemetry/instrumentation-pg
Loading instrumentation for @opentelemetry/instrumentation-pino
Loading instrumentation for @opentelemetry/instrumentation-redis
Loading instrumentation for @opentelemetry/instrumentation-redis-4
Loading instrumentation for @opentelemetry/instrumentation-restify
Loading instrumentation for @opentelemetry/instrumentation-winston
EnvDetector found resource. Resource { attributes: {} }
ProcessDetector found resource. Resource {
  attributes: {
    'process.pid': 52654,
    'process.executable.name': '/Users/memetral/.nvm/versions/node/v16.17.1/bin/node',
    'process.command': '/Users/memetral/dev/gb/gasbuddy/node_modules/.bin/start-service',
    'process.command_line': '/Users/memetral/.nvm/versions/node/v16.17.1/bin/node /Users/memetral/dev/gb/gasbuddy/node_modules/.bin/start-service',
    'process.runtime.version': '16.17.1',
    'process.runtime.name': 'nodejs',
    'process.runtime.description': 'Node.js'
  }
}
@opentelemetry/api: Registered a global for trace v1.2.0.
@opentelemetry/api: Registered a global for context v1.2.0.
@opentelemetry/api: Registered a global for propagation v1.2.0.
Applying patch for dns
patch lookup function
patch lookup function
Applying patch for net module
Patching pg.Client.prototype.query
@opentelemetry/instrumentation-http Applying patch for http@16.17.1
Applying patch for express@4.18.1
@opentelemetry/instrumentation-http Applying patch for https@16.17.1
{"level":30,"time":1664511439593,"pid":52654,"hostname":"MaxM1Max.local","msg":"OpenTelemetry enabled"}
{"level":30,"time":1664511439595,"pid":52654,"hostname":"MaxM1Max.local","port":8001,"service":"token-serv","msg":"express listening"}

regarding ESM see #1946. In short ESM modules are not yet supported so any problems regarding ESM are not bugs.
I responded already on https://github.com/open-telemetry/opentelemetry-js/discussions/3285 which seems to cover the same topic.
Closing this one as duplicate.

That issue leads to a few stale PRs and some mention that perhaps there's a way to get the same benefit with esModuleInterop? Will resume convo on #3285 .

authors: Flarna djMax

repo: open-telemetry/opentelemetry-js


text:
Auto instrumentation does not set attribute http.route for HTTP server spans

What happened?
Steps to Reproduce
SDK configurations:
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');

const { Resource } = require('@opentelemetry/resources');

const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');

const opentelemetry = require('@opentelemetry/sdk-node');

const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');

const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');

const { registerInstrumentations } = require('@opentelemetry/instrumentation');

const {

   ConsoleSpanExporter,

   SimpleSpanProcessor,

   BatchSpanProcessor,

} = require('@opentelemetry/sdk-trace-base');

const {

   PeriodicExportingMetricReader,

   ConsoleMetricExporter,

} = require('@opentelemetry/sdk-metrics');

const { SERVICE_NAME, BUILD_BUILDID } = process.env;

// This registers all instrumentation packages

registerInstrumentations({

   instrumentations: [getNodeAutoInstrumentations()],

});

const resource = Resource.default().merge(

new Resource({

   [SemanticResourceAttributes.SERVICE_NAME]: SERVICE_NAME ?? 'spg-webplatform-core-BE',

   [SemanticResourceAttributes.SERVICE_VERSION]: BUILD_BUILDID ?? '1.0.0',

})

);

const provider = new NodeTracerProvider({

   resource: resource,

});

//set up a trace exporter

const traceExporter = new OTLPTraceExporter({
   concurrencyLimit: 10, // an optional limit on pending requests
});

// export spans to console (useful for debugging)

provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));

// export spans to opentelemetry collector

provider.addSpanProcessor(new BatchSpanProcessor(traceExporter), {

   // The maximum queue size. After the size is reached spans are dropped.
   maxQueueSize: 1000,

   // The interval between two consecutive exports
   scheduledDelayMillis: 30000,

});

provider.register();

const sdk = new opentelemetry.NodeSDK({
   traceExporter: traceExporter,
   instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

process.on('SIGTERM', () => {
   sdk
      .shutdown()
      .then(() => console.log('Tracing terminated'))
      .catch((error: any) => console.log('Error terminating tracing', error));
});

Expected Result
The generated HTTP server spans have the attribute http.route
Actual Result
http.route is not present in server spans, while other attributes like http.method, http.host, http.url etc. are present.
Additional Details
According to the HTTP server spans semantic conventions (https://opentelemetry.io/docs/specs/otel/trace/semantic_conventions/http/#http-server-semantic-conventions), HTTP server spans should have the http.route attribute set
OpenTelemetry Setup Code
No response
package.json
No response
Relevant log output
No response

Which HTTP server framework do you use? And is there an instrumentation providing the route info?
The built in HTTP module has no cocept of routes therefore it can only add the HTTP_ROUTE attribute if the server framework instrumentation (e.g. express, connect, hapi,...) provides it.

I'm filing on behalf of a customer, they only mentioned they're using Node.js
The interesting thing is span attributes http url and http path group are present, but http route is missing, while http route should be fairly easy to derive given other attributes are present.

Could you please elaborate on the algorithm you refer to for http.route detection?
Consider express framework which allows to use patterns in routes like this:
app.post(/.*fly$/, handler)
app.get('/users/:userId/books/:bookId', handler)
How should OTel know that the route is /users/:userId/books/:bookId if the path is /users/15/books/37?

@Flarna sorry I meant the http route info should be present, especially in this case we saw http path_group was correctly set (sth. like path_group: /users/?/books/?)
@dyladan as far as I can tell they're using https://www.npmjs.com/package/@emotion/react, not sure what other frameworks they're using. Is it something already supported?

@emotion/react is a client styling library and applies to web, not node. I'm referring to the HTTP server framework such as express, koa, nest, or similar.

We're experiencing the same issue with not being able to see the http.route on HTTP server spans. We noticed that this issue appears when the server output is compiled to ESM, but things work as expected when the exact same code is compiled to commonjs, if that helps narrow things down. We're also using ExpressJS.
@songy23 @dyladan

We noticed that this issue appears when the server output is compiled to ESM, but things work as expected when the exact same code is compiled to commonjs

We are experiencing the exact same issue.

Instrumentations are currently broken with ESM: https://github.com/open-telemetry/opentelemetry-js-contrib/issues/1849

The ESM issue is separate from this one. The original issue here was that they were expecting http.route, which is not added by the http instrumentation but by the framework like express, because the native http has no concept of http.route. This is most likely caused by the instrumentation for your framework not working, not the http instrumentation. Please open a separate issue.
I'm going to close this one so that it doesn't cause confusion as it is quite old and we believe it is not a bug but a misunderstanding of the way the instrumentation is meant to work. Please reopen or create a new issue if there is a bug not addressed above.

authors: Flarna OliverJAsh annejohnson220 dyladan mlegenhausen songy23


text:
Implement Named Tracers and Meters

The "Named Tracers and Meters" RFC (https://github.com/open-telemetry/oteps/blob/master/text/0016-named-tracers.md) has been approved and was added to the specification (open-telemetry/opentelemetry-specification#264).
Please make sure to also update the documentation if necessary (tracer, meter creation).
OpenTelemetry language repositories now need to implement this mechanisms.

This is turning out to be a much bigger code change than expected, especially around the node SDK.
Following the specification instructions, I started by adding a TracerFactory type that has the function getTracer(name?: string, version?: string). In @opentelemetry/core, initGlobalTracer becomes initGlobalTracerFactory and we end up with something like
getTracer(name?: string, version?: string) {
  return globalTracerFactoryDelegate.getTracer(name, string);
}

so that ergonomically existing code can feel the same.
However, for the node and basic tracer code, a kind of ugly issue rears its head when it comes to sharing exporters among tracers created by the tracer factory. Let's say that we have a simple sdk factory:
class BasicTracerFactory implements types.TracerFactory {
  constructor(config: BasicTracerConfig) {
    this._defaultConfig = config;
    this._defaultTracer = new BasicTracer(config);
  }
  getTracer(name?: string, version?: string) {
    return this._defaultTracer
  }
}

If we add an exporter, all we have to do is opentelemetry.getTracer().addSpanProcessor(...). However, if we begin to actually create new tracers based on name, e.g.
getTracer(name? : string, version?: string) {
  if (name) {
    // this would probably be more like a get or create tracer operation
    return new BasicTracer({ name: name, config...})
  }
  return this._defaultTracer;
}

span processors added via opentelemetry.getTracer().addSpanProcessor would not be on the tracer opentelemetry.getTracer('http-plugin'). To solve this, addSpanProcessor and other methods would need to be added to the factory and so it would become responsible for managing all shared configuration for tracers. Not ideal at all.
Instead of using a factory, I propose adding a new method to types.Tracer: withComponent(name: string, version?: string): Tracer. Implementations can either return the original tracer or return a wrapper class that maintains a reference to the original tracer while attaching the component to all spans. The same thing can be added to Meter (https://github.com/open-telemetry/opentelemetry-js/issues/402).
Thoughts @open-telemetry/node-approvers @draffensperger @dyladan>

@bg451 would you expect span processors added via opentelemetry.getTracer().addSpanProcessor to be on opentelemetry.getTracer('http-plugin')? When I read the spec I read that as creation (if needed) of a new Tracer with its own set of configs and span processors.

@dyladan Yeah I would. The person using opentelemetry.getTracer('http-plugin') is writing an shared instrumentation library (not an end user), so they wouldn't be doing any configuration and also doesn't know where the end user wants the spans to go.

This just feels like deviating from the spec a little too much for me. Could the tracer factory return a wrapper class around the global tracer that implemented naming but delegated everything else to the wrapped tracer?
FWIW the ruby implementation also would not satisfy your constraint https://github.com/open-telemetry/opentelemetry-ruby/pull/114. I didn't find another OpenTelemetry language that has implemented named tracers/meters yet.
Reading through their PR conversation and the associated issue, it seems pretty clear that they don't understand the need for named tracers or what they may be used for. The OTEP and associated spec PR is really unhelpful in this regard. Maybe @z1c0 can be of some help here since he wrote the OTEP and the spec around it. I must admit the named tracers/meters spec left me with more questions than answers and it seems I am not the only one.

The otep provides an example of something similar in the Prior art section:

existing (global) Tracers could return additional indirection objects (called e.g. TraceComponent), which would be able to produce spans for specifically named traced components.

My understanding of named tracers is that traditionally 3rd party libraries ould instrument themselves with opentracing and use the global tracer. This way, users could also get visibility of what was happening in their dependencies. There was this tag in opentracing called component that would specify where the instrumentation was, so all spans created in and by gRPC or express or node-mongodb-native would have the tag component=node-mongo-native set on them. This is super tedious though and only some libraries did this so the concept of named tracers came about, where the 3rd party library could do tracer = getTracer('node-mongo-native') and not have to attach the component tag manually. @danielkhan could also help explain some of the benefits of having this 3rd party library naming as well.

I think this is worth bringing up to the specification because it is really not clear what the desired side effects are.

To solve this, addSpanProcessor and other methods would need to be added to the factory ... Not ideal at all.

Why is it not ideal? If tracers are moving one level down by becoming namespaced (instead of being a singleton), then exporters naturally have to move one level up, to the factory.

Can we simply allow two things so you would be able to inject the exporter during the initialisation, but we can add function to tracer to update this at any given time too in  case you  want to use a different exporter later.

I think this is worth bringing up to the specification because it is really not clear what the desired side effects are.

I think it is probably worth bringing up with spec. Even if we decide what we want, the spec should make it more clear than it does. If the spec isn't cleared up, then different implementations may have different behaviors as we already see with the Ruby PR implementing in a naive way that would not share span processors among multiple tracers.
A
const defaultTracer = TracerFactory.getTracer().addSpanProcessor(p1);
const httpTracer = TracerFactory.getTracer('http'); // Should this tracer contain p1?

B
const httpTracer = TracerFactory.getTracer('http').addSpanProcessor(p1);
const defaultTracer = TracerFactory.getTracer(); // Should this tracer contain p1?

C
const defaultTracer = TracerFactory.getTracer();
const httpTracer = TracerFactory.getTracer('http');
defaultTracer.addSpanProcessor(p1)
// should httpTracer contain p1?

According to @bg451 at least A should be yes.
The naive Factory would answer no to all questions
The ruby implementation answers no to all questions

All 3 are incorrect.

As @yurishkuro said, all 3 are incorrect.
Setting a spanProcessor must move up to the TracerFactory

I didn't find another OpenTelemetry language that has implemented named tracers/meters yet.

Maybe the .NET implementation helps (https://github.com/open-telemetry/opentelemetry-dotnet/pull/239)

Thank you @z1c0 that's what I thought but I wanted to make sure.
Perhaps the spec should mention that setting span processor moves to the factory in order to minimize confusion between implementations. In this case, the ruby implementation needs to be amended. The current version (https://github.com/open-telemetry/opentelemetry-ruby/blob/7122835f6cc874e02d75e94078dafce6cbb4a99c/sdk/lib/opentelemetry/sdk/trace/tracer_factory.rb) does not have a mechanism to set the span processor on the tracer factory.

Thanks @dyladan, I can see how this causes confusion.
I will make sure to update the specification where necessary and comment on the ruby repository.

@draffensperger Ruby and .NET also have implemented but Ruby is a very minimal implementation. .NET was implemented by the OTEP and spec writer.
withComponent doesn't give the core benefit which is that naming tracers becomes the default recommended approach. If you build a tracer without a name, nothing stops you from never calling withComponent and many libraries may never do so. If the factory getTracer method takes a name and version argument it becomes much more clear that you're expected to name and version them.

If I understand correctly in my case it should look like this
import * as opentelemetry from '@opentelemetry/core';
const { SimpleSpanProcessor } = require('@opentelemetry/tracer-basic');
const { ConsoleExporter } = require('@opentelemetry/console-exporter');
import { WebTracer } from '@opentelemetry/tracer-web';
const exporter = new ConsoleExporter();
const webTracer = new WebTracer({
  plugins: [
    new DocumentLoad()
  ]
});
opentelemetry.getTracer().addSpanProcessor(new SimpleSpanProcessor(exporter));
// or ?
opentelemetry.getTracer('webTracer').addSpanProcessor(new SimpleSpanProcessor(exporter));

opentelemetry.initGlobalTracer(webTracer);

instead of what I like much more and I think is more intuitive and natural from js
import { ConsoleExporter } from '@opentelemetry/console-exporter';
import { WebTracer } from '@opentelemetry/tracer-web';
import { DocumentLoad } from '@opentelemetryplugin-document-load';

const webTracer = new WebTracer({
  exporter: new ConsoleExporter(),
  plugins: [
    new DocumentLoad()
  ]
});

ConsoleExporter - just a simple exporter to show spans in console nothing fancy so far

Okay I'm going to continue forward with the factory approach, but I agree with @obecny that the exporter should go into the configuration of the tracer.

I don't see any reason that both can't work. That would be a question for specification though. I think @z1c0 is going to bring it up with them, but maybe we should make an issue to track these types of questions.

The question where these configurations objects need to go, seems to be highly controversial. I think we need to be very clear in the specification on this, so I created an issue in the specification repository. We should continue this discussion there: https://github.com/open-telemetry/opentelemetry-specification/issues/304

Named Tracer is implemented via #582, closing this one. Will open a separate issue for Named Meter.


text:
unclear where UserInteractionInstrumentation and XMLHttpRequestInstrumentation should be imported from.

Suggested improvements for page: https://opentelemetry.io/docs/languages/js/getting-started/browser/#add-instrumentations
As a starting point in OpenTelemetry, it is unclear where UserInteractionInstrumentation and XMLHttpRequestInstrumentation should be imported from.

thank you for your feedback @gilisho!
@open-telemetry/javascript-approvers please take a look

@gilisho thanks for pointing this out! Would you be interested in creating a PR with these changes? Something like this is probably what should get added into there.
npm install @opentelemetry/instrumentation-user-interaction \
  @opentelemetry/instrumentation-xml-http-request \

import { UserInteractionInstrumentation } from '@opentelemetry/instrumentation-user-interaction';
import { XMLHttpRequestInstrumentation } from '@opentelemetry/instrumentation-xml-http-request';

// code from earlier step

// Registering instrumentations
registerInstrumentations({
  instrumentations: [
    new DocumentLoadInstrumentation(), // from earlier
    new UserInteractionInstrumentation(),
    new XMLHttpRequestInstrumentation(),
  ],
});

Hey, sorry for the late reply. I'd love to contribute. will push a PR in the following days! 😄

@gilisho are you still interested in helping?

Hi, I've submitted the PR now. Thanks!

Hi, I've submitted the PR now. Thanks!

Thanks!

authors: JamieDanielson gilisho svrnm


text:
Update otel collector service name

Open Telemetry collector service name changed from otel-collector to otelcol

Thanks for the PR @rogercoll. Is this meant to close #1126?

@jpkrohling Yes, commands tested in Debian and Rpm based machines.
The only commands that can cause confusion are the ones to install the packages as they are without the sudo command in front.
Would you add it?

Would you add it?

No, that's fine.

authors: chalin jpkrohling rogercoll


text:
Use the workbox-config.js as default config

Docs: Rollup > Overriding the workbox config
I want to propose that if the project already has a workbox-config.js, the @open-wc/building-rollup use it by default, without any other change. Overriding the default:
https://github.com/open-wc/open-wc/blob/85f53c94f10b4d0c86c8f93da52135654d7821d0/packages/building-rollup/modern-and-legacy-config.js#L126-L135
That way, the user just has to change the rollup.config.js if he wants to change the workbox mode.

One idea is #884

Closing as fixed by #884
Please reopen if this is still relevant.

authors: abdonrd bennypowers

repo: open-wc/open-wc


text:
Please invite me.

Please invite me to your github group.
Here is Daivid Morgan from Macedonia.
I love teamwork and I really wanna be one of your teammates.
Thanks. Daivid

Thanks.

Name : "Daivid Morgan"
Github Name : "DevStar0202"
Discord Name : "DevStar0202"
I really wanna be one of your group and I will contribute your github repositories toegether,
Thanks. Daivid
@DevStar0202

Hey David, Welcome to openAOD. I will be sending an invite to join the organization shortly. Feel free to join our Discord server: https://discord.gg/wZ83xSJSsN . If you have any questions regarding the project or about contributions do contact me. If you need to ask anything please fell free to do so here. After you can confirm that you have joined the organization I will go ahead and close the other 2 issues as well. Cheers. Have a great day,

Thanks.

Sure, anytime.

repo: openAOD/Join


text:
Consistency across fileBased Iterations

Nowhere in the standard is it specified that attributes, groups and datasets must be consistent (at least their presence, name and position) across all files in a fileBased series.
The concrete undefined behaviour I ran into is this:
Starting with #171, meshesPath and particlesPath are optional in the sense that their presence indicates the presence of the contained group.
It is possible to have multiple iterations (and thus files) in a fileBased series where either of the attributes is present or not. This may vary across files (i.e. one iteration may suddenly contain no particles or meshes could suddenly pop out of the void).

Yes, that's true. In openPMD-viewer we have a flag checking this (optionally) during open.
It probably makes sense to ask for consistency in a series for those very practical reasons. And if varying structure (other records, etc.) need to be written to put it separate series. But I can also see how this leads to unnecessary many files, e.g. if one wants to dump a certain quantity often (in high temporal resolution) and another less often, because they evolve on different time scales (think: electrons vs. ions).

repo: openPMD/openPMD-standard


text:
indices sequence length is longer than the specified maximum sequence length

when i run python -m detector.train it gives this error:

i have tried to solve it with different parameters of train but doesnt make sense.

I also encountered this problem.

authors: andysjt mfurkanndemir


text:
Is there a way to set stopSequences? I can see the option in the Typescript and Python APIs but not .NET

Confirm this is not a feature request for the underlying OpenAI API.

[X] This is not a feature request for the underlying OpenAI API

Confirm this is not a feature request for Azure OpenAI.

[X] This is not a feature request for Azure OpenAI

Describe the feature or improvement you're requesting
I would like to set stopSequences but it appears to be read only
Additional context
No response

Thank you for reaching out, @sashababayan . StopSequences is already initialized. You can add and remove elements directly like this:
ChatCompletionOptions options = new();
options.StopSequences.Add("foo");

thanks!

authors: joseharriaga sashababayan

repo: openai/openai-dotnet


text:
[TRITON-MLIR][OPTIMIZER] Improve pipeline unit test

Our unit test for the loop pipelining pass should match insert_slice and extract_slice. Right now, if we get the indices wrong (as was the case before) the test still passes

done in #660

repo: openai/triton


text:
[Frontend] Convert constexpr to value for store and load ops

Fixing problem 2 in https://github.com/openai/triton/issues/1017

@ptillet Ready for review


text:
Support of recursive and circular references

Is your feature request related to a problem? Please describe.
References to schemas that have not been processed yet are not supported now. See the example.
Describe the solution you'd like
I suggest to add models that are referenced without properties. And fill in the properties later. This adds the ability to refer to schemas that have not been processed yet.
Describe alternatives you've considered
Also it may also be easier to create all models without properties first, then add properties with second pass.
Additional context
Example OpenAPI:
openapi: 3.0.3
info:
  title: 'Example'
  version: 0.1.0
servers:
  - url: 'http://example.com'
paths:
  '/foo':
    delete:
      responses:
        '200':
          description: OK
components:
  schemas:
    Brother:
      type: object
      properties:
        sister:
          $ref: '#/components/schemas/Sister'
    Sister:
      type: object
      properties:
        brother:
          $ref: '#/components/schemas/Brother'

Generator produces warnings and models package is empty.
Could not find reference in parsed models or enums
Reference(ref='#/components/schemas/Sister')

Could not find reference in parsed models or enums
Reference(ref='#/components/schemas/Brother')

I expect the generated models for Brother and Sister. Something like:
# models/brother.py
class Brother:
    sister: Union[Unset, Sister] = UNSET

# models/sister.py
class Sister:
    brother: Union[Unset, Brother] = UNSET

This would be great!
I want to use openapi-python-client, but this issue is a blocker.
I'll keep an eye on https://github.com/openapi-generators/openapi-python-client/pull/467...

Hello! The branch #467 does not work and I do not plan to finish it. Instead, I wrote another one that allows you to generate a client that supports circular, recursive references and inheritance in allOf cases . But it is of low quality, contains third-party bugs. Please PM if you need such a code. I don’t want to publish it because it’s bad. I don’t have time to refactor it. I think it’s the right idea, some things in model generation have to be redesigned to make it clear and high quality with support circular references + inheritance.
By the way, I think it is better to use pydantic in models generation as it is done in datamodel-code-generator it looks cleaner. Also
I don’t really like to put the classes in one module, but it also lets not write a bunch of ugly local try ... except ... in case with circular references.
For my OpenAPI, I got a lot of local pieces like,
        try:
            from ..models import user as user_m
            # ... 15 lines
        except ImportError:
            import sys

            user_m = sys.modules[__package__ + "user"]
            # ... 15 lines

A note for the eventual fix of this, I've added an explicit check and warning to reduce user confusion when this issue presents itself in #519 which should be removed once this is supported.

What release is this scheduled to go into? when will that release goout? and what can I do to help? as this is a feature I need.

I am not sure how you usually work but is it possible to create a branch with the code changes that have been made then I could then add some test schemas and code along with any other  changes that may be required

I am not sure how you usually work but is it possible to create a branch with the code changes that have been made then I could then add some test schemas and code along with any other changes that may be required

@penske-file If you have GitHub cli and have cloned the openapi-generators/openapi-python-client repo, you can use this command to checkout the PR branch:
gh pr checkout 582

@maz808 @penske-file @dbanty

openapi: 3.0.3
info:
  title: 'Example'
  version: 0.1.0
servers:
  - url: 'http://example.com'
paths:
  '/foo':
    delete:
      responses:
        '200':
          description: OK
components:
  schemas:
    Brother:
      type: object
      properties:
        sister:
          $ref: '#/components/schemas/Sister'
    Sister:
      type: object
      properties:
        brother:
          $ref: '#/components/schemas/Brother'

I think this is related to an issue that I ran into. If it is helpful to anybody, I found that modifying the example as follows results in an error-free generation-
openapi: 3.0.3
info:
  title: 'WorkingExample'
  version: 0.1.0
servers:
  - url: 'http://example.com'
paths:
  '/foo':
    delete:
      responses:
        '200':
          description: OK
components:
  schemas:
    Brother:
      type: object
      properties:
        sister:
          schema:
            $ref: '#/components/schemas/Sister'
    Sister:
      type: object
      properties:
        brother:
          schema:
            $ref: '#/components/schemas/Brother'

@ayemiller As far as I'm aware, the second example you've given isn't valid OpenAPI spec. The schema keyword isn't meant to be used in that context. If it's not throwing errors, that may be indicative of another issue.

Here I just wanted to add that instead of pydantic, the use of attrs (modern interface) and especially cattrs (for structuring/unstructuring) could be really good. There is a lot of stuff now in attrs and cattrs that overall is more flexible than pydantic.

Closed by #670 🥳

authors: ayemiller barakalon dbanty hhoeflin maz808 mtovts penske-file


text:
Rename G4-raw to G4-upload, and G4 to G4-local-only

Also removes ShareBLE from the interactive prompts per @kdisimone's #398

Need someone to run through each G4 CGM option on a new myopenaps directory and make sure they get set up as intended and work properly.

Merging this to dev for testing.

license: mit

license_source: bigquery


text:
Move to github.com/openark/orchestrator: update code

This repository recently moved from http://github.com/github/orchestrator to http://github.com/openark/orchestrator
Since golang uses internet paths in source code, the move implies changes to source code, build files, docker files, etc.
This PR switches all source, scripts, resources and documentation to indicate the new path.

Sheesh. With golang source code change, also comes gofmt, which reorders import lines alphabetically.

repo: openark/orchestrator


text:
Add .PutKVPairs() method to KVStore interface

Related issue: https://github.com/openark/orchestrator/issues/1273
Description
This PR adds the .PutKVPairs() function to the KVStore interface (in go/kv) to allow decisions around updating multiple KVs to be pushed down to the various KV store implementations. This new method replaces the single-KVPair method .PutKVPair() from go/kv/kv.go
The following files were updated to use .PutKVPairs() vs single-KVPair updates:

go/logic/command_applier.go
go/logic/orchestrator.go
go/logic/topology_recovery.go

For now the .PutKVPairs() function in each KVStore is just doing a plain-loop over .PutKeyValue() but in the near-future this method will be used to implement atomic multi-KVPair updates for the Consul KV store (https://github.com/openark/orchestrator/issues/1273) and potentially the ZooKeeper store too

cc @shlomi-noach

Updated PR based on @shlomi-noach's suggestions


text:
[Bug]:

Version of the software
0.1.25
Operating system
win 10
Browser / Native
firefox
What happened?
hi
in selenium,when using WaitForElement block,if it get timeout,the bot get end with Error Result and it will not continue the next blocks like ob1.2.2
fix if possible
thanks
Relevant LoliCode if needed
No response

OB2 has puppeteer not selenium
Click on the SAFE checkbox at the top of the block and it will not throw an error even if it fails

authors: openbullet ufoevangel


text:
[QUESTION] Where is the thread/bot limit

Hello, I'm just looking at the source code and i cannot find where the thread (bot) limit is. Me and My friends need a limit that is above 1000 because it would be faster and we can handle it. Can someone reply to this with the file name and the directory of the file where the thread limit is located :)

Views > Main > Runner > Runner.xaml
Line 96, Change 200 to whatever you want

authors: PurityWasHere lifeisbroken

repo: openbullet/openbullet


text:
[related] Export a list of user IDs from the OLD dataset

Jason, this is kind of a weird request, but it should not take you more than 45 mins.
I would like you to start from your graph database, populated with data from the Drupal platform (this is what I have today on my GraphRyder dashboard) and export a list of its 282 usernames and user IDs, in CSV or JSON or whatever you want. That's it.
Possible?

Hi, the route http://164.132.58.138:5000/users should give you what you are
looking for: a json with ids and labels.
On 4 Nov 2017 10:10 pm, "Alberto Cottica" notifications@github.com wrote:

Jason, this is kind of a weird request, but it should not take you more
than 45 mins.
I would like you to start from your graph database, populated with data
from the Drupal platform (this is what I have today on my GraphRyder
dashboard) and export a list of its 282 usernames and user IDs, in CSV or
JSON or whatever you want. That's it.
Possible?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/opencarecc/graph-ryder-dashboard/issues/33, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACvxb19FbJTnh0dPv_vwq9rPJcrifjGGks5szNLBgaJpZM4QSKSn
.

Great, thanks!
On Sat, Nov 4, 2017 at 11:20 PM, jason-vallet notifications@github.com
wrote:

Hi, the route http://164.132.58.138:5000/users should give you what you
are
looking for: a json with ids and labels.
On 4 Nov 2017 10:10 pm, "Alberto Cottica" notifications@github.com
wrote:

Jason, this is kind of a weird request, but it should not take you more
than 45 mins.
I would like you to start from your graph database, populated with data
from the Drupal platform (this is what I have today on my GraphRyder
dashboard) and export a list of its 282 usernames and user IDs, in CSV or
JSON or whatever you want. That's it.
Possible?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/opencarecc/graph-ryder-dashboard/issues/33, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACvxb19FbJTnh0dPv_
vwq9rPJcrifjGGks5szNLBgaJpZM4QSKSn>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/opencarecc/graph-ryder-dashboard/issues/33#issuecomment-341933897,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB4p5ks-2vd_nlopZof7PGfWmIGmiyVXks5szOMxgaJpZM4QSKSn
.

authors: albertocottica jason-vallet

repo: opencarecc/graph-ryder-dashboard


text:
Can't build from source, can't build frontend

Describe the bug
Can't compile front-end component
To Reproduce
Steps to reproduce the behavior:

Git clone '...'
Mvn clean install '....'
See error

Environment Information

OS: Debian on Termux
Browser: None, headless server
lastest commit

The error:
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.10.3:grunt (grunt build) on project opencast-admin-ui-frontend: Failed to run task: 'grunt build --skipTests=false' failed. org.apache.commons.exec.ExecuteException: Process exited with an error: 3 (Exit value: 3) -> [Help 1]               org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.10.3:grunt (grunt build) on project opencast-admin-ui-frontend: Failed to run task                        at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)       at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)                           at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)                            at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)              at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)                                            at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)                        at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)                        at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)                          at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)                              at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)                               at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)                                 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)                  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)                                             at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)                                     at java.lang.reflect.Method.invoke (Method.java:566)                                      at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)                                                at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)           at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)                                              at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)         Caused by: org.apache.maven.plugin.MojoFailureException: Failed to run task                   at com.github.eirslett.maven.plugins.frontend.mojo.AbstractFrontendMojo.execute (AbstractFrontendMojo.java:100)                        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)                                  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)       at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)                           at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)                            at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)              at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)                                            at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)                        at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)                        at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)                          at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)                              at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)                               at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)                                 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)                  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)                                             at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)                                     at java.lang.reflect.Method.invoke (Method.java:566)                                      at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)                                                at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)           at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)                                              at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)         Caused by: com.github.eirslett.maven.plugins.frontend.lib.TaskRunnerException: 'grunt build --skipTests=false' failed.                     at com.github.eirslett.maven.plugins.frontend.lib.NodeTaskExecutor.execute (NodeTaskExecutor.java:63)                                  at com.github.eirslett.maven.plugins.frontend.mojo.GruntMojo.execute (GruntMojo.java:64)                                               at com.github.eirslett.maven.plugins.frontend.mojo.AbstractFrontendMojo.execute (AbstractFrontendMojo.java:94)                         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)                                  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)       at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)                           at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)                            at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)              at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)                                            at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)                        at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)                        at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)                          at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)                              at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)                               at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)                                 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)                  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)                                             at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)                                     at java.lang.reflect.Method.invoke (Method.java:566)                                      at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)                                                at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)           at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)                                              at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)         Caused by: com.github.eirslett.maven.plugins.frontend.lib.ProcessExecutionException: org.apache.commons.exec.ExecuteException: Process exited with an error: 3 (Exit value: 3)          at com.github.eirslett.maven.plugins.frontend.lib.ProcessExecutor.execute (ProcessExecutor.java:82)                                    at com.github.eirslett.maven.plugins.frontend.lib.ProcessExecutor.executeAndRedirectOutput (ProcessExecutor.java:64)                   at com.github.eirslett.maven.plugins.frontend.lib.NodeExecutor.executeAndRedirectOutput (NodeExecutor.java:29)                         at com.github.eirslett.maven.plugins.frontend.lib.NodeTaskExecutor.execute (NodeTaskExecutor.java:58)                                  at com.github.eirslett.maven.plugins.frontend.mojo.GruntMojo.execute (GruntMojo.java:64)                                               at com.github.eirslett.maven.plugins.frontend.mojo.AbstractFrontendMojo.execute (AbstractFrontendMojo.java:94)                         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)                                  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)       at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)                           at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)                            at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)              at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)                                            at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)                        at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)                        at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)                          at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)                              at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)                               at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)                                 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)                  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)                                             at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)                                     at java.lang.reflect.Method.invoke (Method.java:566)                                      at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)                                                at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)           at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)                                              at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)         Caused by: org.apache.commons.exec.ExecuteException: Process exited with an error: 3 (Exit value: 3)                                       at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)     at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)             at com.github.eirslett.maven.plugins.frontend.lib.ProcessExecutor.execute (ProcessExecutor.java:74)                                    at com.github.eirslett.maven.plugins.frontend.lib.ProcessExecutor.executeAndRedirectOutput (ProcessExecutor.java:64)                   at com.github.eirslett.maven.plugins.frontend.lib.NodeExecutor.executeAndRedirectOutput (NodeExecutor.java:29)                         at com.github.eirslett.maven.plugins.frontend.lib.NodeTaskExecutor.execute (NodeTaskExecutor.java:58)                                  at com.github.eirslett.maven.plugins.frontend.mojo.GruntMojo.execute (GruntMojo.java:64)                                               at com.github.eirslett.maven.plugins.frontend.mojo.AbstractFrontendMojo.execute (AbstractFrontendMojo.java:94)                         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)                                  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)       at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)       at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)                           at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)                            at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)              at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)                                            at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)                        at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)                        at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)                          at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)                              at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)                               at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)                                 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)                  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)                                             at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)                                     at java.lang.reflect.Method.invoke (Method.java:566)                                      at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)                                                at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)           at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)                                              at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)         [ERROR]                                      [ERROR]                                      [ERROR] For more information about the errors and possible solutions, please read the following articles:                              [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException    [ERROR]                                      [ERROR] After correcting the problems, you can resume the build with the command          [ERROR]   mvn <args> -rf :opencast-admin-ui-frontend        root@localhost:~/opencast#`

The stack trace you posted only tells us that grunt build --skipTests=false failed, not why. That's probably in some of the other logs. But if you say that you do not have a browser installed, then that's likely already the reason. Since you are building with tests, Opencast will try running some front-end tests which require Firefox or Chrome for their execution. Try installing one of the browsers, or skip the tests with mvn clean install -DskipTests …

Closing for now.

authors: lkiesow mtneug xx1182

repo: opencast/opencast


text:
Remove JDOM From Ingest Service

This patch removes JDOM from the ingest service, making Opencast use one
less XML library. As discussed on list, this breaks compatibility with
zipped Matterhorn ≤ 1.3 media packages.
In case there are still such media around, ingest the media by
extracting the zip archive and adding the files one by one.
Your pull request should…

[x] have a concise title
[x] close an accompanying issue if one exists
[x] be against the correct branch (features can only go into develop)
[x] include migration scripts and documentation, if appropriate
[x] pass automated testing
[x] have a clean commit history
[x] have proper commit messages (title and body) for all commits
[x] have appropriate tags applied

Build fails but in the search service because of the spring failure.
[ERROR] Failed to execute goal on project opencast-search-service-impl: Could not resolve dependencies for project org.opencastproject:opencast-search-service-impl:bundle:9-SNAPSHOT: Failed to collect dependencies at org.jdom:com.springsource.org.jdom:jar:2.0.1: Failed to read artifact descriptor for org.jdom:com.springsource.org.jdom:jar:2.0.1: Could not transfer artifact org.jdom:com.springsource.org.jdom:pom:2.0.1 from/to spring.io (https://repo.spring.io/plugins-release/): Not authorized , ReasonPhrase:Unauthorized. -> [Help 1]
[ERROR]

Okay, that's completely unrelated to this patch. Sorry for assuming this would fix the problem reported on list.
Still, those may be easy to fix as well.
I've sent more details to list.
@mliradelc, will you still do the review.
Would be great if this could be merged.
It's already waiting for over a month.

Works good, merged!

Thanks for the review

authors: lkiesow mliradelc


text:
Create Task4.txt

issue:#5
created a directory and a text file inside it. commands used are are in Task4.txt in the week1 folder.

Hey @sanjitha006
Thanks for opening this PR 🚀. Mentor will review your pull request soon and till then, keep contributing and stay calm.
Thanks for contributing in OpenCode'24 ✨✨!

Hey @sanjitha006
Your PR has been merged 🥳🥳 and you have earned 10 points.
Thanks for contributing in OpenCode'24 ✨✨


text:
Create task4.txt

Issue: #5
added code & screenshot

Hey @Suvanwita
Thanks for opening this PR 🚀. Mentor will review your pull request soon and till then, keep contributing and stay calm.
Thanks for contributing in OpenCode'24 ✨✨!

Hey @Suvanwita
Your PR has been merged 🥳🥳 and you have earned 10 points.
Thanks for contributing in OpenCode'24 ✨✨

authors: Opencodeiiita-Bot Suvanwita


text:
Host admins to see hosted accounts activity

Without this check, the feature does not work when selecting specific hosted collectives from the Host Activity log.

Ended up merging a similar fix in https://github.com/opencollective/opencollective-api/pull/8009

repo: opencollective/opencollective-api


text:
Don't use Twitter nick as OC nick

URL: sign-up process
Expected result: a place to choose the short URL for opencollective.com/X and separate place(s) to indicate social media accounts (especially open ones like Mastodon)
Actual result: the only option is Twitter, entering that account causes that to be used as the X for opencollective URL and lists @X on the account page without any reference to that being Twitter specifically.
Things to fix:

indicate on any account page that a link is to Twitter if it is
(temp fix) indicate in the form that the Twitter nick will be used as the OC nick
(real fix) add a new field to choose the OC nick/url
have a new field for Mastodon account and mark that on the profile page

Thanks for your feedback!
Most people are confused by picking up a username. It's a power user feature (that's why Twitter has removed it from their sign up process). That's why we are making a best guest and if the user has a twitter account, we assume that people will want it to be consistent.
People can change that username in the advanced settings when they edit their profile page.
e.g. https://opencollective.com/xdamman/edit#advanced
We show the Twitter logo next to it on the profile page:

Would love to add Mastodon, but also GitHub, Facebook, LinkedIn, etc. as ways to sign up/login and show those accounts on your profile. This is up for someone to grab!

Thanks for the clarifications. Some notes:

incidentally, uBlock Origin (at least with most of the standard lists enabled) blocks the Twitter icon
glad to know the username is editable, but adding a note "this will be used as OC username too, but that can be edited lated", if even as a footnote or hover text or something, that would be nice
Of the things you mentioned for connecting accounts:

Mastodon is actually free/libre/open (FLO)
GitHub, Facebook, LinkedIn, and Twitter are not open, and shouldn't be emphasized as much — certainly do not encourage sign-up / log-in with those, that's full of problems and is an anti-pattern to be avoided.

Missing some precise expectation on what to do here. Can we perhaps track that in multiple issues?

authors: wolftune xdamman znarf

repo: opencollective/opencollective


text:
Support in-kind donations

Add a link to Donations page to add in-kind donations: Name, email, avatar, amount, description.
It creates a Donation on the backend and adds to userGroup.
Note: you might need to generate sponsors and backers from Donations instead of Transactions, with this change.

From Slack:
gusaus 2:42 PM
Is there a way to have an in-kind sponsor (like a hosting company) show up as a sponsor?
2:43
if that makes sense :grinning:
nicobarreto 2:45 PM
@gusaus that’s a good question. I am not sure if we have that functionality yet. Although I can imagine it being used for co-working spaces.
piamancini 2:49 PM
@gusaus we don't support that, because it messes up the backers/sponsors sorting
2:49
we did at one point but we stopped for the moment.
gusaus 2:54 PM
@U0J6D6LV9 I thought that was an option previously - I’m trying to visualize how the sorting would be thrown off. If a company was providing #100/mo hosting, that would mess something up?
piamancini 2:55 PM
because we sort based on the contributions they make
2:55
that 100/month is not a transaction so we can't compute it
gusaus 2:57 PM
right - makes sense

we decided agains this as per @patcon's comment so closing the issue.

authors: asood123 patcon piamancini


text:
Add some helpers to facilitate the release of early access features

We often release features progressively, starting with a few trusted users before we release them to the general public. The way we do that varies from time to time, which causes some problems:

We often rely on account.settings, which is not secure because users can edit this field themselves
These feature flags are rarely cleaned in the database after the releases
They tend to pollute libraries. We, for example, have a settings.features.MULTI_CURRENCY_EXPENSES that is not going to be useful for long

Proposed solution

[ ] These flags ideally should be stored in account.data. In this case, we'll want to expose a earlyAccess string array field on Account. (optional)
To easily enable for a few trusted account, I'd love to see some helpers such as these ones:

[ ] loggedInUser.isEngineer()
[ ] loggedInUser.isSupportStaff() (https://github.com/opencollective/opencollective/issues/4628)
[ ] hasEarlyAccess(account, 'ACTIVITY_LOG')

Implemented in lib/preview-features.ts


text:
PayPal and Stripe New Order Status

For both PayPal and Stripe donations there is a New status that the order goes into when the user first creates the order but before we receive the web-hook response.
There are instances where the order doesn't move away from the New status. An example would be, https://opencollective.com/drupal_gin/orders/790109. This is a confusing situation for the user as they see the order but do not know what this status mean.

Ideally show a different label that makes sense to the user; such as processing
Auto sync from Stripe or PayPal after a few days to update the status as otherwise the order remains in this status forever and doesn't get updated unless manually done so. Alternatively if there's a problem with the order if we could have a notification; an error in Sentry or similar that would be useful to proactively take action as most times we do not know about this until much later the user complains.

For Stripe: https://github.com/opencollective/opencollective-api/pull/10317

This seems to be still occurring on Stripe; for example the order, https://opencollective.com/logseq/orders/796540 😉
cc: @hdiniz

We haven't yet re-enabled the cron job, it's on our Todo for this week

A related side effect due to this issue was reported at, https://opencollective.freshdesk.com/a/tickets/371756

authors: Betree SudharakaP hdiniz


text:
OTG RT2.1: Fix for Retrieving port name using Eth.Connection

"The Connection specification for portName on Ethernet object instead of direct portName" is changed with reference commit id  https://github.com/open-traffic-generator/featureprofiles/commit/04f106f81b85b7060d3c2100e1b397419a97b49d
This PR helps to align with the above commit

Pull Request Test Coverage Report for Build 4182929116

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 57.219%

Totals

Change from base Build 4180461664:
0.0%

Covered Lines:
1181

Relevant Lines:
2064

💛  - Coveralls

Fixes #589

/gcbrun

authors: ANISH-GOTTAPU coveralls michaelore octpetre

repo: openconfig/featureprofiles


text:
Changes for Issue-466. NextHop index as integer string.

Changes for below error hit during get_rpc_test.go script execution -
[InvalidArgument] failed to set .network-instance{.name=="DEFAULT"}.next-hop-groups.group{.name=="oc-static-198.51.100.192/26"}.nexthop{.index==0}.index - Invalid value "AUTO_0": Must be an integer in range 0..65535

Closing as of now due to CLA.


text:
Add packer sleep for initial updates

https://github.com/geerlingguy/packer-boxes/issues/7
hopefully this will reduce build pipeline flakiness

Pull Request Test Coverage Report for Build 3323212406

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 57.509%

Totals

Change from base Build 3322765520:
0.0%

Covered Lines:
2313

Relevant Lines:
4022

💛  - Coveralls

authors: alexmasi coveralls

repo: openconfig/kne


text:
Populate runc4

https://github.com/openconnectome/m2g/blob/disa-dev/MR-OCP/MROCPdjango/ocpipeline/procs/runc4.py

in asana, closing


text:
Check up on maintainers absenteeism and desire to be a maintainer

via @stevvooe :

I think we need to give the current maintainers a chance to respond on the issue of absenteeism.

Hey @opencontainers/image-spec-maintainers if you desire to continue to be a maintainer with the time commitments expected, please let us know. I'll leave this issue open for a couple of weeks to get feedback before we decide to add more maintainers:
https://github.com/opencontainers/image-spec/issues/590#issuecomment-285179960

I'd like to stay involved (and participate more actively, I haven't given a lot of PRs as much attention as I'd like). A significant issue for me has been the weekly call time, but fortunately seems like we're figuring that out in the associated mailing list thread

@jonboulle Thank you for your increased participation!
@caniszczyk I think since we are on track now, we can close this. Any objections? @opencontainers/image-spec-maintainers

@stevvooe SGTM however I think we should consider adding some folks based on their contribution rate by asking if they want to be nominated as a maintainer and assume responsibilities (https://github.com/opencontainers/image-spec/issues/590#issuecomment-285109834) but I leave it up to you and the @opencontainers/image-spec-maintainers to decide :)

authors: caniszczyk jonboulle stevvooe

repo: opencontainers/image-spec


text:
media-types: Describe media type conflict resolution

Fill in more generic detail for the advice which was removed in #392.

LGTM

lgtm

authors: jonboulle philips wking


text:
Add Anchors to Runtime Spec

By adding anchors to the spec, we enable tools to reference specific spec sections, sub-sections, bullets, list items, etc.

[x] bundle.md #612
[ ] config-linux.md #635
[x] config-solaris.md #636
[x] config-windows.md #637
[ ] config.md
[x] glossary.md #638
[x] principles.md #639
[x] runtime-Linux.md #640
[ ] runtime.md #614
[ ] spec.md
[ ] style.md

@RobDolinMS do you have PRs for the remaining anchor adds? If not and this is something we still need, I'd be willing to whack them up.

On Wed, Nov 30, 2016 at 03:09:59PM -0800, Rob Dolin (MSFT) wrote:

By adding anchors to the spec, we enable tools to reference specific
spec sections, sub-sections, bullets, list items, etc.

Should we re-open this?  For example, #614 was adding anchors to
runtime.md bullets 1 so you could link to specific properties
(e.g. 2).  #614 was closed because it needed a rebase and the
sign-off was broken 3, and then this issue was closed by #707, which
added anchors to the sections 4, but not to bullets and list items.
So there's currently no way to link to the ociVersion entry in the
state JSON declaration outside of GitHub's blame UI 5.

authors: RobDolinMS jlbutler wking

repo: opencontainers/runtime-spec


text:
Update 2020-03-15.yaml

Apparemment c'est au 18/03, 5 cas guéris et non 3. Source prefecture : https://twitter.com/Prefet973/status/1240002935863508993

Je ne suis pas sûr de comprendre : tu souhaites modifier des données du 15/03 de l'ARS de Guyane par des données du 17/03 données par la préfecture ?

Il y a un dossier dédié sur ce dépôt pour les données prefecture : le bien nommé /prefecture ! On pourrait y créer un fichier 973/2020-03-17.yaml pour y ajouter le nombre de guéris.

Oui très bien. Comme il n'y avait pas la variable gueris dans le dossier /prefecture, et que les communications de la préfecture sont nourries des données de l'ARS, je ne savais pas trop comment représenter ça. (d'autant que les données de personnes guéries ne sont pas affichées pour l'instant sur le dashboard, mais elles sont néanmoins utiles) Mais créons donc ce fichier yaml dans le dossier /prefecture, ça sera plus clair !

Salut @ColinMaudry, j'ai pas trop suivi cette PR. Il faut la merger ? La fermer ?
Merci d'avance :wink:

On peut fermer. Si @cecilaki le souhaite elle peut en réouvrir une avec un fichier préfecture.

Oui très bien, je ferai ça à l'avenir, avec les bonnes variables !

authors: Binnette ColinMaudry cecilaki jdesboeufs


text:
Permissions for new users

I hosted a cvat instance and saw that anyone can sign up as a new user and create tasks. How can I
a) disable sign-up (so new users have to be created by admin)
b) not add new users to group "user" so they have no permissions?
As a workaround I could change the rules in OPA for "user", but I hope there is an easier way of achieving this.

Dublicate of #1283

Thanks, I tried their workaround setting up email-verification. It works, but I think the error message should be adapted for that solution.
Is there another solution for workaround b)?
I also tried changing the auth.csv (https://github.com/opencv/cvat/blob/develop/cvat/apps/iam/rules/auth.csv) Priviledge for /auth/register to Admin, but that did not result in any change.

@ninafiona , I will close the issue as a duplicate

https://github.com/opencv/cvat/issues/1283

authors: bsekachev ninafiona nmanovic

repo: opencv/cvat


text:
Added instructions how to deploy CVAT behind a proxy

Added instructions how to deploy CVAT behind a proxy
Motivation and context
Some users have experienced issues when deploying CVAT with serverless functions behind a proxy. This PR should simplify the process.
How has this been tested?
Manually
Checklist

[x] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG file
[x] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] 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.
[ ] I have updated the license header for each file (see an example below)

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

Pull Request Test Coverage Report for Build 6858

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.005%) to 68.938%

Totals

Change from base Build 6850:
0.005%

Covered Lines:
11129

Relevant Lines:
15658

💛  - Coveralls

authors: azhavoro coveralls


text:
Misc minor bugfixes: css, js, readme

All trivial, but have built up in my branch. See the individual commit messages.

Coverage decreased (-0.9%) to 88.813% when pulling 0b740e42d26404de7709f4744132465f8f84bb5e on jeremyh:develop into 8a82d2db1f84209611e61bf71e5d1a986384da4a on opendatacube:develop.

authors: coveralls jeremyh

repo: opendatacube/dea-dashboard


text:
Strip core dependencies

Strip out all dependencies on datacube-core.
Had to copy across some utils code (and switch to odc-geo).  The copied code is all marked # TODO CORE so core can be refactored to use these implementations, and otherwise cleanup.
Still a lot of higher level functionality to strip out, so some of the duplicated code from core may be able to be removed later.

Damn did it again.

repo: opendatacube/eo-datasets


text:
Dependencies missing from requirements.txt

Fastscore-CLI depends on "tabulate" and "websocket-client", which are missing from requirements.txt

Seems to be fixed

repo: opendatagroup/fastscore-cli


text:
Delete the deployment at the end of test, allow using upon-end parameter to "stop" or "keep".

Description

Clean up after the setup, delete the deployment at the end of test.
Allow using upon-end Pipeline parameter to stop or keep, apart from the default delete.
Based on information in https://github.com/opendatahub-io/ai-edge/pull/119#issuecomment-1749253767.
How Has This Been Tested?

Manually.
Merge criteria:

[x] 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

Now that https://github.com/opendatahub-io/ai-edge/pull/119 was merged, added update of the pipelines/README.md.

LGTM feel free to merge unless @devguyio still has some qualms

Thanks, merged.

authors: adelton piotrpdev

repo: opendatahub-io/ai-edge