pnpm patches incorrectly excluded on turbo prune

Verify canary release

[X] I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue
https://github.com/RTVision/turborepo-prune-patch-issue
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Linux
Which canary version will you have in your reproduction?
2.1.2-canary.0
Describe the Bug
patches are being remove from the pruned workspace when app depends on the package.
Expected Behavior
all patches for dependent libraries be included in the prune of an app.
To Reproduce
clone the repo and run pnpm turbo prune --scope=web and then open up out/pnpm-lock.yaml and see the next patch is no longer present even though it is the base pnpm-lock.yaml file and web depends on next
Additional context
pnpm recently added a feature that allows trying to apply the same patch to all versions of a package which was added in pnpm 9.7. Because of that the patch doesn't have a version in the file name or in the lockfile which I suspect is causing not to be added during the prune. This is the default way pnpm generates patch files now so any new patches done are no longer being kept around.

hi is this bug related to why i can't run even the 'with-docker' example with it failing on
web:build: cache miss, executing e9bd4163eb4a2003
0.347   x internal errors encountered: unable to find package manager binary: cannot
0.347   | find binary path

I too just sunk too much time trying to integrate the with-docker starter example into an existing repo running on pnpm.
I finally tried the raw examples and discovered both the npm and yarn versions work, but as liam-germain suggests, the with-docker example does not work with pnpm.

I've been struggling with this issue all day. I can't get my app to run in Docker when using the standalone output. It seems like the dependency directories inside the Docker image are created as symbolic links, which is causing issues during runtime

This is my workaround:
# copy the patchedDependencies from the root package.json to the pruned package.json
RUN jq --slurpfile src <(jq '.pnpm.patchedDependencies' package.json) '.pnpm.patchedDependencies = $src[0]' /app/out/full/package.json > package.json.patched && mv package.json.patched /app/out/full/package.json

Make sure jq is installed and maybe you need to adjust some paths.

I solved it, it was just a pnpm-lock.yaml that was in my apps/web dir


Update DG Model

Removed the alternative section and 2nd PlantUML in the Model Section as it is unneeded
New PUML

LGTM


ToggleButtonOption

The above works logically just like CheckboxesField. Which means we could probably just substitute the CheckboxOption for a ToggleButtonOption component.

[ ] Create the ToggleButtonOption component.
[ ] Update the app theme to make the MUI ToggleButton look like UI above

One clarification point @CarsonF  - are we going to entirely replace CheckboxesField? Or make a new component called ToggleButtonOption that's functionally identical to CheckboxesField and visually unidentical?

I was thinking
<CheckboxesField>
  <ToggleButtonOption />
</CheckboxesField>

Really what I would like to do is combine radio & checkboxes into one with an exclusive option and maybe a variant prop to switch between this and radio/checkbox. But another day...


Cli: improve vote-account vote-authority display

Problem
In solana vote-account output, the Vote Authority line is not clear. It returns a map of one or more numbers to address strings, eg:
Vote Authority: {2: "A1T3QdPZGRT99twji2M4vrkFRDXjp8aEbFc6GCJuviSp"}

The number is in fact an epoch, the epoch the respective authority is active. This is usually the current epoch, but in the case of a vote-authority update, it is the epoch in which the new vote authority will go into effect.
Cleaning up small, old Labs issues: https://github.com/solana-labs/solana/issues/11273
Summary of Changes
Simplify normal display:
Vote Authority: A1T3QdPZGRT99twji2M4vrkFRDXjp8aEbFc6GCJuviSp

If a new vote authority has been authorized, display its information, eg:
Vote Authority: A1T3QdPZGRT99twji2M4vrkFRDXjp8aEbFc6GCJuviSp
  New Vote Authority as of Epoch 4: EvgdtuXcKoBAMW6eL6KMiqDre1do5o2v4tinFv91H2Fo

Fixes https://github.com/solana-labs/solana/issues/11273

Also, a question: I think the json output of vote authorities should properly be an array (echoes this issue), ie:
"authorizedVoters": [
    {
        "epoch": "3"
        "voter": "A1T3QdPZGRT99twji2M4vrkFRDXjp8aEbFc6GCJuviSp",
    },
    {
        "epoch": "4"
        "voter": "EvgdtuXcKoBAMW6eL6KMiqDre1do5o2v4tinFv91H2Fo",
    }
]

instead of current:
"authorizedVoters": {
    "3": "A1T3QdPZGRT99twji2M4vrkFRDXjp8aEbFc6GCJuviSp",
    "4": "EvgdtuXcKoBAMW6eL6KMiqDre1do5o2v4tinFv91H2Fo"
  }

Too breaking to change?

Codecov Report
Attention: Patch coverage is 63.63636% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 81.8%. Comparing base (661de5b) to head (daedbe9).
Report is 3 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master      #95   +/-   ##
=======================================
  Coverage    81.8%    81.8%
=======================================
  Files         838      838
  Lines      225940   225948    +8
=======================================
+ Hits       184937   184969   +32
+ Misses      41003    40979   -24


HID strings

This allows the controller to appear as "gladuin IIDX controller" in spicecfg and btools, and having named outputs as well :

Note: this way of declaring the descriptors with string minimum and maximum doesn't play well with btools for some reason (only tt sensitivity appears correctly there), but this should be valid so I think btools should be patched instead...
I haven't double-checked if lights were in correct order on the base code since I'm running a modded version for my controller, but I think it should work fine

First of all, sorry for the delay, I saw the notification for the pr late at night and completely forgot about it.
Very cool addition, it makes the configuration a little easier for beginners I suppose, thanks for the contribution!

welcome :) it will also help with a future dev for spice... we can make an autobind feature for when strings match


Make QR view customizable

The QR code view is pretty basic since it comes straight from https://github.com/chill117/passport-lnurl-auth. Building customization support into the lib would allow people who want to use this in production to style the login flow according to their wishes. That would certainly make adoption for real world products a bit easier.

Yes, big +1 from my side.


not change  filterable attributes.

python client:

not change filterable attributes.
but when delete all documents  client.index('photoes').delete_all_documents(),it can change  filterable attributes.
Meilisearch version: [v0.29.1]
Additional context
Additional information that may be relevant to the issue.
window11

Hello @fangaofeng
Did you check the task route later to confirm the status of the settingsUpdate task? It appears the task is in enqueued status from the screenshot. The settingsUpdate task is asynchronous in Meilisearch, meaning they are not executed instantaneously. There is a great chance there are other tasks in the queue which might delay this particular task because Meilisearch processes tasks in the order they were received.
There are four status values as mentioned in the docs:
enqueued: the task request has been received and will be processed soon
processing: the task is being processed
succeeded: the task has been successfully processed
failed: a failure occurred when processing the task. No changes were made to the database
I'd recommend checking the status of the task once again to confirm the actual progress of the task.
Hope this helps. Thank you.

I close this issue due to a lack of answers. Nothing is definitive of course, feel free to ask to re-open if needed 😊


Removing schema by key reference doesn't remove the schema reference by id

When removing a schema by key, you can still get the schema by id or vice versa.
What version of Ajv are you using? Does the issue happen if you use the latest version?
8.11.2
Ajv options object
No options
JSON Schema
With any schema
const schema = {
    $id: "id",
    type: "object",
    properties: {
        nested: {
            type: "number",
        },
    },
};

Your code
ajv.removeSchema("id");
console.log(schemas()); // ['key']
console.log(ajv.getSchema("key")?.schema); // schema found {"$id": ...}
console.log(ajv.getSchema("id")?.schema); // undefined

run again but with key ref:
ajv.removeSchema("key");
console.log(schemas()); // []
console.log(ajv.getSchema("key")?.schema); // undefined
console.log(ajv.getSchema("id")?.schema); // schema found {"$id": ...}

What results did you expect?
When removing a schema by id or key it should remove both references by key and id.

Why do you need both ID and key reference? Usually you would use one or another, with ID being a better approach.

I assumed the key reference will work as a name alias of long schema IDs and the docs is not clear about key ref use cases. If this the case, is not possible to just add id dynamically with {...schema, $id: "your id"} .?

