Package duplicated by different cataloger

What happened:
Scanning almalinux:latest image with various tools to compare the generated SBOM. At first sight Syft sounds better as total number of identified components was greater. But... making a deeper analysis showed that Syft had identified the same packages from rpm and from python.
Example Rpm cataloger finding:
   "name": "libcomps",
   "version": "0.1.16-2.el8",
   "type": "rpm",
   "foundBy": "rpmdb-cataloger",
   "locations": [
    {
     "path": "/var/lib/rpm/Packages",
    }
   ],
   "licenses": [],
   "language": "",
   "cpes": [
    "cpe:2.3:a:almalinux:libcomps:0.1.16-2.el8:*:*:*:*:*:*:*",
    "cpe:2.3:a:libcomps:libcomps:0.1.16-2.el8:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:rpm/almalinux/libcomps@0.1.16-2.el8?arch=x86_64&upstream=libcomps-0.1.16-2.el8.src.rpm&distro=almalinux-8.5",

Example Python Cataloger finding:
   "name": "libcomps",
   "version": "0.1.16",
   "type": "python",
   "foundBy": "python-package-cataloger",
   "locations": [
    {
     "path": "/usr/lib64/python3.6/site-packages/libcomps-0.1.16-py3.6.egg-info",
    }
   ],
   ],
   "licenses": [
    "GPLv2+"
   ],
   "language": "python",
   "cpes": [
    "cpe:2.3:a:rpm_software_management:python-libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm_software_management:python_libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm_software_management:libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python-libcomps:python-libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python-libcomps:python_libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python_libcomps:python-libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python_libcomps:python_libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm-ecosystem:python-libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm-ecosystem:python_libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm_ecosystem:python-libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm_ecosystem:python_libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:libcomps:python-libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:libcomps:python_libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python-libcomps:libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python_libcomps:libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python-libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:python_libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm-ecosystem:libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:rpm_ecosystem:libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:libcomps:libcomps:0.1.16:*:*:*:*:*:*:*",
    "cpe:2.3:a:python:libcomps:0.1.16:*:*:*:*:*:*:*"
   ],
   "purl"<EMAIL_ADDRESS>    "license": "GPLv2+",

In fact this python package is delivered by above rpm so shall point to the same.
What you expected to happen:
In fact I am not sure if this is a good or bad to have duplicate for the same. Note that purl/cpe are different.
Searching on NVD https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=libcomps
the CPEs are only rpm based cpe:2.3:a:rpm:libcomps:.... Thus we may think that only rpm is necessary. Maybe a way to reduce the findings when one also belongs to another packager could be provided.
How to reproduce it (as minimally and precisely as possible):
docker run \
            --rm \
            -it \
            -v /var/run/docker.sock:/var/run/docker.sock \
            -v $PWD:/tmp/workdir \
            anchore/syft:latest \
            -v \
            packages \
            -s Squashed \
            -o json \
            --file /tmp/workdir/bom.json \
            docker:almalinux:latest

Anything else we need to know?:
Environment:

Output of syft version: 0.38.0 (and same result with 0.42.4)
OS (e.g: cat /etc/os-release or similar): N/A