Yes, you can do it like that… Possibly it needs to be changed like you describe, but I wouldn’t do it without a major version release. For short aliases - in most cases you are better off with some map in your own app to refer to the schemas, Ajv still uses keys for ref lookup, so in theory you can get some collisions.

Yeah I think it's better to just use external maps. Currently working on automatic file-based endpoints validation and I thought using key ref to quickly know which schema belong to endpoint using combination of path and schema id(so no id and key collision in this case). But this was not the case.
Anyways. Thank you. Appreciate your hard work 👍


OS X El Capitan installation from ISO fails

using Mist Version 0.8.1 I today created an ISO file of Mac OS X El Capitan 10.11.6
I then tried to install from the ISO (VMware Fusion) and it failed:
"The Install OS X El Capitan application can't be used from this disk.
Copy this application to a writable Mac OS Extended formatted disk and reopen it to continue installation."

The logic I was using to shrink the Bootable Disk Image down in size seems to have broken the ability to boot the ISOs.
I have a pull request in flight, #82, will reach out to confirm testing after I cut a new release 👍

Mist version 0.9.1 is now available - if you can please test with this version and report back 🙌

wonderful, thank you! Ijust created a new ISO of El Capitan and tried to create a VM in VMware Fusion. unfortunately I'm getting the exact same error during install as shown in the screenshot I posted above... running on a Mac mini 2014 with macOS Monterey. I'm now going to reinstall Monterey from scratch on said machine and report back.

@mibosshard thanks for the update - just confirming: please ensure you are on macOS Monterey 12.6.8 (21G725) when you attempt to build the ISO again 👍

okay: I made a USB installer stick using the latest (21G725) "Install macOS Monterey.app". wiped the SSD of the Mac mini clean using dd, installed macOS. downloaded Mist 0.9.1 and let it create an El Capitan installer ISO. tried to install a fresh VM using VMware Fusion 12.2.3. still getting the same error "The Install OS X El Capitan application can't be used from this disk".

just to make sure it's not macOS Monterey or VMware Fusion that causes the error I now have successfully created an El Capitan VM using an ISO I made a few years back...

I stumbled across this VMware article:
https://communities.vmware.com/t5/VMware-Fusion-Discussions/copy-this-application-to-a-writable-mac-os-extended-formatted/td-p/2865859
I suspect VMware Fusion is smarter in creating a compatible ISO than just converting a DMG > ISO via Mist, especially for "newer" versions of macOS.
Are you able to confirm the app installer isn't corrupted in any way by attempting the solution in the article? Maybe even compare the ISO created by VMware with the one created by Mist?
I may just be missing the secret sauce in the ISO that allows VMware to boot the ISO correctly.

I mounted the (non-working) ISO I created 2 days ago using Mist and dragged "Install OS X El Capitan.app" to VMware Fusion to create a fresh VM. BTW: VMware Fusion does not create an ISO but a DMG instead (gets attached to the VM as a virtual harddrive). the installer the runs without throwing an error.

As of .10 this issue still persists.


Player UI

Describe your suggested feature
I was suggesting that the brightness and sound toggle should only be visible when sliding up and down. It will make the player look less congested.
Other details
Also the brightness toggle has a bug..when adjusting brightness it begins with full brightness.

Hey @Futsu-0, would you mind updating this thread if this has been fixed after the recent commits?

Hey @rhenwinch, after the new update I'm still having the same issue of full brightness
Also there's a bug in the 'resize mode' feature. When setting it(settings menu) doesn't apply in the player. The 'center crop' and 'fit' are sometimes mixed up.

Hey @rhenwinch..I have a solution for the player being congested.
You could put it as a preference in the settings..one could add or remove some of the features on the player if they like
Thanks

Considered!

I suggest the "Providers" item of the main menu might be moved to "Preference" as a normal setting.

@rhenwinch ..was suggesting that the playback speed to be customizable. The speed I want to watch with is not in the available options. Thanks

I suggest the "Providers" item of the main menu might be moved to "Preference" as a normal setting. And the "History", including recently watched and watchlis items, is instead.

Should opened up on a new issue

The speed I want to watch with is not in the available options.

What speed multiplier are you trying to watch on to? I dont see a use for a customizable speed yet.
I mean, nobodys gonna wanna watch past 2.0x and below 0.25x, no?

The speed I want to watch with is not in the available options.

What speed multiplier are you trying to watch on to? I dont see a use for a customizable speed yet.
I mean, nobodys gonna wanna watch past 2.0x and below 0.25x, no?

It doesn't have to be customizable yet. Probably add more options like 1.15X (which I prefer). More options like on cloud stream. Thanks

Ah, I see. Will consider, thanks! sorry for judging too early

Player UI suggestions :
1.) Add an option to see resolution of video in player Like CS3
2.) Make brightness and volume slider invisible only visible when we are changing it
3.) currently when player is visible brightness is on left and volume on right and when player is hidden brightness is on right and volume on left make them on same side only brightness on right volume on left


Make sure patternstim input file has gid as integers

See this internal JIRA ticket :
User has input file:
/scatter
1000.15876308    221273.0
1000.16120151    221145.0
1000.1612057     221043.0

The second column is gid and it should be integer form i.e.
1000.15876308    221273
1000.16120151    221145
1000.1612057     221043

We should change implementation in https://github.com/BlueBrain/CoreNeuron/blob/5f1c036c14535ef225470d8bba16036dbfd64374/coreneuron/mechanism/patternstim.cpp#L140
Possible solutions:

if not an integer, throw an error
read as double, if it's integer then it's fine. Otherwise thrown an error

Hi Pramod sir, could I work on this?

What we have to do?Ccannot understand please help.SIr

hello @muhdmud  @singhshivansh244,
sorry for delay here. Let me explain how to reproduce and fix the issue:

build coreneuron:

# clone repo, create build dir and compile coreneuron
git clone https://github.com/BlueBrain/CoreNeuron coreneuron
mkdir coreneuron/build && cd coreneuron/build
cmake .. -DCMAKE_INSTALL_PREFIX=`pwd`/install -DCORENRN_ENABLE_MPI=OFF
make -j

create sample pattern.dat stimulus input file:

echo "/scatter" > pattern.dat
echo "10.15876308    221273.0" >> pattern.dat
echo "1000.16120151    221145.0" >> pattern.dat

note that second column is floating point value instead of integer:
$ cat pattern.dat
/scatter
10.15876308    221273.0
1000.16120151    221145.0

now we can run coreneuron with pattern.dat from build directory:

./bin/x86_64/special-core --tstop 100 --datpath=../tests/integration/ring/ --pattern=./pattern.dat

now if you look at https://github.com/BlueBrain/CoreNeuron/blob/5f1c036c14535ef225470d8bba16036dbfd64374/coreneuron/mechanism/patternstim.cpp#L140, the second value is read as integer with %d. In our case, the second column is float (containing integer value) and parsing this with %d is error prone.

So what one can do is:

read the value as double (%lf)
if the value read is non-integer : throw an error and abort program
if value contains integer then static_cast it to int and push to spikes vector

(I think std::modf can be used?)

So,Sir what I have to do is,change "%d" to "%lf" and add if condition to check var is int or float??
If yes then I can do it.


Lint Python with ruff replacing flake8, autopep8, etc.

Ruff replaces add-trailing-comma, autopep8, flake8, and reorder-python-imports.
Ruff supports over 500 lint rules and can be used to replace Flake8 (plus dozens of plugins), isort, pydocstyle, yesqa, eradicate, pyupgrade, and autoflake, all while executing (in Rust) tens or hundreds of times faster than any individual tool.

thanks but no thanks


Virtual environment created in wrong location

Here's my GitHub Action file:
name: Run tests

on:
    push:
        branches:
            - develop

defaults:
    run:
        working-directory: ./services/flask

jobs:
    tests:
        runs-on: 'ubuntu-latest'
        timeout-minutes: 5

        steps:
            - name: Check out Git repository
              uses: actions/checkout@v4
              with:
                fetch-depth: 2

            - name: Set up Python 3.11.7
              uses: actions/setup-python@v4
              with:
                  python-version: 3.11.7

            - name: Install and configure Poetry
              uses<EMAIL_ADDRESS>              with:
                  virtualenvs-create: true
                  virtualenvs-in-project: true

            - name: Load cached venv
              id: cached-poetry-dependencies
              uses: actions/cache@v3
              with:
                path: .venv
                key: venv-${{ runner.os }}-${{ steps.setup-python.outputs.python-version }}-${{ hashFiles('**/poetry.lock') }}

            - name: Install poetry dependencies
              run: poetry install --all-extras --no-interaction

            - name: Run tests
              run: |
                  source .venv/bin/activate
                  pytest tests/

Despite virtualenvs-in-project being set to True, the virtual environment is created in /home/runner/.cache/pypoetry/virtualenvs. Consequently, all my actions are now failing with error .venv/bin/activate: No such file or directory.
Strangely, this action worked previously without any modifications.

https://github.com/snok/install-poetry/pull/152


Standardize CLI flags

I standardized all the CLI flags to kebab-case
[Closes #116 ]

@webstradev Thanks so much for this! Could you also update the readme file to reflect the changes you've made?

@webstradev Thanks so much for this! Could you also update the readme file to reflect the changes you've made?

Will do


Test Step Script

Allows user to test the script in while creating a step

The monaco issue is causing Javascript to behave strangely. We need to fix Javascript first and then enable the conditional button-disabling functionality.


-s/--showedits argument not working

Using the -s argument does not show edits, only runs the script as if it had no command line parameters.
root@DS1:~# /volume1/Data/syno_hdd_db.sh -n -f -r
Synology_HDD_db v1.2.21
DS2415+-j DSM 7.1.1
Using model: ds2415+

HDD/SSD models found: 4
SSD 850 EVO 250GB,EMT0
SSD 860 EVO 1TB,RVT0
ST12000VN0007-2GS116,SC60
ST12000VN0008-2YS101,SC60

No M.2 drives found

No Expansion Units found

SSD 850 EVO 250GB already exists in ds2415+_host_v7.db
SSD 850 EVO 250GB already exists in ds2415+_host_v7.db.new
SSD 860 EVO 1TB already exists in ds2415+_host_v7.db
SSD 860 EVO 1TB already exists in ds2415+_host_v7.db.new
ST12000VN0007-2GS116 already exists in ds2415+_host_v7.db
ST12000VN0007-2GS116 already exists in ds2415+_host_v7.db.new
ST12000VN0008-2YS101 already exists in ds2415+_host_v7.db
ST12000VN0008-2YS101 already exists in ds2415+_host_v7.db.new

DSM successfully checked disk compatibility.
root@DS1:~# /volume1/Data/syno_hdd_db.sh -s
Synology_HDD_db v1.2.21
DS2415+-j DSM 7.1.1
Using model: ds2415+

HDD/SSD models found: 4
SSD 850 EVO 250GB,EMT0
SSD 860 EVO 1TB,RVT0
ST12000VN0007-2GS116,SC60
ST12000VN0008-2YS101,SC60

No M.2 drives found

No Expansion Units found

SSD 850 EVO 250GB already exists in ds2415+_host_v7.db
SSD 850 EVO 250GB already exists in ds2415+_host_v7.db.new
SSD 860 EVO 1TB already exists in ds2415+_host_v7.db
SSD 860 EVO 1TB already exists in ds2415+_host_v7.db.new
ST12000VN0007-2GS116 already exists in ds2415+_host_v7.db
ST12000VN0007-2GS116 already exists in ds2415+_host_v7.db.new
ST12000VN0008-2YS101 already exists in ds2415+_host_v7.db
ST12000VN0008-2YS101 already exists in ds2415+_host_v7.db.new

Re-enabled support disk compatibility.

DSM successfully checked disk compatibility.
root@DS1:~# /volume1/Data/syno_hdd_db.sh --showedits
Synology_HDD_db v1.2.21
DS2415+-j DSM 7.1.1
Using model: ds2415+

HDD/SSD models found: 4
SSD 850 EVO 250GB,EMT0
SSD 860 EVO 1TB,RVT0
ST12000VN0007-2GS116,SC60
ST12000VN0008-2YS101,SC60

No M.2 drives found

No Expansion Units found

SSD 850 EVO 250GB already exists in ds2415+_host_v7.db
SSD 850 EVO 250GB already exists in ds2415+_host_v7.db.new
SSD 860 EVO 1TB already exists in ds2415+_host_v7.db
SSD 860 EVO 1TB already exists in ds2415+_host_v7.db.new
ST12000VN0007-2GS116 already exists in ds2415+_host_v7.db
ST12000VN0007-2GS116 already exists in ds2415+_host_v7.db.new
ST12000VN0008-2YS101 already exists in ds2415+_host_v7.db
ST12000VN0008-2YS101 already exists in ds2415+_host_v7.db.new

Re-enabled support disk compatibility.

DSM successfully checked disk compatibility.
root@DS1:~#

It only shows the edits for the <model>_host_v7.db and <model>_host_v7.db.new files and all of your drives are already exists in those db files so no there was no edits to show.

I tried this on my DS720+ and got the same output:
root@DS3:~# /volume1/Data/syno_hdd_db.sh -s
Synology_HDD_db v1.2.21
DS720+ DSM 7.1.1

HDD/SSD models found: 1
WD80EFZX-68UW8N0,0A83

M.2 drive models found: 1
WD_BLACK SN770 2TB,731100WD

No Expansion Units found

WD80EFZX-68UW8N0 already exists in ds720+_host_v7.db
WD80EFZX-68UW8N0 already exists in ds720+_host_v7.db.new
WD_BLACK SN770 2TB already exists in ds720+_host_v7.db
WD_BLACK SN770 2TB already exists in ds720+_host_v7.db.new

Re-enabled support disk compatibility.

Re-enabled support memory compatibility.

M.2 volume support already enabled.

DSM successfully checked disk compatibility.
root@DS3:~# /volume1/Data/syno_hdd_db.sh -n -f -r
Synology_HDD_db v1.2.21
DS720+ DSM 7.1.1

HDD/SSD models found: 1
WD80EFZX-68UW8N0,0A83

M.2 drive models found: 1
WD_BLACK SN770 2TB,731100WD

No Expansion Units found

WD80EFZX-68UW8N0 already exists in ds720+_host_v7.db
WD80EFZX-68UW8N0 already exists in ds720+_host_v7.db.new
WD_BLACK SN770 2TB already exists in ds720+_host_v7.db
WD_BLACK SN770 2TB already exists in ds720+_host_v7.db.new

Disabled support disk compatibility.

Disabled support memory compatibility.

M.2 volume support already enabled.

DSM successfully checked disk compatibility.
root@DS3:~#

Update added to ds720+_host_v7.db:
"WD80EFZX-68UW8N0":{"default":{"compatibility_interval":[{"compatibility":"support","not_yet_rolling_status":"support","fw_dsm_update_status_notify":false,"barebone_installable":true}]}},"WD_BLACK SN770 2TB":{"default":{"compatibility_interval":[{"compatibility":"support","not_yet_rolling_status":"support","fw_dsm_update_status_notify":false,"barebone_installable":true}]}}

Okay, I understand now. It will only show edits if you run it with -s AND it needs to make changes. I thought it would show what edits had been previously made to the existing files.


bump: bump lua-reqwest in Makefile to fix macos build error

Summary

Checklist

[ ] The Pull Request has tests
[ ] A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
[ ] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

https://konghq.atlassian.net/browse/FTI-6338

I have tested, it could work for me on my macOs env.

Me too


Making a gun slider with the VRTK_Slider?

Does this work or is there a way to do this? I tried it but then the gravity doesn't work

I suspect you want to pull the slider and upon releasing it should go back to its original position? The slider control would probably give you the ability to move the gun slider and get nice events when the "reload" position was reached, but it will not move back as of now automatically.
My guess would be it's probably easier to use a manual setup with a spring joint here for now but it might be worth looking into it and extending the control with another one that uses the "spring slider" setup.

I have kindof got something working, but the slider just floats in mid-air, and doesn't follow the gun. Rigidbodys dont even work on VRTK_Sliders

Some more details would be great or even better a reproduction setup/scene.

stonefox committed this earlier today :)
https://github.com/thestonefox/VRTK/pull/666/commits/c1b65bb95651d8444bdfe3093a5932a66b4cea2b