Hi @WhyJee, good eye! The short answer is: this is known behavior. And you're right about rpm superseding here.
Syft's philosophy is to surface as much data as it's aware of. And in this case it found evidence of a Python package and also of an RPM package.
But Syft also is aware of the relationship between these two packages. For this "libcomps" example, you should see an item in the "artifactRelationships" array (in Syft's JSON output) that looks kind of like this:
{
  "parent": "f3a95e529e656bd7",
  "child": "56567855bd1c8c05",
  "type": "ownership-by-file-overlap",
  "metadata": {
    "files": [
      "/usr/lib64/python3.6/site-packages/libcomps-0.1.16-py3.6.egg-info"
    ]
  }
}

This way, if a consumer of this data wanted to, they could intentionally and explicitly filter out child packages that are part of ownership-by-file-overlap relationships (e.g. the Python package in your example).

Maybe a way to reduce the findings when one also belongs to another packager could be provided.

I think this is a great idea for a new feature. As we saw above, Syft already has the data needed to do this. It would just need to expose the filtering functionality via a CLI flag or something.
How does that sound?

@luhring so it seems that the feature (or part of it) is already there. It is more a matter of SBOM processing in order to "minimize" it.
Now we may say we do have two use-cases:

opensource packages an opensource component (case above) : libcomps rpm delivers libcomps python module
I package some opensource components that are dependencies of my product (to ease customer deployment for instance)

In case 1. you may want to eliminate one of the two (which one is another story but normally you shall pick the englobing package).
In case 2. I may be interested to eliminate my package and keep only what it delivers. So in that case I need to find the Id of my package to remove it or not. But If I have a standard cleanup mechanism I will need to have a way to indicate do not remove the child (X,Y,Z, ...).
But in any case, we may say that ball is in the end of the SBOM consumer (and not producer -- here Syft).
Note that the picture is probably more complex as there are more relationship that we (I) may want to see in a SBOM.
Let's take an example:

for some reason, I have have forked an opensource component
I package it also

So we may have in the end something as (not complete picture as I may have forgotten other relationship types):
graph TD
    R1[pkg:rpm/myRpm-1.2.3] --> |delivers| P1
    R1 --> |requires| R2[pkg:rpm/python-3.y.z]
    P1[pkg:pypi/myMod-2.3.4] --> |derivesFrom| P2
    P2[pkg:pypi/aMod-4.5.6] --> |dependsOn| P3
    P3[pkg:pypi/otherMod-7.8.9]

There is a simpler case where you did not rename the module but just override the version such as aMod-4.5.6-mybranchonmyfork.
This implies that :

in myMod I have put necessary data so that the scanner is able to generate the whole graph
a vulnerability scanner is able to read the graph and gives me warning (or indication) of potential vulnerabilities in the module I derived from. myMod being eventually a private module it will surely not be known by vulnerability DB so this processing is interesting to have.

Thanks for the thoughtful depiction here! I think I'm following.
So it sounds like the actionable piece of this is that there are two potential feature enhancements we could add to Grype (the vulnerability scanner companion to Syft).

Provide a way to tell Grype to ignore "contained" (using the nomenclature from your graph above; in Syft, we call this ownership-by-file-overlap) dependencies (but probably not their dependencies?) while finding vulnerability matches.

Provide a way to tell Grype to ignore specific "containing" (e.g. pkg:rpm/myRpm-1.2.3 from your graph) packages, and to instead consider their child nodes to be roots in the graph (as if they had never been repackaged by you in the first place).

Does this align with your thinking?

Also just quick notes: @WhyJee would you be ok with me updating the issue name to reflect the new enhancement here?

@spiffcs sorry for the delay. I was on trip and then got too much involved in day to day activities.
So yes agree to update the issue.

@luhring I believe there could be some enhancements in Syft side either.
I would see its logic in a multistage pattern:

Stage 1 : use OS package manager (here rpm) to identify a bunch of stuff

Stage 1.1 : remove from the file list every file owned by a package, except if indicated modified by the package manager (typically what rpm verify indicates)

Stage 2 : execute all other known package managers (option to skip may be provided -- would probably an overkill as I don't see real use case)

Stage 2.1 : same removal rule as 1.1

Stage 3 : based on some "file" DB, try to infer where they come from...

With this type of logic you can also assess the score of the findings:

Stage 1 or 2 and package clean = highest
Stage 1 or 2 and package dirty = high with warning
Stage 3 = from low to moderate

Regarding Grype enhancement, sounds both make sense. For 1. people using such option shall be aware that if vulnerability database use consistent package identification (the contained or the container) the final VEX may miss some vulnerabilities. Put pb is more on vulnerability identifier than on SBOM.

An example of the consequence of this behavior in another context. An image is scanned with Syft and the generated SBOM is pushed to a vulnerability tool.
The image contains the rpm package python3-rpm which leads in the SBOM to 2 entries:

rpm

Name : python3-rpm
Version: 4.14.3-23.el8

python

Name: rpm
Version: 4.14.3

CVE-2021-3421 is reported against this product for the 2nd item (Python) whereas it is fixed as per RHSA-2021:2574 - Security Advisory  since version 4.14.3-14.
The consequence is more "manual" validation for developers to assess these false positive vulnerabilities.

@luhring I have the same issue, but with different catalogers (binary and sbom), and in this case there is no direct relationship between them...
syft packages -o json docker.io/bitnami/redis@sha256:d06075921a96f3ccc3d2567230f6d22575ff65c1a8e8c0ce55717aaa8719b41f

Will detect "Redis" and "redis" with respectively the binary-cataloger and the sbom-cataloger:
   "id": "daf59709b31d2efc",
   "name": "redis",
   "version": "7.0.11",
   "type": "binary",
   "foundBy": "binary-cataloger",
   "locations": [
    {
     "path": "/opt/bitnami/redis/bin/redis-server",
     "layerID": "sha256:6b9f25067a7386027c0290ec0845fe0f246fd5782d3cb1852d43d3bdf687a7c5"
    }

   "id": "75918b40c8383df",
   "name": "Redis",
   "version": "7.0.11",
   "type": "",
   "foundBy": "sbom-cataloger",
   "locations": [
    {
     "path": "/opt/bitnami/redis/.spdx-redis.spdx",
     "layerID": "sha256:6b9f25067a7386027c0290ec0845fe0f246fd5782d3cb1852d43d3bdf687a7c5"
    }

However there is no relationship between them... how should I filter these?
Thanks for your support.

cc: @wagoodman

@matthyx I'm not certain in the specific case you brought up that there is enough information from syft's perspective to know that these are two different redis packages. That is, name and version might not be enough information in all cases, to create a relationship we need one package to claim ownership of a location that another package was defined by. For instance, a package found in an RPM DB lists out all files owned by a package... if that package is a python wheel, then the python cataloger will also pick up on it. The key to knowing if the packages describe the same thing is if the RPM file ownership locations overlap with the python package evidence locations, in this case a python wheel metadata file -- the we'd be able to determine there is some overlap in ownership.
Even though you provided a small snippet, the binary and sbom catalogers today do not list out owned files from packages they raise up, so it isn't possible yet to create ownership overlap relationships for these two packages.

@wagoodman alright... so there is nothing we could do in that particular case (and other similar ones).
Thanks for your investigation and for the great product 👍

Popping off the stack some, ideally syft does persist all information found for packages discovered. However, that goal might not be mutually exclusive to merging packages together (slightly different than deduplicating, which may be lossy to the full set of data on a package object). I feel that such an approach probably has tradeoffs.
Today the syft package data model allows for a package to be found by a single cataloger and for tailored metadata to be persisted in the .metadata field:
{
  "id": "83df403875b8c91",
  "name": "curl",
  "version": "8.2.7",
  "type": "binary",
  "foundBy": "binary-cataloger",
  "purl"<EMAIL_ADDRESS>  "metadata": {
    "matches": [
      {
        "classifier": "curl-binary",
        "location": "..."
      }
    ]
  }
}

(omitting a few things...)
But if we wanted to merge this definition with the dpkg one:
{
  "id": "413d8f5b0378c98",
  "name": "curl",
  "version": "8.2.7",
  "type": "dpkg",
  "foundBy": "dpkg-cataloger",
  "purl"<EMAIL_ADDRESS>  "metadata": {
    "architecture": "x86-86",
    "installedSize": 8392,
    "maintainer"<EMAIL_ADDRESS>  }
}

... we'd be out of luck, since there are several singular fields that have different values, thus you'd need to drop one. But if the package object were modified to allow for merging logical packages found in different ways, then it would be possible:
{
  "name": "curl",
  "version": "8.2.7",
  "data": [
    {
      "id": "83df403875b8c91",
      "type": "binary",
      "foundBy": "binary-cataloger",
      "purl"<EMAIL_ADDRESS>      "metadata": {
        "matches": [
          {
            "classifier": "curl-binary",
            "location": "..."
          }
        ]
      }
    },
    {
      "id": "413d8f5b0378c98",
      "type": "dpkg",
      "foundBy": "dpkg-cataloger",
      "purl"<EMAIL_ADDRESS>      "metadata": {
        "architecture": "x86-86",
        "installedSize": 8392,
        "maintainer"<EMAIL_ADDRESS>      }
    }
  ]
}

There are some important things to note with this hypothetical object. Today nodes in the graph are package objects, which is relatively simple. With this new approach the evidence array elements would be nodes in the graph, not the logical package. Why? We don't know if there are multiple dependency graphs in the greater SBOM being explained, where each node would be a part of a different dependency graph... making the logical package the node represented in the graph means that we'd be effectively merging currently separate dependency graphs. It's ok if the two separate evidence nodes are related across the two dependency graphs, as long as that relationship is not expressed as a dependency.
This new hypothetical object also makes it a little harder for consumers to use the data. Instead of a small jq command to understand answers to simple questions (what is the type of package name==x? jq .artifacts[] | select(.name ==  x)) you'd need to start writing larger scripts to reconcile fields with multiple values (find the logical package name x, iterate over .data, find all .type fields and return the array). Where today you get 0 to 1 values, with this new approach you get 0 to many values.
Popping out of the hypothetical package object example... I still think the default behavior of syft should raise all of the raw information as possible, but I think there is room for allowing for opt-in filtering or deduplication logic. (needs more thought though...)

cc: @slashben

We've had some internal discussion regarding the correctness of overlapping packages in an SBOM so I wanted to get the ball rolling on this thread for what this kind of opt in filtering enhancement would look like if we were to add it to the syft tool.
Just to set a baseline, we are NOT talking about how to enhance the current SBOM for downstream tooling like grype. We're discussing opt-in behavior for syft (non default flag or config) where it filters and decides a winner between packages that overlap via the ownership-by-file-overlap relationship, but contain conflicting information.
Feature
Before generating the SBOM, if syft detects a difference between the two package's information that are related via the ownership-by-file-overlap relationship`, it will use some context or rule set provided by the user to eliminate the "incorrect" package.
Current Default State
The current philosophy for package overlap is as follows (chime in @anchore/tools if any of this seems wrong):
syft stays out of making filtering decisions be default
it instead raises enough information so that downstream tooling
can try and make the right decision between packages for their use case

The above is in place because it's currently not clear 100% of the time that some other cataloger (SBOM, binary, ecosystem, etc) will be wrong relative to an OS-package cataloger. There is no one size fits all cataloger hierarchy.
Said another way, Syft currently has no mechanism for assessing correctness between two catalogers output if a conflict in package information arrises, but ownership-by-file-overlap relationship is present.
Consider the following case of two packages:
{
  "id": "83df403875b8c91",
  "name": "curl",
  "version": "8.2.7",
  "type": "binary",
  "foundBy": "binary-cataloger",
  "purl"<EMAIL_ADDRESS>  "metadata": {
    "matches": [
      {
        "classifier": "curl-binary",
        "location": "..."
      }
    ]
  }
}

{
  "id": "413d8f5b0378c98",
  "name": "curl",
  "version": "8.2.7-rc1",
  "type": "dpkg",
  "foundBy": "dpkg-cataloger",
  "purl"<EMAIL_ADDRESS>  "metadata": {
    "architecture": "x86-86",
    "installedSize": 8392,
    "maintainer"<EMAIL_ADDRESS>  }
}

These packages have the following relationship:
{
  "parent": "413d8f5b0378c98",
  "child": "83df403875b8c91",
  "type": "ownership-by-file-overlap",
  "metadata": {
    "files": [
      "/usr/bin/local/curl"
    ]
  }
}

In the default SBOM - syft would surface both packages given the conflicting information. One of these packages would turn out to have incorrect version information upon investigation, but there is not current rule to say always take OS packages over binary given a conflict or vise versa.
Way forward
The thread is open for discussion on design/implementation on how we can best build this more advanced context into syft's current mechanisms so that users have more agency over filtering the SBOM they create.
I'll follow up with my own proposal separate to this framing comment so that we can keep problem/solution discussion separate.

As this is related to https://support.anchore.com/hc/en-us/requests/4315 I was hoping you could tell me when this Issue is planned to be worked on?  If the ownership-by-file-overlap tag is already present, it seems like a solution is already at hand - let users decide which order to prioritize package cataloger discoveries (which takes precedent).
I can say from my experience, binary detections should always be at the bottom - they have the least accurate information.  Merging/de-dupping/otherwise removing the binary component is not a 'lossy' action, it's just a bad detection - the version is purely wrong.  It may be the upstream version, but that doesn't make it correct for the package as distros frequently apply patches and change the release string, which changes the component version.  The package manager manifest has the correct information for that component, and where you know there is a relationship between the two components (shared files list for example from the package manager metadata, e.g. /var/lib/dpkg/info/<package_name>.list), you should delete the bad detection in favor of the correct information from the package manager.

Hey @christinahaig! Thanks for following up here -
The solution of:
Let users decide which order to prioritize package cataloger discoveries (which takes precedent).

Is a great suggestion.
My thoughts here are adding a few things to the syft configuration that help accomplish this.
The first pass would just be:
remove-packages-by-overlap: true

This would allow syft to prune the generated SBOM before it's output much in the same way that https://github.com/anchore/grype already filters packages using the ownership-by-file-overlap
A follow up to that would be what you suggested - where a cataloger precedence construct is added that the user can configure. This one needs a bit more design work as the catalogers are hierarchical by convention only right now. They would need some kind of additions or alterations that allow a user configuration to hook into / identify cataloger "types" (binary, distro, package manager etc) that could be assigned a precedence.

I'm starting to see the case for why a binary package in particular should probably not be included if there is an owning package... since the "binary packages" were entirely synthesized by syft. That may call for excluding them by default.

Let users decide which order to prioritize package cataloger discoveries (which takes precedent).

This resonates with me too. Here's an option of what that might look like in syft configuration:
drop-packages-with-ownership-overlap:
  - parent-type: class:os
    type: binary

Where class:os is short hand for ["apk", "alpm", "rpm", "dpkg", "portage"], so the full expression would be:
drop-packages-with-ownership-overlap:
  - type: binary
    parent-type:
    - "apk"
    - "alpm"
    - "rpm"
    - "dpkg"
    - "portage"

This could be the default configuration. However, we could allow for simple expressions like:
drop-packages-with-ownership-overlap:
  # drop any python package that is owned by an RPM package
  - parent-type: rpm
    type: python

Alternatively we could allow for something as agnostic as dropping packages based off of more generic criteria:
drop-packages:
  - relationship-type: ownership-by-file-overlap
    parent-type: class:os
    type: binary

But this is really starting to get into something like https://github.com/anchore/syft/issues/31 ... but I'd like to avoid this since
#31 is really about how to apply hints for a specific image, and this issue is really about ignoring a class of packages based on structural elements, regardless of the specifics of an image.

One thing that I feel is unanswered is should we be looking at exclusively the relationships and package types? Or should there be more to match on in order to drop a package? For instance, what if an OS package contains multiple binaries, should we suppress the binary packages then? Or what if a binary contained within an OS package does not logically represent the same package name as the OS package name (e.g. an RPM for web-app contains the php binary)... should we be trying to fully or partially ensure that the binary found logically represents the OS package?

 For instance, what if an OS package contains multiple binaries,
should we suppress the binary packages then?

This is a great point! Here are a list of other fields we can match on to make this more exact. The current implementation on #1948 is very bare bones in that a match will be excluded based on the relationship only.
Name
Version
FoundBy
Locations
Licenses
Language
Type
CPE
PURL

There was a suggestion in another issue that PURL could be a candidate to consider here. I do know that Version is sometimes unreliable here in that since syft is constructing binary packages the Version might not always match what exists from the OS cataloger:
Example:
busybox                 1.36.1       binary
busybox                 1.36.1-r0    apk

Other consideration:
Or what if a binary contained within an OS package does
not logically represent the same package name as the OS package name

^ My Opinion: A binary that is linked to an OS package with the ownership-by-file-overlap relationship should not be removed if they have different names

I suspect that's not going to work particularly well because the package manager names will often not match the syft constructed names (for instance python vs python3).

agreed that a specific approach would be needed (we can look for partial matches or similarity).
The higher level question is should we be trying to determine if the binary package is bring represented by the OS package? or not try and detect this? I feel that not accounting for this will filter out packages that should remain in the SBOM.

@christinahaig -  we just merged #1948 and it should go into the next syft release - feedback is always welcome and we hope that this new default configuration reduces the noise you were seeing when synthetic packages were incorrectly constructed and had a valid OS overlap =)


Injected Redirect Fails

I am attempting an oauth2 authorization for a project management system API, Everything seems to be functioning properly, until I get to the end of the injected JS.
When changing window.location to "redirect+params", it opens "about:blank" instead of "oauth2.html."
Of course this means the the process never truly finishes and I can not access the api.
If I console.log the redirect+params, I can click it in the console and it finishes properly.
Has anyone else seen this issue?
on Chrome Version 51.0.2704.106 (64-bit) in Ubuntu 14.04

This was a chrome extension security thing. I had to give the browser window access to the finish page in my extension by adding
"web_accessible_resources": ["oauth2/oauth2.html"],
to my manifest.json


Github User Search [GSSOC'23]

Describe the project you want to add with tech stack
Github User Search
Tech stack : React.js
Expected behavior
Once the results are fetched, we'll see how to display all the relevant info such as their name, avatar, and a link to go to their profile

Sir @pranjay-poddar @MohitGupta121 @TusharKesarwani sir , please assign me this issue under GSSOC'23.


Text is shown in a single line and changes on double click on Excel macOS and Excel Windows

\n and \r\n don't actually break in Excel on Mac at least.

Making text wrap work involves generating special styles, a feature present in our Pro compendium


fix icon cut off on safari

What does this PR do and why?
Fixed icons getting cut off in safari, need to post a before and after image confirming fix

Confirm items aren't cut off in the deploy preview on safari, firefox, chrome.
https://github.com/jbx-protocol/juice-interface/issues/1298
Would you mind if I merge with graphite after LGTM?
Screenshots or screen recordings
TODO will add
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] I have tested this PR in all supported browsers.
[ ] I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #1557

PR #1558   👈

This comment was auto-generated by Graphite.

Great catch @benschac LGTM!


can only concatenate str (not "NoneType") to str

Got this on the /db/-/assistant page:

I'm going to add tests to ensure this doesn't happen again.

That didn't actually fix it, at least not for POST.


Update README.md: Rename fs section

...to "filesystem"

Thanks!

Thank you! Incredible project 😎.


[Issue] Federated credential is set only on main (not other branches)

[X] Make sure you've installed the latest version using instructions in the wiki

Output from azd version
azd version 1.0.2 (commit 145e046b1ea9394bd4e1b1d539eb32e860d692fb)
Describe the bug
To test my azd workflow, I set the push to include my testing branch (cicd). However, when I do that, I get an error:
AADSTS70021: No matching federated identity record found for presented assertion. Assertion Issuer: 'https://token.actions.githubusercontent.com/'. Assertion Subject: 'repo:pamelafox/sample-app-aoai-chatGPT:ref:refs/heads/cicd'. Assertion Audience: 'api://AzureADTokenExchange'. https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation\r\nTrace ID: fcbeda46-d5f3-48c6-9058-84408cf47600\r\nCorrelation ID: 031d62c7-6267-4c89-aa09-64364f3235c8\r\nTimestamp: 2023-06-16 16:38:31Z",
I realized that's because the federated credentials are only set up for the main branch and pull_request, per:
https://github.com/Azure/azure-dev/blob/f84dbd154d5b12ce58ff1d475f29d063d9f6cdb9/cli/azd/pkg/pipeline/github_provider.go#L621
So I adjusted my workflow to include pull_request to get it working.
To Reproduce
Change azure-dev.yaml to include a non-main branch, push to that branch, see error.
Expected behavior
I was hoping it'd work. Maybe the code could check azure-dev.yaml to decide what to make credentials for? If not, maybe it could let the user know that it'll only work on main/pull_request.
Environment
CI/CD server, VS Code

@wbreza can we infer other non-main branches and make it work?

@wbreza can we infer other non-main branches and make it work?

@rajeshkamal5050
Federated credentials require specifying branch name when creating the credential.  We have a few options:
If new branches are created after running azd pipeline config azd doesn't know these branches exist

Offer new flag on azd pipeline config to specify a branch_name that can be used
Scan for all branches on the repo and create credentials for each
User can manually update federated credentials in the Azure portal

Out of the above options I believe option 1 would provide the most value. Otherwise user can workaround this issue with option 3.

@wbreza , when creating the ref-cred, azd should use whatever branch is currently the output of git status, as that's the branch that is likely to be pushed.
We should not be hardcoding main

Agreed we can do better than hardcoding main.  I think that part of the issue is knowing that the credentials that are generated at the time of the command are only good on the branch that was initially pushed and that other/new branches will fail.

Hm, from a user perspective, I think I was hoping I could set it up from my testing branch, and then once it worked, I'd delete testing branch from the workflow file and leave it as main (or whatever is the prod branch name).

Hm, from a user perspective, I think I was hoping I could set it up from my testing branch, and then once it worked, I'd delete testing branch from the workflow file and leave it as main (or whatever is the prod branch name).

From a usability perspective that request makes total sense.  Based on the GitHub -> Azure docs around federated identity it unfortunately requires specifying an Entity to create the subject claim for the underlying OIDC request.
The Entity can either be an environment, branch, pull request or tag.  Today we use main branch as the default but once we better support GitHub environments (#2373) I could see this becoming easier.  Any branch then targeting the same azd environment name could share the same the same federated identity.

Related: https://github.com/Azure/azure-dev/issues/2040


estraverse-fb missing

I just downloaded, installed and attempted to run 2.0.0-alpha.1.  "npm start" complained that estraverse-fb was missing.  I did a save-dev install of estraverse-fb, and now all appears to be fine.  I see no errors in the "npm install" log, and no references to estraverse-fb.

Are you on npm2 or 3?
Sent from my iPhone

On Mar 5, 2016, at 12:29 AM, Ed Staub<EMAIL_ADDRESS>wrote:
I just downloaded, installed and attempted to run 2.0.0-alpha.1. "npm start" complained that estraverse-fb was missing. I did a save-dev install of estraverse-fb, and now all appears to be fine. I see no errors in the "npm install" log, and no references to estraverse-fb.
—
Reply to this email directly or view it on GitHub.

same error for me. I'm on:  npm -v ==> 3.3.12
save-dev for estraverse-fb worked as reported by @estaub

I’m on NPM 3.3.6.
From:  David Zukowski<EMAIL_ADDRESS>Reply-To:  davezuko/react-redux-starter-kit<EMAIL_ADDRESS>Date:  Saturday, March 5, 2016 at 7:20 AM
To:  davezuko/react-redux-starter-kit<EMAIL_ADDRESS>Cc:  Ed Staub<EMAIL_ADDRESS>Subject:  Re: [react-redux-starter-kit] estraverse-fb missing (#629)
Are you on npm2 or 3?
Sent from my iPhone

On Mar 5, 2016, at 12:29 AM, Ed Staub<EMAIL_ADDRESS>wrote:
I just downloaded, installed and attempted to run 2.0.0-alpha.1. "npm start" complained that estraverse-fb was missing. I did a save-dev install of estraverse-fb, and now all appears to be fine. I see no errors in the "npm install" log, and no references to estraverse-fb.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

Guessing this is a breaking change from one of our dependency's dependencies, since I don't recognize this package at all.
Sent from my iPhone

On Mar 5, 2016, at 12:35 PM, Wayne K. Walrath<EMAIL_ADDRESS>wrote:
same error for me. I'm on: npm -v ==> 3.3.12
save-dev for estraverse-fb worked as reported by @estaub
—
Reply to this email directly or view it on GitHub.

I think it's probably this: https://github.com/eslint/eslint/issues/5476

I just installed it without saving to package.json. Seems to be about eslint, like @estaub just mentioned.

err, same issues here.
Cannot find module 'estraverse-fb'
at Function.Module._resolveFilename (module.js:339:15)
at Function.Module._load (module.js:290:25)
at Module.require (module.js:367:17)

It's not an issue with this starter kit but a related dependency. I'm away on vacation and unable to submit a patch, so I suggest installing locally as a temporary solution or waiting for the appropriate babel/eslint fix since that's the cause, unless you'd like to submit a PR.
Sent from my iPhone

On Mar 6, 2016, at 4:20 PM, Tony Tai Nguyen<EMAIL_ADDRESS>wrote:
err, same issues here.
Cannot find module 'estraverse-fb'
at Function.Module._resolveFilename (module.js:339:15)
at Function.Module._load (module.js:290:25)
at Module.require (module.js:367:17)
—
Reply to this email directly or view it on GitHub.

+1
I resolved it by installing it afterwards.

This is an issue with babel-lint as suggested here: https://github.com/eslint/eslint/issues/5476#issuecomment-192704497
To resolve temporarily consider updating your package.json files and set "eslint": "~2.2.0" as shown by example here.

ty @neverfox

thank you it worked


How to use VPD for classification?

Hi, thanks for open source the code for VPD!
I'm very interested in your work, and I wonder if I can use VPD for zero-shot image classification, here is my plan:

Get embeddings(class_embeddings.pth) for different class labels.
Get the cross-attention map for a given image with c_crossattn(which did not go through a text adapter).
Find the most responsive embedding on the cross-attention map, which is the classification result.

My question is: how to get the logits for each embedding, so I can use softmax to get the prediction score? A code example would be great.
I managed to obtain outs (x_c1, x_c2, x_c3, x_c4) and class_embeddings. What should I do next? Any help would be appreciated.

Hi, thanks for your interest in VPD.
Your idea to perform zero-shot image classification is interesting. However, I think VPD is not suitable for zero-shot inference because it is not a diffusion-based framework anymore. Fine-tuning is required to adapt the pre-trained knowledge to downstream tasks in VPD.
However, there are some recent works that leverage the text-to-image diffusion model for zero-shot image classification, such as https://arxiv.org/abs/2303.15233 and https://arxiv.org/abs/2303.16203. I think maybe these papers are helpful to you. Please feel free to further discussions.

Thank you for your explanation!
I found the papers you mentioned as well. Indeed, they are more related to my problem, but they haven't been open-sourced yet. I will try some experiments with VPD (finetune or zero-shot) and update this thread when I have the results. I'll close the issue for now.
Thanks again, VPD is a great work!


Code Improvement:

Using inline if

Thank you for your effort.
I dont think that there are any peformance gains here, and personally find this to be less readable code.

No problem dude. It is not a performance improvement. It is a personal suggestion to avoid unnecessary lines.
Cheers ;)

Hey so why did this get merged in? There are only performance losses with ternary operators when replacing If/Else blocks in Javascript, and I don't find this to be more readable code.
@anonrig can you give some context to your choice here?


Removed compiler warnings [-Wself-assign] for a cleaner build output …

I added an UNDEFINED(X) macro in the single file that produces [-Wself-assign] warnings at build time.
This removes the false sense of something being wrong; the sentiment in the code is clear and perfectly legitimate. However, some build processes take output as a sign of weakness or failure!

I've applied your patch.

Thanks. It's one of the most comprehensive libraries I think I've ever seen
and used. I wonder how I managed without out it, it has made dealing with
RabbitMQ messages an absolute pleasure.
Thanks for bstrlib!
On 25 January 2016 at 17:17, websnarf<EMAIL_ADDRESS>wrote:

I've applied your patch.
—
Reply to this email directly or view it on GitHub
https://github.com/websnarf/bstrlib/pull/9#issuecomment-174590907.


Serving when use category features

Summary

Motivation

Description
when I use category features in training, how do i use them while serving, I just set features as category features in training.

References

It should be enough. Indices of categorical features are saved into model.


Write a Haskell program to find surface area of a cone

Description
Write a Haskell program to find surface area of a cone
Surface area of cone = π × Radius × (Radius + Slant Height)
Radius       : 2
Slant Height : 3

Surface area : 31.4

How to contribute

Save the solution in program/find_surface_area_of_a_cone.hs file
Add find_surface_area_of_a_cone.hs file in find-surface-area-of-a-cone folder

!assign


Create class with ssh session as a property

Remove need to keep calling ssh.getSSH

Create in WrdsSession, passed to the query directly now.


[Bug]: Additional dimension for lat_bnds and lon_bnds

What happened?
When I load data with xcdat, sometimes it generates additional dimensions for lat_bnds and lon_bnds. An example code is here:
MIROC_cmip_tas = xc.open_dataset('tas/tas_MIROC5_piControl.nc')
MIROC_cmip_tas = MIROC_cmip_tas.sel(time=slice("2100-01-01", "2619-01-01"))
MIROC_cmip_tas = MIROC_cmip_tas.drop_vars('height')
print(MIROC_cmip_tas['lat_bnds'])
print(MIROC_cmip_tas['lon_bnds'])

It generates the following output:
<xarray.DataArray 'lat_bnds' (time: 6228, lat: 132, bnds: 2)>
[1644192 values with dtype=float64]
Coordinates:
  * lat      (lat) float64 -88.93 -87.54 -86.14 -84.74 ... 86.14 87.54 88.93
  * time     (time) object 2100-01-16 12:00:00 ... 2618-12-16 12:00:00
Dimensions without coordinates: bnds

For lon_bnds, an additional latitude dimension is generated.
<xarray.DataArray 'lon_bnds' (lat: 132, time: 6228, lon: 256, bnds: 2)>
[420913152 values with dtype=float64]
Coordinates:
  * lat      (lat) float64 -88.93 -87.54 -86.14 -84.74 ... 86.14 87.54 88.93
  * lon      (lon) float64 0.0 1.406 2.812 4.219 ... 354.4 355.8 357.2 358.6
  * time     (time) object 2100-01-16 12:00:00 ... 2618-12-16 12:00:00
Dimensions without coordinates: bnds

The situation changes for different files. Sometimes I got (time, lon, bnds) for lon_bnds.
The version of xCDAT is 0.4.0.
What did you expect to happen?
Keep only latitude/longitude and bnds dimensions for bnds variables.
Minimal Complete Verifiable Example
No response
Relevant log output
No response
Anything else we need to know?
 You can skip this check by specifying compat='override'.

See https://github.com/xCDAT/xcdat/issues/162 for more on this.
I think this error arises when the lat_bnds values vary across files, which I suspect may be what is happening here. It looks like the data has been re-saved out in tas/tas_MIROC5_piControl.nc. What does an ncdump -h look like @ShihengDuan?

Here is the output from ncdump -h:
(duan) /home/duan5/ISIMIP/MIROC5/piControl/tas$ ncdump -h tas_MIROC5_piControl.nc
netcdf tas_MIROC5_piControl {
dimensions:
	lat = 132 ;
	lon = 256 ;
	time = 10440 ;
	bnds = 2 ;
variables:
	double lat(lat) ;
		lat:_FillValue = NaN ;
		lat:bounds = "lat_bnds" ;
		lat:units = "degrees_north" ;
		lat:axis = "Y" ;
		lat:long_name = "latitude" ;
		lat:standard_name = "latitude" ;
	double lon(lon) ;
		lon:_FillValue = NaN ;
		lon:bounds = "lon_bnds" ;
		lon:units = "degrees_east" ;
		lon:axis = "X" ;
		lon:long_name = "longitude" ;
		lon:standard_name = "longitude" ;
	double time(time) ;
		time:_FillValue = NaN ;
		time:bounds = "time_bnds" ;
		time:axis = "T" ;
		time:long_name = "time" ;
		time:standard_name = "time" ;
		time:units = "days since 2000-01-01" ;
		time:calendar = "noleap" ;
	double time_bnds(lat, time, bnds) ;
		time_bnds:_FillValue = NaN ;
		time_bnds:coordinates = "height" ;
	double lat_bnds(time, lat, bnds) ;
		lat_bnds:_FillValue = NaN ;
		lat_bnds:coordinates = "height" ;
	double lon_bnds(lat, time, lon, bnds) ;
		lon_bnds:_FillValue = NaN ;
		lon_bnds:coordinates = "height" ;
	double height ;
		height:_FillValue = NaN ;
		height:units = "m" ;
		height:axis = "Z" ;
		height:positive = "up" ;
		height:long_name = "height" ;
		height:standard_name = "height" ;
	float tas(time, lat, lon) ;
		tas:_FillValue = 1.e+20f ;
		tas:standard_name = "air_temperature" ;
		tas:long_name = "Near-Surface Air Temperature" ;
		tas:units = "K" ;
		tas:original_name = "T2" ;
		tas:cell_methods = "time: mean" ;
		tas:cell_measures = "area: areacella" ;
		tas:history = "2011-09-15T06:51:00Z altered by CMOR: Treated scalar dimension: \'height\'. 2011-09-15T06:51:00Z altered by CMOR: replaced missing value flag (-999) with standard missing value (1e+20). 2011-09-15T06:51:00Z altered by CMOR: Inverted axis: lat." ;
		tas:associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: gridspec_atmos_fx_MIROC5_piControl_r0i0p0.nc areacella: areacella_fx_MIROC5_piControl_r0i0p0.nc" ;
		tas:coordinates = "height" ;
		tas:missing_value = 1.e+20f ;

// global attributes:
		:institution = "AORI (Atmosphere and Ocean Research Institute, The University of Tokyo, Chiba, Japan), NIES (National Institute for Environmental Studies, Ibaraki, Japan), JAMSTEC (Japan Agency for Marine-Earth Science and Technology, Kanagawa, Japan)" ;
		:institute_id = "MIROC" ;
		:experiment_id = "piControl" ;
		:source = "MIROC5 2010 atmosphere: MIROC-AGCM6 (T85L40); ocean: COCO (COCO4.5, 256x224 L50); sea ice: COCO (COCO4.5); land: MATSIRO (MATSIRO, L6); aerosols: SPRINTARS (SPRINTARS 5.00, T85L40)" ;
		:model_id = "MIROC5" ;
		:forcing = "N/A" ;
		:parent_experiment_id = "N/A" ;
		:parent_experiment_rip = "N/A" ;
		:branch_time = 0. ;
		:contact = "Masahiro Watanabe (hiro@aori.u-tokyo.ac.jp), Seita Emori (emori@nies.go.jp), Masayoshi Ishii (ism@jamstec.go.jp), Masahide Kimoto (kimoto@aori.u-tokyo.ac.jp)" ;
		:references = "Watanabe et al., 2010: Improved climate simulation by MIROC5: Mean states, variability, and climate sensitivity. J. Climate, 23, 6312-6335" ;
		:initialization_method = 1 ;
		:physics_version = 1 ;
		:tracking_id = "d5a62be5-f4e9-4e63-b63f-5fea30c77a52" ;
		:product = "output" ;
		:experiment = "pre-industrial control" ;
		:frequency = "mon" ;
		:creation_date = "2011-09-15T06:51:00Z" ;
		:history = "2011-09-15T06:51:00Z CMOR rewrote data to comply with CF standards and CMIP5 requirements." ;
		:Conventions = "CF-1.4" ;
		:project_id = "CMIP5" ;
		:table_id = "Table Amon (26 July 2011) 976b7fd1d9e1be31dddd28f5dc79b7a1" ;
		:title = "MIROC5 model output prepared for CMIP5 pre-industrial control" ;
		:parent_experiment = "N/A" ;
		:modeling_realm = "atmos" ;
		:realization = 1 ;
		:cmor_version = "2.7.1" ;

I concatenated all the piControl simulation with the following code:
files = glob.glob('data/tas_Amon_*.nc')
# print(sorted(files))
tas = xa.open_mfdataset(sorted(files))
print(tas)
print(np.unique(tas.time, return_counts=True))
print('Done')
print(len(np.unique(tas.time)))
print(len(tas.time))

tas.to_netcdf('tas_MIROC5_piControl.nc')

I forgot why I didn't do tas=tas.compute() before saving to nc files, but when I add this code, it still shows time dimension. See below:
(duan) /home/duan5/ISIMIP/MIROC5/piControl/tas$ python
Python 3.10.4 (main, Mar 31 2022, 08:41:55) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xcdat as xc
>>> data = xc.open_dataset('tas_MIROC5_piControl_compute.nc')
>>> data['lat_bnds']
<xarray.DataArray 'lat_bnds' (time: 10440, lat: 132, bnds: 2)>
[2756160 values with dtype=float64]
Coordinates:
  * lat      (lat) float64 -88.93 -87.54 -86.14 -84.74 ... 86.14 87.54 88.93
  * time     (time) object 2000-01-16 12:00:00 ... 2869-12-16 12:00:00
    height   float64 2.0
Dimensions without coordinates: bnds
>>> data = xc.open_dataset('tas_MIROC5_piControl.nc')
>>> data['lat_bnds']
<xarray.DataArray 'lat_bnds' (time: 10440, lat: 132, bnds: 2)>
[2756160 values with dtype=float64]
Coordinates:
  * lat      (lat) float64 -88.93 -87.54 -86.14 -84.74 ... 86.14 87.54 88.93
  * time     (time) object 2000-01-16 12:00:00 ... 2869-12-16 12:00:00
    height   float64 2.0
Dimensions without coordinates: bnds
>>>

tas_MIROC5_piControl.nc is the original file and tas_MIROC5_piControl_compute.nc is what I get when I do tas.compute() before saving to nc file.

@ShihengDuan – I realize that when I go back to the original issue on this ticket, if I use xarray instead of xcdat when opening the dataset (or the original data), I think I have the same issue (lat_bnds has time as a dim). I think this may either be an issue with the underlying data that needs to be resolved or an issue with xarray (on which xcdat is based).
Do you agree?

Oh yes, I didn't realize that. I guess it is related to how the original data file is formatted?

I think this may either be an issue with the underlying data that needs to be resolved or an issue with xarray (on which xcdat is based).

Based on the error below, I believe this is an issue with the underlying data rather than with xarray.
import xcdat as xc
fn = '/p/css03/cmip5_css02/data/cmip5/output1/MIROC/MIROC5/piControl/mon/atmos/Amon/r1i1p1/tas/1/*.nc'
ds = xc.open_mfdataset(fn)

MergeError: conflicting values for variable 'lat_bnds' on objects to be combined. You can skip this check by specifying compat='override'.

Here is info from the FAQs that covers this specific issue and a workaround with xarray:
https://xcdat.readthedocs.io/en/latest/faqs.html#how-do-i-open-a-multi-file-dataset-with-values-that-conflict

In xarray, the default setting for checking compatibility across a multi-file dataset is compat='no_conflicts'. If conflicting values exists between files, xarray raises MergeError: conflicting values for variable <VARIABLE NAME> on objects to be combined. You can skip this check by specifying compat="override".
If you still intend on working with these datasets and recognize the source of the issue (e.g., minor floating point diffs), follow the instructions below. Please understand the potential implications before proceeding!

The solution is to configure open_dataset()/open_mfdataset() with these settings:
import xcdat as xc
fn = '/p/css03/cmip5_css02/data/cmip5/output1/MIROC/MIROC5/piControl/mon/atmos/Amon/r1i1p1/tas/1/*.nc'

ds = xc.open_mfdataset(fn, compat="override", join="override", coords="minimal")

print(ds.lat_bnds)

# Notice how with `coords="minimal"`, time dimension is not being added to lat_bnds and lon_bnds
<xarray.DataArray 'lat_bnds' (lat: 128, bnds: 2)>
dask.array<open_dataset-752fd673e13445722f06a881808577f1lat_bnds, shape=(128, 2), dtype=float64, chunksize=(128, 2), chunktype=numpy.ndarray>
Coordinates:
  * lat      (lat) float64 -88.93 -87.54 -86.14 -84.74 ... 86.14 87.54 88.93
    height   float64 ...
Dimensions without coordinates: bnds

compat="override": skip comparing and pick variable from first
join="override": if indexes are of same size, rewrite indexes to be those of the first object with that dimension. Indexes for the same dimension must have the same size in all objects.
`coords="minimal": Only coordinates in which the dimension already appears are included.

This avoids dimensions unintentionally being added to variables

Note, join="override" might not be necessary in this case.

Thanks for the information. This makes sense to me.


Add consumer library

This PR adds a basic event consumer that can be configured using dependency injection.
The event consumer uses the Mediatr library so a INotificationHandler must be registered for each events added to the type map in order to perform an action when an event is received.
Note: .net5 is out of support but I didn't change it in Odyssey itself and reused in the new library for consistency.

Adding tests is a bit of a challenge, I can try to use a cosmos emulator to emit events and check if we receive them.


Fix local Windows/remote Linux terminal link path separators

Fix for #171122
Using remoting from a Windows machine to a Linux machine and having a remote terminal created by a remote workspace will use the path separators of the local machine (Windows) instead of the path separators of the remote (Linux) machine.  This makes it so ctrl-click on path links won't properly find/launch files on the remote.
I have a workspace extension that will reproduce this problem: https://github.com/MarkZuber/vsctermdebug
Repro steps:

Use a Windows machine as the local VS Code
Use the Remote-SSH extension to remote into a Linux machine
Install the above vsctermdebug extension as a workspace extension on the Linux machine
From the command palette, run "Terminal Path Separator Test".  This will cause the remote extension host to create a terminal and simulate some build output that ran on the remote.
Ctrl-click on the relative/path/to/a/file.txt file link.  This represents a (fake) file relative to the root of the remote workspace.
Once you have clicked on the link, a drop down from the top will open to show the relative file path and let you open the file.

Expected:

the drop down will contain:  relative/path/to/a/file.txt which would exist on the remote machine

Actual:

the drop down contains: relative\path\to\a\file.txt which won't ever exist on the remote machine since the remote is posix based and the path separators here are for Windows.

Note:  I originally built this featured on our 1.71 fork and ported the changes to main.  Given a local build is OSS based I have not been able to verify my fix completely on the public main branch (troubles getting fully connected to the remote on OSS which work on full signed public release).  If there are further steps I can take to help do a final verify using public vscode against a remote, I'm happy to do so.  I'd like to do more of these types of changes in the future that require remoting.

Closing off in favor of https://github.com/microsoft/vscode/pull/176399


empty_titles: Set line-height to match font size.

While working on #32122, I noticed that wrapped empty-title lines collide with each other. This is basically a Bootstrap override, but also something that likely got overlooked on the information-density project from Spring 2024.
CZO issue

Screenshots and screen captures:

Before
After

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Merged, thanks @karlstolley!


[WIP] Add a single endpoint that visualizes new table.

CATEGORY
Choose one

[ ] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

REVIEWERS

Codecov Report

Merging #6 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #6   +/-   ##
=======================================
  Coverage   58.86%   58.86%
=======================================
  Files         360      360
  Lines       11384    11384
  Branches     2795     2795
=======================================
  Hits         6701     6701
  Misses       4505     4505
  Partials      178      178

Continue to review full report at Codecov.

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


fix(security): vulnerabilities found in example-carbon-accounting

Fixes #2062
Signed-off-by: zondervancalvez<EMAIL_ADDRESS>

Closing this for now, let's re-open when work has resumed on it.


Add configurable error callback

Replace console.error with a configurable option. This mimcs the current
default behaviour to guaranteee compatibility with previous versions.
Add errorCallback to the README.md

[clabot:check]

[clabot:check]

This looks like a nice feature to add, but we should first merge #656 which provides a general framework for defining options; then we can add an errorCallback to the options object.

@j-lenoch #656 finally landed.  (Sorry for the delay.)  Can you try to merge your feature addition onto the current master branch, e.g. via git rebase and resolving the conflict?

Thank you very much, I'll take care of it!

@j-lenoch thanks for the PR.


Translations for korean language

could you accept this Translations for "korean"?

Thanks for the new translation.


Custom extensions of the Language Server Protocol

For some languages (concretely thinking about hardware description languages such as VHDL or Verilog, but this probably applies to more), there are certain desirable features that are not covered by the language server protocol, but that are small enough so these features would likely not be implemented into the mainline protocol. As one concrete example: These language description languages usually have a notion of instantiated units that form a hierarchy of sorts. This hierarchy is similar to the notion of a CallHierarchy or TypeHierarchy yet cannot be expressed satisfactorily or semantically correct with either capability. At the same time, it is also not practical to implement support for such InstantiationHierarchy (or similar) capabilities into the mainline protocol because most languages will never use this capability it and therefore most editors won't enable support for the capability.
In my opinion, these kinds of features would best be implemented as part of a custom extension of the Language Server Protocol. Plugins in editors (thinking especially about VSCode, but this is widely applicable) could tune into these extensions and provide the client side implementation of the protocol. The Base LSP is still applicable, but the method names, appropriate parameters and responses would be custom.
My question therefore is: Is there a 'standard' way of extending the Language Server Protocol to implement these niche features? I.e., is there a certain namespace or schema for method names that can or should be used to implement custom capabilities and does LSP even allow or encourage extensions? And if it doesn't so far, would this make sense?

I am in support of those extensions and the npm modules for VS Code support to plugin features into the existing client and server.
We could manage the names of these requests still in the LSP protocol but leave the spec and implementation to someone outside of the protocol. This ensures that no name is taken twice.

This paper by Rask et al. (I am unaffiliated) describes an LSP extension intended for languages that support specification or proof-related tasks, such as Dafny, Lean, Alloy, Isabelle, the Vienna Development Method (VDM), etc.
There is already an implementation of the extension (called SLSP for Specification LSP) in the VDM VSCode extension here, which might be a useful reference.


131 implement ipc for reverse communication with hardware desktop app

added function for ipc back to device. the pull request also include functions to set the led color. working

you can check https://cdn.discordapp.com/attachments/1162479420557246595/1191144063966134302/VID_20231231_231739.mp4?ex=65a45e5b&is=6591e95b&hm=a5287159d6d3fa00fa32ce7a1acd457008f02375a27d7722994fa1559c6fadd9&


If "org.axonframework.eventhandling.TrackingEventProcessor" cannot access the db, it tries several times per second to get a connection

If an Exception occurs, which is not an UnableToClaimTokenException, Thread.sleep() should be called, too.
org.axonframework.eventhandling.TrackingEventProcessor#ensureEventStreamOpened
private MessageStream<TrackedEventMessage<?>> ensureEventStreamOpened(
            MessageStream<TrackedEventMessage<?>> eventStreamIn) {
        MessageStream<TrackedEventMessage<?>> eventStream = eventStreamIn;
        while (eventStream == null && state == State.STARTED) {
            Transaction tx = transactionManager.startTransaction();
            try {
                TrackingToken startToken = tokenStore.fetchToken(getName(), 0);
                eventStream = messageSource.openStream(startToken);
                tx.commit();
            } catch (UnableToClaimTokenException e) {
                tx.rollback();
                try {
                    Thread.sleep(5000);
                } catch (InterruptedException interrupt) {
                    logger.info("Thread interrupted while waiting for new attempt to claim token");
                    Thread.currentThread().interrupt();
                }
            } catch (Exception e) {
                logger.warn("Unexpected exception while attemting to retrieve token and open stream. " +
                                    "Retrying in 5 seconds.", e);
                tx.rollback();
            }
        }
        return eventStream;
    }

#286 Fixes this on master branch (3.x).
Need to cherry pick this on 3.0.x branch

Fixed on 3.0.x branch in ad95cdad652042ac188d1e645824067bd449b191


python310Packages.bthome-ble: init at 0.2.2

Description of changes
Library for BThome BLE devices
https://github.com/Bluetooth-Devices/bthome-ble

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 187408 run on x86_64-linux 1

23 packages built:

home-assistant-component-tests.govee_ble
home-assistant-component-tests.inkbird
home-assistant-component-tests.moat
home-assistant-component-tests.sensorpush
home-assistant-component-tests.xiaomi_ble
python310Packages.bluetooth-sensor-state-data
python310Packages.bthome-ble
python310Packages.govee-ble
python310Packages.inkbird-ble
python310Packages.moat-ble
python310Packages.qingping-ble
python310Packages.sensor-state-data
python310Packages.sensorpush-ble
python310Packages.xiaomi-ble
python39Packages.bluetooth-sensor-state-data
python39Packages.bthome-ble
python39Packages.govee-ble
python39Packages.inkbird-ble
python39Packages.moat-ble
python39Packages.qingping-ble
python39Packages.sensor-state-data
python39Packages.sensorpush-ble
python39Packages.xiaomi-ble


Return values of gmt.info

This issue is opened to further discuss the https://github.com/GenericMappingTools/gmt-python/pull/106#issuecomment-363649758 about gmt.info.

Do you think we should print the output instead of returning it? There could be a flag to trigger a return instead of printing.

IMHO, returning the output makes more sense than printing it. It's easy for users to print it via print(gmt.info()) if they need.

Either way, if the returned string is just a list of numbers, it would be better to return an array/list of the number instead.

As far as I know, the outputs of gmt info can be divided into following types when different options are used:
Type 1
$ gmt info points.txt
points.txt: N = 20	<11.5309/61.7074>	<-2.9289/7.8648>	<0.1412/0.9338>

I think this type is useless in most cases. We can leave it as it is.
Type 2
$ gmt info points.txt -C
11.5309	61.7074	-2.9289	7.8648	0.1412	0.9338

We can convert this type to a list/array.
Type 3
$ gmt info points.txt -I0.1
-R11.5/61.8/-3/7.9

-Rw/e/s/n is useless for Python. Should be convert to a list/array.
Type 4
$ gmt info points.txt -T0.1
-T11.5/61.8/0.1

Useless. Should be convert to a list/array.
Types 5
$ gmt info points.txt -Ib
11.5309	-2.9289
61.7074	-2.9289
61.7074	7.8648
11.5309	7.8648
11.5309	-2.9289

gmt info -Ib reports the bounding box polygon for the data files, which is usually used in further fig.plot(). So it may make more sense to return it as two arrays x and y. A much general way is to return it as a ndarray, so users can access the first column via output[:,0] and the ith column via output[:,i-1].
If -Af|s option is used, the output becomes more complicated, e.g.:
$ gmt info points.txt points-copy.txt -C -Af
11.5309	61.7074	-2.9289	7.8648	0.1412	0.9338
11.5309	61.7074	-2.9289	7.8648	0.1412	0.9338

In such cases, we can return the output as a ndarray.
Conclusion
What we can do with the gmt.info outputs:

convert it to an array (type 2-4)
convert it to a multi-dimensional ndarray (type 2-5 and some more complicated cases).
leave the output as it is (type 1 and other cases not discussed in the issue).

Hi @seisman, sorry I missed this issue. I think we can leave it the way it is for now. gmt.info probably won't be as useful in Python as it is on the command-line because we can get a lot of the same information from the Python containers.
I'll leave this open so we know to come back to it if the need arises.

I also agree with that gmt.info is mostly useless in Python. The above discussions may also apply to other modules like grdinfo, gmtselect et al. So we may further explore this later.

Yep. Those should be very low in our list of things to wrap.

tl;dr
After reading the above discussion, I would like to work on more fully wrapping grdinfo. It seems like a potentially good "first issue," and I can see a benefit in wrapping it even with Python containers also available. See below, for example.
Motivation
In my use case, I want to easily see the min/max z-values of a DEM so that I can choose my colorbar limits.
1. No specified region
With GRIDFILE being the full path to my grid file, I could use
import gmt
print(gmt.grdinfo(GRIDFILE).strip())

...
../srtm15_plus_w180n90.nc: z_min: -7840.125 z_max: 6057.64355469 name: z
...

or (with xarray, for example)
import xarray
print(xarray.open_dataset(GRIDFILE).z.actual_range)

[-7840.125       6057.64355469]

These are about equal effort (and xarray returns things in a more usable output).
2. Specified region of interest
For viewing the min/maz z-values within a specified REGION = (lonmin, lonmax, latmin, latmax), I think that grdinfo makes this easier:
import gmt
print(gmt.grdinfo(GRIDFILE, R='{}/{}/{}/{}'.format(*REGION)).strip())

...
../srtm15_plus_w180n90.nc: z_min: -4996.11816406 z_max: 6057.64355469 name: z
...

vs.
import xarray
z = xarray.open_dataset(GRIDFILE).sel(lon=slice(*REGION[0:2]), lat=slice(*REGION[2:4])).z.values
print(z.min(), z.max())

-4996.118 6057.6436

Plus grdinfo is more format agnostic. By minimally including the @use_alias and @kwargs_to_strings decorators, the grdinfo command above could be just
print(gmt.grdinfo(GRIDFILE, region=REGION).strip())

and (with more work) could perhaps could output a dictionary? Please let me know if this is a worthwhile effort and I'll make a PR for module.py.


Fixed problems related to Issue #38 - it will now place the DOMI subf…

…orm in ALL forms with the alias Appointment that are visible to the Notes client, and will ignore the ones not visible to the Notes client.

 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.


simple dockerfile

I've written a simple docker file to help developing and using the project:
https://github.com/Aref-Riant/open-code-on-docker
hope it could help

Very cool! Thanks for your contribution!


feature/setup-dependencies

Add dependency entry point
Related to commit: 22418532a2842b78a55e27cc44da027b428fe0f8

Looks good, let's merge!


provide functions for approving collateral token and approving debt token

rn we only have userPosition.approveManageTransaction()
when we need both token to be approved
the function will let metamask (or other wallets) prompt twice
and then return with the ContractTransactionResponse for approval of collateral token without ERC20PermitSignatureStruct for approval of R
and both of them are required for the consumer to proceed
rn the work around is to:
pass zero debt change amount when we want to approve for collateral token only
pass zero collateral change amount when we want to approve for debt token only

Not needed anymore.


Documentation doesn't list all reportgenerators

Describe the bug
Dependency checker is great!  Small help and documentation thing I noticed.  Documentation (--help, *.md, etc) doesn't list all report generator types.
Version of dependency-check used
The problem occurs using version 9.0.2 of the cli, but it's observed in the source at many more places.
Log file
usage: Dependency-Check Core [--advancedHelp] [--enableExperimental]
       [--exclude <pattern>] [-f <format>] [--failOnCVSS <score>] [-h]
       [--junitFailOnCVSS <score>] [-l <file>] [-n] [--nvdApiKey <apiKey>]
       [-o <path>] [--prettyPrint] [--project <name>] [-s <path>]
       [--suppression <file>] [-v]

Dependency-Check Core can be used to identify if there are any known CVE
vulnerabilities in libraries utilized by an application. Dependency-Check
Core will automatically update required data from the Internet, such as
the CVE and CPE data files from nvd.nist.gov.

...
 -f,--format <format>           The report format (HTML, XML, CSV, JSON,
                                JUNIT, SARIF, JENKINS, or ALL). The
                                default is HTML. Multiple format
                                parameters can be specified.

To Reproduce
Steps to reproduce the behavior:

Start the CLI with --help
Observe the list of formats enumerated next to -f,--format <format>

Expected behavior
The help should show all ReportGenerator types at https://github.com/jeremylong/DependencyCheck/blob/main/core/src/main/java/org/owasp/dependencycheck/reporting/ReportGenerator.java, but it doesn't show GITLAB.
Additional context
If you search the source for this list (I found it easiest to search for https://github.com/search?q=repo%3Ajeremylong%2FDependencyCheck SARIF&type=code), it shows up in several places in the documentation.  Some are missing JENKINS and some are missing GITLAB.

I was reading through https://github.com/jeremylong/DependencyCheck/issues/6187 and one of the suggestions was to enumerate the report types that you want.  I noticed that they weren't all listed in help.

Thanks for pointing this out.


make jobs run sequentially to reduce benchmark interference

Reasons I hesitate to merge
CI Time
CI time is a bit painful at the moment. This PR takes CI time from 5 minutes to 10 minutes.
Uncertainty of benefits
I don't know the exact mechanics behind how parallel runs work. Do they happen on the same machine, on multiple machines with the same specs, are other people on the same running their cloud actions regardless of if I am running mine in parallel?
I have observed the relative orders to be generally stable in the current approach. We can do some historical analysis and verify this if it is a concern.
Desire to eventually run on dedicated hardware
Ideally all benchmarks are run on dedicated hardware. And we would test across a variety of platforms. This is not cost effective or practical to run these variety of dedicated hardware in GitHub actions.
I imagine an annual performance testing event. In that case, the README will start with the results of the annual test and then below will be the preliminary tests for the upcoming year that ran in the CI. I feel the CI is just a nice way to say "the code runs".

I think that a single action is generally run on one virtual machine so benchmarks, especially those that will saturate available threads will inherently compete against each other.
the timing on the new Julia benchmark was ~30 microseconds on the PR CI, but master branch now shows 49 microseconds which makes me thinks there is enough noise or inconsistency with runs that we should make attempts to minimize
The runtime on this PR was still only ~10 minutes, compared to ~6 minutes on master. IMO four minutes is worth it if the benchmarks are to be more trustworthy

I'm convinced


Add nation and HHS to Safegraph

Description
Merge after #610
Add HHS and nation to safegraph. There's some test code duplication that can be removed that I didn't bother with in this PR.
Changelog
Itemize code/test/documentation changes and files added/removed.

Update conditional statements to map to nation and hhs
Update tests to run the hhs and nation cases

Fixes

n/a

tests passed.
linting looks good.


Graphics glitches while working with rust and json files

Which operating system does the issue occur on?
OSX 10.14.4
Alacritty version 0.3.0 built from source
I seem to be running into weird glitches while working with rust and json files.

I've only noticed this issue while inside of tmux+nvim. Alacritty+nvim, without tmux does not seem to have this issue. I've also tested the same setup with go and js without such issue.

digging further, it looks more like a neovim issue. Closing.


Make an ADS dev key with<EMAIL_ADDRESS>

Right now, I'm using my own API key...

Not sure who has the email login -- I think one of @astrofrog @eteq @kelle @taldcroft will have to do this?

I can help. Please DM me on Slack.

ADS login for<EMAIL_ADDRESS>and Key are both generated. Key sent to adrian via Slack DM. Info stored in team 1Password account. Documenting who has access to that account is in project/#115. (I think this issue can be closed.)

New key added to the repo - thanks @kelle !


MenuFlyout ItemTemplate not Applied

To Reproduce
Steps to reproduce the behavior:

Download Attach
Extract
Open
Run
Click on DropDownButton
You Can se error

Expected behavior
ItemTemplate is applied
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. Windows, Mac, Linux (State distribution)]
Version: 11.0.0-preview4

Additional context
Add any other context about the problem here.
DropDownButton_Issue.zip

Maybe duplicate with mine https://github.com/AvaloniaUI/Avalonia/issues/9696

Duplicated

After some thorough investigation the problem is similar but not the same.

Fix does not work with Avalonia 11.0.0-preview5.
Now it is complete broken and shows no items:
[Binding]Error in binding to 'Avalonia.Controls.MenuFlyout'.'Items': 'Null value in expression '{empty}' at ''.'(MenuFlyout #5560998)
My Window xaml looks like this:
<Button Content="Testen">
    <Button.Flyout>
	    <MenuFlyout Placement="Left" Items="{Binding Path=TestItems,Mode=OneWay}">
		    <MenuFlyout.ItemTemplate>
			    <DataTemplate>
				    <TextBlock Text="{Binding Path=Name,Mode=OneWay}" />
			    </DataTemplate>
		    </MenuFlyout.ItemTemplate>
	    </MenuFlyout>
    </Button.Flyout>
</Button>

And the ViewModel looks like this:
public record class TestItem(string Name, string Info);

public class MainWindowViewModel
{
    public MainWindowViewModel()
    {
        TestItems = new ObservableCollection<TestItem>
        {
            new TestItem("Hallo", "Hallo Welt"),
            new TestItem("Bla", "Hallo Welt"),
            new TestItem("Blubb", "Hallo Welt"),
            new TestItem("Etwas mehr Text", "Hallo Welt"),
            new TestItem("Hallo Ihr da", "Hallo Welt")
        };
    }

    public ObservableCollection<TestItem> TestItems { get; }

With Avalonia 0.10.18 the items are plain shown in UI as ToString()

@FG-rgb please open this as a new issue. Closed issues will not be followed up. Also your issue seems to be different to the one posted above.

Ok @timunie bug created:
https://github.com/AvaloniaUI/Avalonia/issues/10626


generated mgmt_soc and dffram cell name and interface mismatch

New dffram cells has the following interface
 input CLK;
 input EN0;
 input VGND;
 input VPWR;
 input [7:0] A0;
 input [31:0] Di0;
 output [31:0] Do0;
 input [3:0] WE0;

The generated interface in mgmt_soc doesn't have a 0 postfix. In addition, cell names should be RAM128 and RAM256 for the 512B and the 1KB as these are the outputs from the dffram generator

commits ee316545117895812aa72d5de82192d5e2e6f4e8 and 62ee723241c198eb432ee16bb7b61836d6452f4a. regenerates DFFRAM while renaming it and adhering to the interface stated above


Diff error when creating date with format

When creating a date using a non ISO format, the diff function returns weird results (it seems like it is ignoring the minutes of the date).

26/10/2016 14:19:46 - 26/10/2016 14:19:37 = 9 seconds
26/10/2016 14:08:50 - 26/10/2016 14:08:39 = 11 seconds
26/10/2016 14:07:00 - 26/10/2016 14:06:49 = -49 seconds
26/10/2016 13:48:07 - 26/10/2016 13:47:43 = -36 seconds
26/10/2016 13:58:07 - 26/10/2016 13:47:43 = -36 seconds

Here is a jsFiddle where you can check the issue:
var dates = [
    {start: '26/10/2016 14:19:37', end: '26/10/2016 14:19:46'},
    {start: '26/10/2016 14:08:39', end: '26/10/2016 14:08:50'},
    {start: '26/10/2016 14:06:49', end: '26/10/2016 14:07:00'},
    {start: '26/10/2016 13:47:43', end: '26/10/2016 13:48:07'},
    {start: '26/10/2016 13:47:43', end: '26/10/2016 13:58:07'}
];

for(let i = 0, len = dates.length; i < len; i++){
	let start = moment(dates[i].start, 'DD/MM/YYYY H:i:s');
  let end = moment(dates[i].end, 'DD/MM/YYYY H:i:s');
  let diff = end.diff(start, 'seconds');

  document.body.innerHTML += '
'+end._i+' - '+start._i+' = '+diff+' seconds

';
}

document.body.innerHTML += '
';

dates = [
    {start: '2016-10-25 14:19:37', end: '2016-10-25 14:19:46'},
    {start: '2016-10-25 14:08:39', end: '2016-10-25 14:08:50'},
    {start: '2016-10-25 14:06:49', end: '2016-10-25 14:07:00'},
    {start: '2016-10-25 13:47:43', end: '2016-10-25 13:48:07'},
    {start: '2016-10-25 13:47:43', end: '2016-10-25 13:58:07'}
];

for(let i = 0, len = dates.length; i < len; i++){
	let start = moment(dates[i].start);
  let end = moment(dates[i].end);
  let diff = end.diff(start, 'seconds');

  document.body.innerHTML += '
'+end._i+' - '+start._i+' = '+diff+' seconds

';
}

I'm using Chrome 54 on Widnows 10
Next is the output of:
console.log( (new Date()).toString())
console.log((new Date()).toLocaleString())
console.log( (new Date()).getTimezoneOffset())
console.log( navigator.userAgent)
console.log(moment.version)

Fri Oct 28 2016 11:02:55 GMT-0300 (Hora verano Sudamérica Pacífico)
28/10/2016 11:02:55
180
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
2.15.2

You need a different format string. i is not a moment token. The format you are using would properly be coded as DD/MM/YYYY HH:mm:ss.
Also of note - any variable prefixed with _ is private and should not be used in your code. _i is in fact just the initial string passed to the parser. If you had used .format() instead, you would have seen that the minutes were in fact not parsing.


Supporting status as query parameter

Adding a status parameter to override the right-hand-side text of a badge.
This implements feature request on #835

Thanks for your patch!
Query parameters are meant to have an effect on all badges; they mustn't be badge-type-dependent.

@espadrine Gotcha. I though it made sense to include it just on the general badge in order to avoid customizing the other badges which could potentially defeat the whole purpose of having them in the first place. Seemed like the general badge was general enough to include it there alone.
Taking into account my situation describen on #835, should I try to work on applying it to the other badges as well?
Thanks a lot in advance.

@espadrine would appreciate a response on this to manage other options, although seems like a perfectly good feature to customize better a badge

Closing in favor of direct implementation presented on #852 rather than this workaround.


fix a bug for futurebuilder, example:

Builder(
  builder: (context) {
    final identifier = Object();
    return FutureBuilder(
      future: Future.value(identifier),
      builder: (context, snapshot) {
        assert(identifier == snapshot.data || snapshot.data == null);
        return Container();
      },
    );
  },
)

The assertion will fail when the FutureBuilder is rebuilt, but it will succeed after this fix.
Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.
List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] I followed the breaking change policy and added Data Driven Fixes where supported.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

This is a bug I found during development, and I don't know how to submit a pull request. Please help me if you can.

Hi @xiongzhaowei It looks like this PR is missing a test. Can you please add one. Also, it looks like many checks are failing. Can you please take a look at those and address the issues? Thank you!

(triage) @xiongzhaowei Do you still have plans to come back to this PR and address the feedback given above? Also, it seems like a few checks are failing. Can you take a look at those as well? Thank you.

This is my first PR and I don't know how to get it to the required level to be accepted. I noticed that there were some linux-related checks that didn't work, but I didn't modify those.
I found a new way to fix this without caching the widget.


[FEAT]: Attach documents to messages

What would you like to see?
Currently, only administrators and managers can upload documents, and then those documents must be added to a workspace and accessed through RAG / pinning.
It would be good if users could upload attachments to messages. Attachments would be processed / OCRed and added to the context of the current conversation, but not added to the RAG system / made available to other users. This is a very common usage pattern, supported by ChatGPT, Claude, etc.

I'm asking for the same feature but too bad, my ticket got closed

@petrusali https://github.com/Mintplex-Labs/anything-llm/issues/2405
The issue was quite vague and ambiguous. If this issue is what you were asking we need a more verbose use-case and description as above.
We have to be pretty strict on pruning issues since a ton of people use GH issues for help/support or things get out of hand very fast for us.


New Yarn Colors

Add new yarn colors:

Black
Brown
Grey
Pink
Purple
Sky Blue
White
Yellow

Move color determiner to ColorSO and GameManager. Should now mean only a single place needed to update yarn color for level.
Further Improvement:

Make yarn into single prefab with color variants determined by material. This will remove the need for prefab variants for each yarn ball colors.

 Cel Shading Art Style

 Prototype: Change # of Colors


Updated documentation of Traffic Router development page to match the…

… project

Can one of the admins verify this patch?


[Bug]  When I install discord betterdiscord it doesn't work properly and it loads that I'm in the browser.

When I install discordbetter discord I load as if I use the settings. I tried everything ... I reinstalled discord, reinstalled discordbetter and nothing helped

Discord Version
Stable 80597

I closed because I succeeded, but after about 5 minutes discord made the updates itself and discordbetter disappeared. And discord has switched to browser mode

I noticed there are doubled lines. as if discord better was there, but it didn't work.

Try deleting all source/trace files and reinstall. This should fix it.

Same issue here, even when removing. I'm on Manjaro Linux with the discord app from the official repos. Flatpak has same issue.

I've tried everything. And nothing helped. I deleted all discord files on my computer as well as discordbetter. There is a mistake all the time. And if you manage to install it, after 5 minutes discord automatically updates and all discordbetter functions disappear

Try deleting all source/trace files and reinstall. This should fix it.
Also, this seems to only be a bug to mainly the PTB and Canary versions.
It does that for the main version too.
The best thing to do is just to uninstall betterdiscord, it fix this "browser" problem.

I've tried everything.
just uninstall betterdiscord, you don't need to delete any file.
If you use betterdiscordctl then it's simple as using it while discord is opened with this command:
betterdiscordctl uninstall
then it will kill the discord process, restart discord and it's now detected as a desktop app.

all discordbetter functions disappear

Yes it's broken with the last version, if you try to use it won't work and you discord will be the browser version, don't use it for now, just uninstall it until it's fixed by bd.

Thank you very much! I will be waiting impatiently.

I have the same problem, thanks for the update @4n0nct I'll also be looking forward for this to be solve to try it again.
Would appreciate any updates once this is solve to test things again
Thank you!

#600


OpenApiResponseBody is obsolete but mentioned in docs

https://github.com/Azure/azure-functions-openapi-extension/blob/main/docs/openapi-core.md#expose-endpoints-to-openapi-document
This page uses OpenApiResponseBody instead of OpenApiResponseWithBody, but the former is marked obsolete

Let me check this out.


Yarn Not Starting

I have installed yarn application globally but whenever I enter the command 'yarn start' it shows that start command is not found.

Did you run just yarn inside the project folder?

@techyusuf
Most likely there is no start command inside the scripts section of the package.json file.
Look below for an example:
"scripts": {
  "start": "some command to be run", // you need to add this line
  "test": "(eslint lib || true) && jest"
}


ext：有更多的api开放？

+1

Glad to hear from you, we will continue to open more functions

+1

https://pub.flutter-io.cn/packages/amap_flutter_location 官网


DRAFT - Create update OpenShift versions command

Which issue this PR addresses:
Implements https://msazure.visualstudio.com/AzureRedHatOpenShift/_workitems/edit/10581314/
What this PR does / why we need it:
Creating ARO command to update the minimum ocp versions allowed when creating and updating ARO clusters.
Test plan for issue:
Unit tests and manual testing
Is there any documentation that needs to be updated for this PR?
Both in repo documentation and internal ADO Documentation

Few questions here:

Why are we not dynamically building the supported versions within the RP itself by parsing Cincinnati stable channel?

I can understand that we haven't tested & vetted the versions, but how do we plan on testing/vetting the versions before updating them anyway? Do we have a plan
I guess it would be harder to pull versions in the case of a bad release.  Ideally the release team would do so.

The current way this is structured it has 4.11 in it which isn't ready (I know it's in draft, but just a heads up) as well as it includes multiple z-stream versions when there is a minSupportedZStream version.  I think this was meant to look differently.

What's the current workflow to run / update this?  Is it going to run on every RP release, or run independently of them?  If so, how does this play into SDP?

@bennerv thanks for the questions:

This is what we were implementing, but TL's asked for this to be descoped from the initial implementation and the WI was modified to this effect. I'll be creating a design document to circulate for approval.
It was supposed to be just a minimum X.Y.Z version for each supported X.Y version from which the versions from the Cincinnati stable channel would be added. The explanation of this process will be explained in greater detail in the design doc.
The intention is to run this process in a separate pipeline for each sector on a regular, yet TBD, cadence.


Update Composer dependencies (2020-11-25-00-03)

Visual regression test passed!
View the visual regression test report


Update public datasets tutorial speakers

@irenetrampoline it looks like these changes were made on an old branch. The tutorial contents are now contained in https://github.com/acm-chil/acm-chil-website/blob/master/sitedata/tutorials.csv
There is an outstanding invitation for you to join this group. Joining might make it easier to work on the repo if you have more changes to make.
I've made this change in a separate pull request: https://github.com/acm-chil/acm-chil-website/pull/56


gam update group sync issue in 4.03

There appears to be an issue with syncing member to groups in 4.03, I have a file /tmp/memberlist which I am attempting to use to sync up to a group using the following command.
gam update group testgroup sync member file /tmp/memberlist
And I receive the following result
Getting members of<EMAIL_ADDRESS>(may take some time for large groups)...
Got 254 members...
Need to add 1 MEMBER and remove 0.
starting 1 worker threads...
Exception in thread Thread-1:
Traceback (most recent call last):
  File "threading.py", line 801, in __bootstrap_inner
  File "threading.py", line 754, in run
  File "gam.py", line 10183, in batch_worker
  File "subprocess.py", line 523, in call
  File "subprocess.py", line 711, in __init__
  File "subprocess.py", line 1343, in _execute_child
OSError: [Errno 2] No such file or directory

This then hangs indefinitely and must be manually killed. A fresh install of 4.03 performed the same. I also have gam 3.7 installed, and I verified that the same command works as expected with no issues.
Running on CentOS 7

naps,
Jay's single executable Linux installs are broken.
My version is correct: https://github.com/taers232c/GAM-B/releases
Get my version, unpack, copy client_secrets.json, oauth2.txt,
oauth2service.json from your current version into the new folder and try
your command.
Ross
On Wed, Jan 11, 2017 at 10:58 AM, npas<EMAIL_ADDRESS>wrote:

There appears to be an issue with syncing member to groups in 4.03, I have
a file /tmp/memberlist which I am attempting to use to sync up to a group
using the following command.
gam update group testgroup sync member file /tmp/memberlist
And I receive the following result
Getting members of<EMAIL_ADDRESS>(may take some time for large groups)...
Got 254 members...
Need to add 1 MEMBER and remove 0.
starting 1 worker threads...
Exception in thread Thread-1:
Traceback (most recent call last):
File "threading.py", line 801, in __bootstrap_inner
File "threading.py", line 754, in run
File "gam.py", line 10183, in batch_worker
File "subprocess.py", line 523, in call
File "subprocess.py", line 711, in init
File "subprocess.py", line 1343, in _execute_child
OSError: [Errno 2] No such file or directory
This then hangs indefinitely and must be manually killed. A fresh install
of 4.03 performed the same. I also have gam 3.7 installed, and I verified
that the same command works as expected with no issues.
Running on CentOS 7
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jay0lee/GAM/issues/387, or mute the thread
https://github.com/notifications/unsubscribe-auth/AIU8L7tjnZMe7ebo_RMl8TNSUBsLR3yRks5rRSZigaJpZM4Lg8O1
.

--
Ross Scroggs
<EMAIL_ADDRESS>

Thanks Ross, that worked great!


Module content in 1.0.8 has not changed since 1.0.7

Hi Pamela.
Thanks for getting my pull request the other day.
You upgraded the version to 1.0.8 at that time, but looking at the contents, it seems that the module is still out of date.
Please check it out.

Ah, I missed the build step, my apologies. Can you try 1.0.9?

Thank you very much.
The problem has been resolved in 1.0.9.

great thanks!


Bring MeanImputer in line with new testing setup

What?
There are a few required changes for this, summarised below from (https://github.com/lvgig/tubular/issues/150)

Update "minimal attribute dict" fixture in conftest.py with the correct set of minimal arguments required
Set up the TestInit, TestFit, TestTransform, and TestOtherBaseBehaviour methods to inherit the appropriate test classes (see an example Updated Mapping Transformer Tests) and then copy the setup_class class method into each test class, changing transformer_name to the transformer you are testing.
Delete any unnecessary tests from original transformer test file (i.e. tests testing inherited behaviour that is now tested by the inherited test classes).
Debug the failing tests from the base test suite.
Bring the test file in line with best practices by insuring there are no implementation tests (in this case looks like these will have been removed as part of the base test changes)
Bonus: If you identify any gaps in the testing, please set up new issues :)

Why?
Revamp tubular testing to make package more maintainable/modifiable

There are some changes here here to the BaseImputer tests that will be useful to this, if this PR is not complete at time of picking up then would branch off of it!


How to provide distinct values and labels?

Hello, I retrieve autocomplete data from a remote endpoint and populate results using populateResults:
    accessibleAutocomplete({
      element: el,
      id: "search_where",
      name: "where",
      source: debounce(async (query, populateResults) => {
        const res = await fetch(`${url}?q=${encodeURIComponent(query)}`);
        const data = await res.json();
        populateResults(res.results);
      }, 100),
    });

The res.results list received is of this form:
{
    "q": "pari",
    "results": [
        {
            "id": "75",
            "text": "Paris (département 75)"
        },
        {
            "id": "75056",
            "text": "Paris (75)"
        },
        // […]
    ]
}

I would like to render the text property value as the option label, but retrieve the id value when an option is selected by the user (a bit like what is possible using a regular <select> and <option value="42">Answer</option>). What data structure should I pass to populateResults to achieve that, if that's even possible?
Thanks for your help!

@n1k0 we did something this week that might be helpful for you - pr here.
Essentially we create a hidden input to store the id of the selected item - and then use that on the server to look up the thing. It looks like we're using the onConfirm option to all our own function that sets the relevant thing.
Note of course this relies on js so if you're using progressive enhancement you'll probably want a server-side solution too.

@edwardhorsford the hidden input is definitely a clever trick! I feel that distinguishing values and labels might still look like something we'd want natively though :) I feel like accepting a list of { value, label } alternatively to just labels may be relatively easy to implement while staying perfectly backward-compatible, but I may be wrong here. Would be nice to hear from maintainers about that though!

@n1k0 I agree it would be good to include, but I don't think you'll see it happen sadly - I wouldn't consider this repo actively maintained. It gets security fixes, but I don't think is a priority for GDS so hasn't had much in the way of feature work done on it for some years.

@faithandrel ah, using templates is the way to go indeed, totally missed that reading the docs. Thank you for the hint, that's nicely solving my problem 👍


Bug Report - Schema Descriptions no longer appear in the frontend

Expected Behavior

Have built the latest version (databuilder.6.7.1) using docker-amundsen-local.yml
Loaded this with sample data (sample_data_loader.py)
Entered "test" into the search box
In the results list  the "test_schema" name in the hive://gold.test_schema results should be underlined and upon hovering show a tooltip with the schema description ("test schema description")
Current Behavior

The schema names are not underlined. No tooltips are visible.
Possible Solution

Not a solution but possibly a pointer to the issue - I can see from the frontend output that the search results don't look right
         {
            "type":"table",
            "key":"delta://gold.test_schema/delta_test_table",
            "name":"delta_test_table",
            "cluster":"gold",
            "description":"test table for delta",
            "database":"delta",
            "schema":"test_schema",
            "schema_description":null,  // <- Should not be null
            "badges":[
            ],
            "last_updated_timestamp":null
         },

Steps to Reproduce

Build recent release locally
Load with sample data
Search for "test"
Observer lack of tooltip in results list

Screenshots (if appropriate)

Context

Our current prod build (common-0.24.1) functions correctly in this regard. This is stopping us from upgrading.

Your Environment

Amunsen version used: databuilder-6.7.1
Data warehouse stores: sample data
Deployment (k8s or native):
Link to your fork or repository:

cc @kristenarmes @allisonsuarez @Golodhros

As far as I know this is still an issue

Bad bot >:(