I was about to say what @pargee  said but yeah I added a gun with a configurable joint slider :)

i love you


[DNM] Test griddata invalid memory access

Do not merge, PR to diagnose memory issues in #8290

The error reproduced with commit 3ee8ba98c1dd49fa7589f914c2d55e4988c143b3 (9ec472c66 + griddata PR): https://ci.preferred.jp/cupy.linux.cuda120/169855/
Now try running under compute-sanitizer.
/test cuda120

/test cuda120

/test cuda120

:eyes: https://storage.googleapis.com/chainer-artifacts-pfn-public-ci/cupy-ci/170414/log.txt
cupyx_tests/scipy_tests/interpolate_tests/test_ndgriddata.py .......========= Invalid __global__ read of size 4 bytes
=========     at 0x8910 in kerFindClosestTri(Point2 *, int, Tri *, int, TriOpp *, long long *, unsigned int *, Point2 *, Point2 *, const double *, const double *, Point2 *, Point2 *, double, bool, int *, double *)
=========     by thread (3,0,0) in block (0,0,0)
=========     Address 0x7f2c872003f4 is out of bounds

cc/ @takagi

OMG, --pading makes this difference...
https://github.com/cupy/cupy/pull/8290#issuecomment-2175045559

I couldn't reproduce it locally, even with --padding. Maybe some parameters specific to GPU?

I tried locally with L40S, A100, V100, P100 but unable reproduce this... 😢

/test cuda120

https://ci.preferred.jp/cupy.linux.cuda120/171562/

https://ci.preferred.jp/cupy.linux.cuda120/171645/

https://ci.preferred.jp/cupy.linux.cuda120/171790/

Hmm, I guess the illegal memory access is happening because kernel cache in our CI is polluted for some reason...

https://ci.preferred.jp/cupy.linux.cuda120/171916/

https://ci.preferred.jp/cupy.linux.cuda120/171917/

https://ci.preferred.jp/cupy.linux.cuda120/171918/


Fix collector release

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/meow

/meow space


Addition of tooltips and popovers

Do you plan on supporting a tooltip or popover component like bootstrap-for-ember has?

Sure,
I'll keep this ticket open for future reference,
Thanks.


Can the  parameter of the dodecane  in DP-GEN v0.8 be used for the latest version DPgen?

Dear developer:
In the latest version of DPgen manual, https://docs.deepmodeling.com/projects/dpgen/en/devel/run/param.html . There are no some parameters in your dodecane_v1.json. For example, "train_param": "input.json". Can you indicate which parameters need to be modified to match the latest version of DPgen?

The manual is still under development.


ci-fix: pipeline migration

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

[jx-info] Hi, we've detected that the pipelines in this repository are using a syntax that will soon be deprecated.
We'll continue to update you through PRs as we progress. Please check #8589 for further information.

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
dfb3537b68e6c5f0ddb6861d552bb03041f23fb3
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
704c6c074cf43b7afa3e139f7aa2168cfc6d4b40
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest pr

/retest

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
704c6c074cf43b7afa3e139f7aa2168cfc6d4b40
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test pr

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
704c6c074cf43b7afa3e139f7aa2168cfc6d4b40
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
55686af9f5516c3344b6d60d2f3cc7f92ab31bb2
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
5444a33006b923008f71be217ad4c50a0fa4e6a8
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
8da3a68fafa40fbe048bd363504bda99bcac3896
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test pr

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
8da3a68fafa40fbe048bd363504bda99bcac3896
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test pr

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
8da3a68fafa40fbe048bd363504bda99bcac3896
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
2b7c1a74db1060c8d4f11add940721637d81c59f
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
e61a3b6aacee8d2832da923a4f02e11042ff3363
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
b5deb2c5ff197b9aa243285b15c43b54eed8bc5d
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
baadecdfbc7f4980de7ebe710faa3626a8ec7867
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/test pr

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign peaqbot
You can assign the PR to them by writing /assign @peaqbot in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@niazhussain: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pr
5cfc08c5bdc0a202c66dba3083ff9e8e99495902
link
/test pr

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.


Add sudo Commands to Reference Docs

Add missing sudo commands to reference docs and update flags and additional info for all commands to dusk-8.

Closing because sequencer sudo commands are no longer part of the astria-go cli.


Parameterize XML reports file name

Fixes # .
Did you remember to?

[ ] Add test case(s)
[X] Update CHANGES.txt

We encourage pull requests that:

Add new features to TestNG (or)
Fix bugs in TestNG

If your pull request involves fixing SonarQube issues then we would suggest that you please discuss this with the
TestNG-dev before you spend time working on it.

@juherr - This is the PR that is related to my comment here


[QUESTION] Log context inside middlewares

[ x] I've read the docs of nestjs-pino
[ x] I've read the docs of pino
[ x] I couldn't find the same question about nestjs-pino
Question
Is there any way to get a working log context inside nestjs (or even raw express) middlewares? The code above just get the request id (from http-pino's genReqId) for the Response sent log, while Request received remains with no context information.
Already tried some workarounds but none of them is working properly. Maybe could be related to https://github.com/iamolegga/nestjs-pino/issues/803 (not sure)
export class LoggingMiddleware implements NestMiddleware<Request, Response> {
  private readonly logger = new Logger("HTTP");

  use(request: Request, response: Response, next: (error?: unknown) => void) {
    this.logger.debug("Request received", ...); // no request id here

    const originalSend = response.send;
    response.send = (rawBody: unknown): Response => {
      this.logger.debug("Response sent", ...); // request id present

      response.send = originalSend;
      return response.send(rawBody);
    };

    return next();
  }
}

This middleware is the first one loaded on nestjs request lifecycle. I can't use interceptor for that because I need to log request/response considering other application middlewares as well, and interceptors are executed after all middlewares. Any suggestions?
Please mention other relevant information such as Node.js version and Operating System.

must be middlewares order. debug or just add console.log() in your middleware and bindLoggerMiddleware in node_modules/nestjs-pino/LoggerModule.js to check the order. When you will see that your middleware goes before logger's middleware move LoggerModule.forRoot() to make it run before your own middleware

You were right @iamolegga, it was that. Thanks!

Yep, definitely this need to be added to FAQ

Hi, I'm facing a similar issue. Could you pls help me understand how to make it run before your own middleware?

move LoggerModule to the first place in imports array

I tried update the imports order in AppModule, but no luck.
@Module({
  imports: [
    LoggerModule.forRoot(  // <----- LoggerModule is the first in the imports array
      {
        pinoHttp: {
          autoLogging: false,
          quietReqLogger: true,
        }
      }
    ),
    CoreModule,
    CatsModule,
  ],
})
export class AppModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(FoobarMiddleware).forRoutes("*");
  }
}

Is any other change needed?
Here is a sample app: https://github.com/hliang/nest-sample-cats-app/tree/pino-log-middleware

move FoobarMiddleware middleware to a separate module and apply it there, import foobar module last. Nestjs has not guarantee for the middlewares order. If that won't help you can try this: https://github.com/iamolegga/nestjs-configure-after

That works! Thank you!
I moved the middleware into the CoreModule which is the first imports.
@Module({
  providers: [
   ...
  ],
})
export class CoreModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(FoobarMiddleware).forRoutes("*");  // <---- middleware moved to here (was in AppModule)
  }
}


Remove EntityReferenceName-fields from the generated context

Today we generate two fields per EntityReference:

EntityReference (e.g. ParentAccountId)
EntityReferenceName (e.g. ParentAccountIdName)

As far as I can see, the *Name fields are always null when fetched with QueryExpression. They are filled out when fetched via FetchXML (but I do not see that as a real use case when using XrmContext).
We currently generate these fields since CrmSvcUtil generates them. I suggest removing the *Name fields, since it causes confusion for new developers (who think they can actually use them).

Fixed in<PHONE_NUMBER>159643b30e15f30c29cd375af39039


gitlab-runner-v1: remove v1 package

Motivation for this change
It was required for gitlab < 9 which is not supported anymore since some time.
While removinf the V1 the patch was refreshed to cleanly work with version 11.x
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

@GrahamcOfBorg build gitlab-runner

Success on x86_64-darwin (full log)
Attempted: gitlab-runner
Partial log (click to expand)
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
find: '/nix/store/yhm2ixrr1w120v0yh8iwqq6k0ycbslx4-gitlab-runner-11.3.1': No such file or directory
/nix/store/9ajwizkm0riz4g477pc1pdl7y1703aal-gitlab-runner-11.3.1-bin

Failure on aarch64-linux (full log)
Attempted: gitlab-runner
Partial log (click to expand)
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/opencontainers/runc/libcontainer/devices
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/docker/docker/oci
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/prometheus/client_model/go
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/matttproud/golang_protobuf_extensions/pbutil
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/docker/distribution/registry/storage/cache
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/docker/distribution/registry/storage/cache/memory
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/docker/distribution/registry/client
gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/docker/distribution/registry/client/auth
builder for '/nix/store/qgqbsk4374pgv62v98hy6xdb78g4b9gk-gitlab-runner-11.3.1.drv' failed with exit code 24
error: build of '/nix/store/qgqbsk4374pgv62v98hy6xdb78g4b9gk-gitlab-runner-11.3.1.drv' failed

Success on x86_64-linux (full log)
Attempted: gitlab-runner
Partial log (click to expand)
shrinking /nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin/bin/pull-images-for-tests
shrinking /nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin/bin/gitlab-runner
shrinking /nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin/bin/gitlab-runner-helper
shrinking /nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin/bin/scripts
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin/bin
patching script interpreter paths in /nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin
checking for references to /build in /nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin...
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
/nix/store/myl869rk3h0vbk7sl60da64vm5lzn4f0-gitlab-runner-11.3.1-bin

aarch64 failure looks unrelated, see https://github.com/NixOS/nixpkgs/pull/47623#issuecomment-426053955


Creating reference (or reference-to-const) from a class_t

I'm not sure how to accomplish the following: I have a class_t and would like to create a reference to this class. Finally I would like to get the full name. For example, my global namespace has an Object and I would like to create a Object& or even const Object&.
Here is what I have tried:
>>> c = globalNamespace.class_("Object")
>>> c
<pygccxml.declarations.class_declaration.class_t object at 0x7f7ecd655850>
>>> print(c)
Object [class]
>>> r = reference_t(c)
>>> print(r)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/pygccxml/declarations/cpptypes.py", line 24, in __str__
    res = self.decl_string
  File "/usr/local/lib/python2.7/dist-packages/pygccxml/declarations/cpptypes.py", line 51, in decl_string
    self.cache.decl_string = self.build_decl_string()
  File "/usr/local/lib/python2.7/dist-packages/pygccxml/declarations/cpptypes.py", line 596, in build_decl_string
    return self.base.build_decl_string(with_defaults) + ' &'
AttributeError: 'class_t' object has no attribute 'build_decl_string'

Hi.
You need to pass an object which has a build_decl_string method. That would be any class from the type_t hierarchy. As you are working on a class, you will need to use the intermediary class declarated_t.
So first create a declarated_t object, using c as parameter in the constructor. Use this new object as argument for the creation of a reference_t.
Hope that helps.

@iMichka Thanks that is what I wanted!


Remove the Property Forwarding Clutter

Fixes #456

Includes a fix to draw-and-pick on multi-model layers and a light reorganization of seer-integration.


ffmpeg showing python command window

i keep getting python prompts opening and closing when downloads finish, from what i've assumed to be ffmpeg. i recently added a few new shows that downloaded pretty quickly, and this command prompt kept popping up in my way while i was trying to do other work.
is there a way to use pythonw so the window stays hidden when converting?

I would just adjust the configuration for whatever program is executing the files to point to pythonw instead of python and maybe adjust your environment variables to use pythonw for .py files and see if that helps.
IE edit the config.ini for Sickbeard and point it to pythonw.exe instead of python

i just edited the config to use pythonw for the post processing script. sickbeard itself i had already set to start without a window.
i'll see if that was enough. i dont want to make all py files open with pythonw because i have a few interactive ones where i need to give them a file, or other inputs. using pythonw blocks it from ever showing a window, and they die immediately

the window isnt labeled as a python window anymore, now its clearly ffmpeg. i don't see any flags i can set on it, and i've tried playing with the verbosity.
do you have the same boxes appear when processing, or is it something with the way i've got things setup?

I also have the same boxes appear. As far as I know there's no command line switch to hide the FFMPEG output unfortunately.

I just pushed a new commit that may resolve your issue. It will only work under Windows but give it a try and see if the FFMPEG window is hidden now.

seems to be working. thanks!


Xenlib update to support fatfs on sdmmc

This series is prerequisite to enable FATFS storage on SDMMC for zephyr-dom0-xt application, instead of default littlefs.
It fixes build failure when littlefs is not enabled.
It adds support for DMA debounce buffer in xrun/storage which is required to enable DMA for SDMMC device, because xenlib loads Kernel image directly in foreign guest domain memory which can be used with DMA.
It adds  option to read domain partial device-tree binary from storage with "xu create" shell command.

checkpatch warning is false positive.


When using multiple memcache servers what is dalli's strategy?

I'm experiencing a weird issue. I'm currently using dalli (2.6.4)
I store my sessions in memcache with the dalli gem.
However, sometimes when a session is stored, the next request can't find the session, but the following requests after that can find it.
I am using 3 memcache servers. I was wondering how dalli or memcache distribute data between different memcache servers?
Seems like the issue could be one instance of rails is writing to server 1, and another instance is reading from server 2?
Does dalli/memcached shard?

@arianf you can just check the Dalli's code for your answer https://github.com/petergoldstein/dalli/blob/master/lib/dalli/ring.rb#L31

Closing, since this is described in code/documentation.


Use Node 6 and 8 in Appveyor builds

The dependency-tree dev dependency doesn't seem to work in Node 4 and is causing CI builds to fail. Updated .appveyor.yml to use Node 6 and 8 instead.

There's a failing test in Node 8: https://ci.appveyor.com/project/AnalyticalGraphics/gltf-pipeline/build/732

@ggetz The failing tests should be fixed. There were two tests that weren't setting up their buffers incorrectly which was leading to out of bound reads.

Looks good @lilleyse, thanks!


Use session scope for loading test machines.

This speeds up the tests significantly. In order to do this, I have used
a pytest plugin pytest-lazy-fixture.

Coverage remained the same at 93.919% when pulling cd4f52a5f43c094e85717652953c14f07d968725 on test-speedup into bb62a09b7f4f676bb2bf52fddc57063b637c5694 on master.

Coverage remained the same at 93.919% when pulling cd4f52a5f43c094e85717652953c14f07d968725 on test-speedup into bb62a09b7f4f676bb2bf52fddc57063b637c5694 on master.


⚠ Samsung has degraded performance

In 05163fe, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2622 ms

Resolved: Samsung performance has improved in 9e33d1d.


F28 - Provided service versions (aka 'Operand versioning')

This is the feature request received in the past for OLM to expose the "provided service versions" (aka "Operand versioning") offered by the Operator/extension.
As extensions can only be installed once in a cluster as cluster-wide singletons with OLM 1.0, it is likely for an extension to oversee multiple versions of service and utilize a distinct versioning scheme. This should be a part of the OLM v1 requirement.
Related work in the past (Feb, 2021): https://hackmd.io/IEYEaOYkR-eBkMQkbVrC1A?view

cc @cdjohnson @Jamstah @pgodowski

cc @cdjohnson @Jamstah @pgodowski

Will review early next week, thanks for sharing!

This PR focuses mainly on operator-to-operator dependencies, which is a great use case for being able to determine the service versions and keep the operator dependency graph complete.
The other high level use case for this is user selection of service versions, which I feel we should include more strongly. For example, if the user has a kafkas.apigroup.provider.com CR that is at operand version 3.4.0 then we shouldn't allow (or should at least warn) if the operator providing that API is upgraded past the point where it supports 3.4.0 any more. This would require that OLM have an idea of which field in the CR indicates the service version that is currently in use for that API.
Potentially, even if the user doesn't have a CR using that operand version right now, if that's what they asked for at install time then they should be warned if that service version is going away, although I'm not sure how/where that dependency would be recorded, or if we need it. Perhaps in the subscription? I guess this would be an issue for job style CRs that are created temporarily. Certainly a less urgent use case.

if the operator providing that API is upgraded past the point where it supports 3.4.0 any more.

That's a breaking change and that would warrant a major version bump of the operator. And I would expect:

operator authors to disclose this breakage in release notes
users not to upgrade to a version that contains a breaking change without understanding the ramifications.

Beyond that, the implications here seems to be that:

APIs for services have a spec field somewhere that contain a service version string
OLM knows how to find that field for each service API.

IMO, that is too opinionated. What if an API wants to expose the desired version as a range or as a channel containing multiple versions?  IMO, going this far is beyond the scope of what I think OLM should have awareness of.

APIs for services have a spec field somewhere that contain a service version string

I would have said that it would be a status field not a spec field, where the operator has resolved the constraints and reconciled a specific version, that then needs to be supported through any operator change.

OLM knows how to find that field for each service API.

Yes, OLM would need to know which field to look for, and that would need to be specific in some way (in the CSV?).

I guess that's easier to track.

That's the case because the thing that removes the deprecated API is the same thing that is doing this tracking, right? The analogy holds if the operator (which owns this API) is the thing doing this checking.
We're planning to have an OperatorHealth sort of API where the operator can raise these sorts of things and potentially prevent upgrades.

Right, but the currently installed operator doesn't know the capabilities of the next one, so it doesn't know to prevent the upgrade.
Maybe that's why we need a pre-install hook of some kind. I'm definitely all for the operator making the call, because I don't think we can rely on operand versions being semver, which means only the operator can safely parse them.

My overall perspective I think remains the same.

There are two separate use cases here (dependency resolution and disconnected mirroring) that, IMO, are sufficiently different that the suggested API (declaration of supported service versions per bundle) can't solve them both in a way that supports the various approaches operators take to orchestrate their operands.
I think adding this specific API, even if optional, will lead to us enshrining undesirable incentives. Use of this API will be perceived as a maturity thing: "Immature operators don't specify it, mature operators do." But that's an invalid assumption. Some operators don't have service versions at all. Others might have complex logic around choosing an operand version without actually exposing a direct choice by the end user. If we move forward with this API, I worry that we will pre-dispose operator authors to build their operators in a way that requires them to accept operand versions in their CRDs, and that might be a worse end-user experience than the operator managing the operand version.
This opens a door that makes it more likely for operator authors to remove support for operand versions in a non-major-version-bump of an operator. It gives them a way to say, "Yeah, I removed support for an operand version, but I told you I did that, so it's not my responsibility to prevent upgrades if existing operands are at versions unsupported by the upgrade". This is not something OLM would be able to know (easily at least). If operator v1.28.0 supports operand versions v3.0.0 and v3.1.0 and lets an end user state their desire for v3.0.0 in an API, then all future operator v1 versions need to continue supporting v3.0.0. Otherwise the existing CR that says "use v3.0.0" will break.

TL;DR: I think we're trying to make OLM "all things for all people", and in doing so, I think we're wrapping ourselves into knots. I'm worried this is another knot. It solves one set of use cases, but adds friction to other -- equally valid -- use cases.

There are two separate use cases here (dependency resolution and disconnected mirroring) that, IMO, are sufficiently different that the suggested API (declaration of supported service versions per bundle) can’t solve them both in a way that supports the various approaches operators take to orchestrate their operands.

This API being optional is just so that the API does not need to support all kinds of approaches Operators take to orchestrate their operands, but the majority of the use cases (e.g., operand versioning following semver, etc).

I think adding this specific API, even if optional, will lead to us enshrining undesirable incentives. Use of this API will be perceived as a maturity thing: “Immature operators don’t specify it, mature operators do.” But that’s an invalid assumption. Some operators don’t have service versions at all. Others might have complex logic around choosing an operand version without actually exposing a direct choice by the end user. If we move forward with this API, I worry that we will pre-dispose operator authors to build their operators in a way that requires them to accept operand versions in their CRDs, and that might be a worse end-user experience than the operator managing the operand version.

This API does incentivize Operator authors to denote provided service versions clearly to their users following the guidance if their Operators do provide managed service(s) to showcase their maturity and I’d argue it’s in a good way.  There are Operators out there that don’t ship any CRDs at all, but they are not viewed as inferior simply because of that.  But if they do provide managed service(s), and they don’t clearly denote the supported version, then that’s a valid maturity issue.

This opens a door that makes it more likely for operator authors to remove support for operand versions in a non-major-version-bump of an operator. It gives them a way to say, “Yeah, I removed support for an operand version, but I told you I did that, so it’s not my responsibility to prevent upgrades if existing operands are at versions unsupported by the upgrade”. This is not something OLM would be able to know (easily at least). If operator v1.28.0 supports operand versions v3.0.0 and v3.1.0 and lets an end user state their desire for v3.0.0 in an API, then all future operator v1 versions need to continue supporting v3.0.0. Otherwise the existing CR that says “use v3.0.0” will break.

I don’t see how adding this will exacerbate “operator authors to remove support for operand versions in a non-major-version-bump of an operator” but rather with this Operand versioning thing, it helps greatly to expose this to the end-users, so users can either better prepared for that, or simply walked away toward another Operator does better in honoring semver.  Just as you mentioned, without this Operand versioning, even OLM is having a hard time telling “if existing operands are at versions unsupported by the upgrade”.  This is exactly the reason this API is critical to improving the visibility of this to both OLM and the end-users.

Late to the party, it seems like we are discussing a couple of things in parallel so here is my attempt to bring into one larger picture:
A) users, relying on workload-managing operators, generally have a great desire to know upfront (before install or upgrade) what versions of the workload the desired operator version can manage
To your point @joelanford - not all operators are workload-managing operators. This kind of data will not make sense for something like Tekton or Isitio, which generally represent control planes and event-based automation facilities instead of managing a workload that is the actual thing that is consumed. Also automation-focussed operators like a namespace-configuration operator or cert-manager will not take value from this.
But the workload-managing operators category is real and is providing a lot of value to users. By hiding this critical piece of information from them, that value will be hard to get to. One would imagine how successful managed cloud services like AWS RDS would be, if they simply would never tell users what version of Postgres the service is able to manage.
That said, I don't think it incentives breaking changes in minor release versions anymore than OLM currently incentivises breaking changes in the operator APIs due to OLMs enforcement of semantic version strings for bundles. OLM doesn't bark if you remove an entire CRD in a minor version. Still, we see value in enshrining the semver concept in operator versioning to convey the recommendations associated with that. That value isn't lowered just because we aren't always able to enforce it at runtime in all cases. Rather the presence of this data allows test systems to check for this behavior. Equally, with operand information we would allow test systems to call our operators that are removing operand versions within a minor or patch release.
I also argue that this leading to a notion of more vs. less mature operators is a good thing. An operator that provides more metadata and supports multiple versions of a managed workload and also calls this out publicly with a well-maintained list of versions is more mature IMHO, because it gives users what they need. But this can only be a comparison between workload operators. I think we can expect people to be aware enough of the intent of this, to not call out cert-manager as immature because it doesn't provide operand versions.
On the other hand, I would be curious to learn more about the example:

Others might have complex logic around choosing an operand version without actually exposing a direct choice by the end user.

Do we know of an example? I almost seems like a missed opportunity by the operator to provide more controls and nuance. And even when an operator does that at runtime, isn't the logic around that caused by variable input from the user? I.e. a version of another component. Regardless, if an operator has a good reason not to expose a choice her, they can opt out of providing the operand version data as well.
B) OLM resolving based on operand information
I think it's important to remind ourselves that OLM is not a workload manager. It is generally not aware of what the operators are exactly doing, nor should it be.
So I think it would be out of scope for OLM to try to predict what happens to operator-managed things when the operator updates. There are a couple of obvious scenarios, like removing CRDs that will delete the CRs and therefore most likely also the workloads they represent, that we catch. But I don't see us going beyond that. So OLM would not make assumptions about how the user specifies the versions for a desired workload, e.g. on which CR or in which field. This knowledge is in the operator and IMHO that is the best place for it. It can still communicate with OLM based on this knowledge:
for instance, an operator updating to a newer version that drops support for an operand version that is found on cluster could leverage the preflight check facility in F6 to block the update from going through. There is no need for OLM to try to solve that scenario generically.
What is in OLMs realm is using this information as additional constraints when resolving dependencies. If operator A says it needs operator B and operand B.v1.1, OLM shouldn't update B to a version that only provides operand B.v2.0 and not v1.1 anymore (of course an admin would always be able to force it through). That's where this feature provides additional value in the form of safety. The scenario I see is: popular operators used by multiple products and open source projects as a shared dependency but serving different requirements in regards to the version of the managed workload provided.
I would go as far saying that without operand versioning information here, the concept of shared dependencies of operator will not be something the community can adopt, ultimately hampering reuseability and growth of open-source projects.
C) Mirroring based on operand information
There seem to be two issues here:

we can't expect all operands to follow well-known versioning schemas, so useful things like version ranges or sorting cannot be applied.

We could tackle this in a couple of ways: we could either say that like operators, also operands should follow semver. And by looking at the ecosystem, I think we stand a good chance to capture the majority of users / projects / software here.
We could also say we fall back to simple lists, which are harder to maintain than ranges, but not insurmountably hard. We will likely never find a solution that works for everyone and everything out there, so I'd encourage us to have an opinion that enables a majority of the software and incentives a useful pattern.

we are afraid that if people don't mirror the right operands, the operator will inevitably run into image pull errors and we think that this will be on OLM to blame

IMHO, with our current mirroring concept, would likely end up doing the equivalent for operand versioning of what we are already doing for channels and packages in catalogs today: we mingle with the list of stuff in the mirrored catalog. That is, if a users filters out an operand version during mirroring, the resulting catalog would also not contain that operand version reference. This way, we convey to the user correctly what's available in the mirrored environment.
I know we are also thinking about different approaches to mirrored catalog, where we would have other ways of denoting if an operator channel, package or individual version was mirrored or not. We could do the same with the operands.

@Jamstah @perdasilva @joelanford @tlwu2013 What do we think, how do we move forward here?

I'm seeing three requirements:

Operator admins should be able to see which operand versions each workload-based operator supports.
Operator admins have guarantees that they can install an operator that supports their desired operand version(s).
Operator authors have guarantees that they can list operator dependencies that support the necessary dependency operand version(s).
When mirroring a catalog, mirroring users can select a subset of the related images to mirror, based on desired operand version(s).

Maybe I'm getting hung up on the prescriptiveness of the implementation in the PR (i.e. there shall be a new field for a list of service versions, operand version shall be constrainable). Perhaps we could reword it to look more like the above?

I think that's a good list, I might add:

Operator admins have guarantees that the operator won't be upgraded to the point where it no longer supports the operands.

The easy bit here is an operator knowing itself what it supports. The hard bit is knowing what something that isn't yet installed supports to know its going to be suitable for the job. To write that down in a way that is flexible enough may be impossible, we're expecting to be able to communicate knowledge to OLM that it really shouldn't need to have, like:

Which field on a CR is an operand version?
How do we match that to images?
Are there fields for specific features that may have been deprecated?

If we do build that model, I'm 90% sure that there will immediately be requests to extend it with additional checks for more specific cases.
I feel like we may need a way for an uninstalled operator to look at a cluster and say if it can or cannot reconcile what is already existing on it. Perhaps a CSV could include a pre-install/pre-update Job of some kind for that purpose.... it wouldn't solve all the use cases, but I feel many of them could be solved with documentation if we take the sharp edges out of install.

I'm seeing four requirements:
1. Operator admins should be able to see which operand versions each workload-based operator supports, by operator version.

2. Operator admins have guarantees that they can install an operator that supports their desired operand version(s).

3. Operator authors have guarantees that they can list operator dependencies that support the necessary dependency operand version(s).

4. When mirroring a catalog, mirroring users can select a subset of the related images to mirror, based on desired operand version(s).

Maybe I'm getting hung up on the prescriptiveness of the implementation in the PR (i.e. there shall be a new field for a list of service versions, operand version shall be constrainable). Perhaps we could reword it to look more like the above?

Done with the editing. Can we start another round of review?  thanks!

I think that's a good list, I might add:

Operator admins have guarantees that the operator won't be upgraded to the point where it no longer supports the operands.

@Jamstah, I've also added the "upgrade" piece to the latest change:

Extension admins are guaranteed to install or upgrade an extension that supports their desired operand version(s).

This looks good to me.

High-level, I'm comfortable with some sort of optional API operator authors can use to declare which versions of an operand are supported by a particular operator version. This seems to dovetail with some recent conversations we've had about making operators more multi-tenant capable.
However, I think there is still MUCH to discuss about the mechanics of this and how it would work. E.g. what if an operator supports upgrading an existing workload from a particular operand version, but not installing or upgrading to that version?
I still think this feature description seems too presumptive about how operators would (or wouldn't) expose operand version selection to users.
So my stance is that I'm okay to merge if the goal here is to capture a high-level idea of supporting some sort of feature about operand version support awareness for admins. But I am not ready to say that what is described can or should be implemented without more design discussion.


Load Library on WebIDE and Launchpad

Hi John,
Have you succeed to do work the add-on with WebIDE and Launchpad ?
As you have mentionned on previous Issues, i tried to :
var myRootPath = jQuery.sap.getModulePath("CustomerDB");
sap.ui.getCore().loadLibrary("openui5.googlemaps", [myRootPath,"openui5/googlemaps/"].join("/"));
But it doesn't work and produced the following error :
Uncaught Error: found in negative cache: 'com/codilog/Component.js' from ../../../../../webapp/Component.js: Error: failed to load 'openui5/googlemaps/library.js' from ../../../../../resources/CustomerDB/openui5/googlemaps/library.js: 404 - Not Found
Have you a tips ?

looking on slack i can see that the googlemaps library is under
CustomerDB/js
in which case you will nee to do something like
sap.ui.getCore().loadLibrary("openui5.googlemaps", [myRootPath,"js"].join("/"));

Hello John,
I have tested several method.
I have tried your solution, and no good result :(
My tree : CustomerDB/webapp/openui5/googlemaps/
And Component.js under webapp
In component.js :
var myRootPath = jQuery.sap.getModulePath("CustomerDB");
sap.ui.getCore().loadLibrary("openui5.googlemaps", [myRootPath,"openui5/googlemaps/"].join("/"));
And the error message :
Uncaught Error: found in negative cache: 'com/codilog/Component.js' from ../../../../../webapp/Component.js: Error: failed to load 'openui5/googlemaps/library.js' from ../../../../../resources/CustomerDB/openui5/googlemaps/library.js: 404 - Not Found


Black screen when and no audio when playing video

I'm submitting a ...

[ x] bug report
[ ] feature request
[ ] support request

General information
Addon version used
0.14.6
[eg. 13.21.0]
Description
[Description of the bug or feature]
Steps to Reproduce

start kodi
open netflix addon
select a series and navigate to episode
start episode, get play symbol, loading wheel, black screen, no audio and timestamp progresses but nothing plays
Expected behavior: [What you expected to happen]

Actual behavior: [What actually happened]
Context (Environment)
Installation

[x ] I'm using this Netflix Repo
[ ] I'm using other Netflix Repo (Please specify which)
[ ] I'm using a different source (Please tell which)

Operating System

[ ] Linux (x86/x64)
[ ] OSX (x86/x64)
[ ] Windows (x86/x64)
[ ] Linux (ARM)
[x ] Android
https://paste.kodi.tv/poxeherene.kodi

Additional informatin on the environment
[Descripe your environment a bit more detailed, are you using LibreElec f.e.]u
[e.g. detailed explanation, related issues, suggestions how to fix, links for us to have context, etc.]
Screenshots
[Please add a screenshot if that helps understanding your problem]
[You can erase any parts of this template not applicable to your Issue.]

Please enable debug logging in Kodi and post logs again.

https://paste.kodi.tv/fifupuhuwa.kodi

Can you try enabling HEVC in settings/expert? It may solve the problem.
Also, is it your first attempt or is it after any upgrade (addon, kodi, or even Android) ?

I tried enabling it. Closed kodi and reopened but same results.
This is my 1st attempt no updates

Try deleting .kodi/cdm and addona/inputstream.adaptive/cdm contents , basically find libwidevinecdm.so and delete it....
Si it will install Widevine again.
Also disable OMX Codec, I have had very frustaring times trying OMX. I have to use pa or MMAL


wasm: update rules_rust to latest.

Signed-off-by: Piotr Sikora<EMAIL_ADDRESS>

/lgtm deps


Echo path impulse responses?

In the folder https://github.com/microsoft/AEC-Challenge/tree/main/datasets/RIRs README, it says "This folder contains room impulse responses (RIRs) measured on real devices." I can only see the csv metadata file, however, and not the full impulse response files themselves.
Any chance the full impulse response will be available? Maybe I just missed something?
Thank you for the awesome dataset!

The full responses are in files named Sweep

Nice, thanks!

@andosa, do the full responses exist for the synthetic dataset?

No, the sweep files are only in the real recordings dataset


python312Packages.mobly: 1.12.3 -> 1.12.4

https://github.com/google/mobly/blob/refs/tags/1.12.4/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

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

[x] 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/)
24.11 Release Notes (or backporting 23.11 and 24.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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Failing packages are already broken on master.


simplify yaml package: replace github.com/ghodss/yaml with sigs.k8s.io/yaml

Please provide a description of this PR:
istio has four yaml related packages, as below,
github.com/ghodss/yaml
gopkg.in/yaml.v2
gopkg.in/yaml.v3
sigs.k8s.io/yaml

we can simplify these packages only to one, we can keep only the one package.
this pr replace package github.com/ghodss/yaml with sigs.k8s.io/yaml
To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Please check any characteristics that apply to this pull request.

[X] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

@gy95: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test release-notes_istio

gencheck_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test gencheck_istio

unit-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@gy95: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test release-notes_istio

gencheck_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test gencheck_istio

unit-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test unit-tests_istio

integ-pilot-istiodremote-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-istiodremote-tests_istio

integ-telemetry-k8s-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-telemetry-k8s-tests_istio

integ-pilot-istiodremote-multicluster-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-istiodremote-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@gy95: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test release-notes_istio

gencheck_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test gencheck_istio

unit-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test unit-tests_istio

integ-pilot-istiodremote-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-istiodremote-tests_istio

integ-telemetry-k8s-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-telemetry-k8s-tests_istio

integ-pilot-istiodremote-multicluster-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-istiodremote-multicluster-tests_istio

integ-pilot-k8s-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-k8s-tests_istio

integ-cni-k8s-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-cni-k8s-tests_istio

integ-pilot-multicluster-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@gy95: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test gencheck_istio

unit-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test unit-tests_istio

integ-pilot-istiodremote-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-istiodremote-tests_istio

integ-telemetry-k8s-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-telemetry-k8s-tests_istio

integ-pilot-istiodremote-multicluster-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-istiodremote-multicluster-tests_istio

integ-pilot-k8s-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-k8s-tests_istio

integ-cni-k8s-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-cni-k8s-tests_istio

integ-pilot-multicluster-tests_istio
ea85963154904e7cda99944f66f67ff243c97b63
link
true
/test integ-pilot-multicluster-tests_istio

release-notes_istio
f5dcc3514e5db51e96c0a3f5ab8284410dd6de39
link
true
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Ref docs issue

Error:

: Unpacking sdist file D:\a_work\1\s\dist_temp\10\azure-ai-translation-text-1.0.0b1.zip to destination source_code\10.
: Uncompressing the zip file D:\a_work\1\s\dist_temp\10\azure-ai-translation-text-1.0.0b1.zip.
: Getting name information of package in D:\a_work\1\s\dist_temp\10\azure-ai-translation-text-1.0.0b1.
 Running commandline: & 'python' setup.py --quiet --dry-run --name 2>&1
azure-ai-translation-text
: Getting version information of package in D:\a_work\1\s\dist_temp\10\azure-ai-translation-text-1.0.0b1.
 Running commandline: & 'python' setup.py --quiet --dry-run --version 2>&1
1.0.0b1
: Getting author information of package in D:\a_work\1\s\dist_temp\10\azure-ai-translation-text-1.0.0b1.
 Running commandline: & 'python' setup.py --quiet --dry-run --author 2>&1
Microsoft Corporation
: Unpacked D:\a_work\1\s\dist_temp\10\azure-ai-translation-text-1.0.0b1.zip into source_code\10...
: Fetching source code from PyPI...
: Downloading azure-ai-vision==0.13.0b1 from PyPI...
Looking in indexes<EMAIL_ADDRESS>CI/_packaging/Content_CI_PublicPackages/pypi/simple
##[error]ERROR: Could not find a version that satisfies the requirement azure-ai-vision==0.13.0b1 (from versions: none)
ERROR: No matching distribution found for azure-ai-vision==0.13.0b1
: Downloading failed.

For more details check here:

https://apidrop.visualstudio.com/Content CI/_build/results?buildId=382187&view=results

@danieljurek for notification.

This issue has been resolved. Turns out the problem isn't the cache, it's that the package is published in a way that fails when specifying the default prefer_source_distribution of true in our EngSys. This has been corrected in the metadata JSON file for that package.


TypeScript - Incorrect no-use-before-define warning

Describe the bug
Incorrect no-use-before-define warning when using TypeScript.
Did you try recovering your dependencies?

Yes.
Which terms did you search for in User Guide?

N/A
Environment

System:
  OS: macOS Sierra 10.12.6
  CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
Binaries:
  Node: 9.4.0 - ~/.nvm/versions/node/v9.4.0/bin/node
  Yarn: Not Found
  npm: 6.5.0 - ~/.nvm/versions/node/v9.4.0/bin/npm
Browsers:
  Chrome: 75.0.3770.100
  Firefox: 65.0.1
  Safari: 12.1.1
npmPackages:
  react: ^16.8.6 => 16.8.6
  react-dom: ^16.8.6 => 16.8.6
  react-scripts: ^3.0.1 => 3.0.1
npmGlobalPackages:
  create-react-app: Not Found

Steps to reproduce

Run npx create-react-app my-app --typescript
Open / create a .tsx file and write the code below:

type Foo = ReturnType<typeof bar>
const bar = (): string => 'baz';

Run react-scripts start command.

Expected behavior

Should emit all files without any warning.
Actual behavior

Line 11:  'bar' was used before it was defined  no-use-before-define

Reproducible demo

See code / example upper.

Update — Published npm module hasn't the same rules as specified in the Git repository.
eslint-config-react-app (4.0.1) - (fetched via react-scripts)
'no-use-before-define': [
	'warn',
	{
		functions: false,
		classes: false,
		variables: false,
	},
]

/packages/eslint-config-react-app (4.0.1) - GitHub
'no-use-before-define': 'off',
'@typescript-eslint/no-use-before-define': [
	'warn',
	{
		functions: false,
		classes: false,
		variables: false,
		typedefs: false
	}
]

Thanks, a new version should be released soon.

This fix has been released.


Use real lodash instead of custom lodash.* builds

Most people use lodash and not lodash.isequal or lodash.find. They are custom builds of lodash, with a lot of duplicated code, and results in really heavy bundles.
Today I have to alias lodash.find to lodash/find and lodash.isequal to lodash/isEqual in my apps in order to prevent the duplicated code.
For reference, for etalab/inspire, my output bundle is 5.88 KB (gzipped) heavier when I’m not aliasing lodash.find and lodash.isequal to their counterparts in lodash.

Let me rebase this. :)

Thanks!

Done, and updated main comment to include size diff of the UMD builds. :)