New version: RoyalApps.RoyalTS.V7 version 7.02.50301.0

Pull request has been created with komac v2.1.1 :rocket:

Resolves #142822

Microsoft Reviewers: Open in CodeFlow

For moderators
This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping Exorcism0666.

[!warning]
With the new version of Komac, numerous Pull Requests may contain bugs or unwanted elements. If such issues arise, please tag russellbanks so that these bugs can be addressed in future updates.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！

Hi @Exorcism0666,
This manifest adds Apps and Features entries that aren't present in previous PR versions. These entries should be added to the previous versions, or removed from this version.
(Automated response - build 867.)


Process library Wait For Process keyword does not return when used with some adb commands

Ugh
I am using Robot Framework 2.8.7 (Python 2.7.6 on win32), on Windows 7 (64bit).
When I do this:
*** Settings ***
Library           Process

*** Test Cases ***
Example
    ${handle} =    Process.Start Process
    ...    adb
    ...    status-window
    ...    shell=yes
    ...    cwd=${OUTPUT_DIR}
    ${result}=    Process.Wait For Process
    ...    handle=${handle}
    ...    on_timeout=kill
    ...    timeout=15 s

Then the Wait For Process keyword hangs forever. I see this in the debug log (note removed the tilde characters from the log file keyword boundary because github did some fancy formatting):
==============================================================================
20150804 10:49:34.472 - INFO - + START SUITE: Example [ ]
==============================================================================
20150804 10:49:34.473 - INFO - +- START TEST: Example [ ]
------------------------------------------------------------------------------
20150804 10:49:34.474 - INFO - +-- START KW: ${handle} = Process.Start Process [ adb | status-window | shell=yes | cwd=${OUTPUT_DIR} ]
20150804 10:49:34.474 - INFO - Starting process:
adb status-window
20150804 10:49:34.475 - DEBUG - Process configuration:
cwd = C:\workspace\system-test\tests
stdout_stream = -1
stderr_stream = -1
shell = True
alias = None
env = None
20150804 10:49:34.483 - INFO - ${handle} = 1
20150804 10:49:34.484 - INFO - +-- END KW: ${handle} = Process.Start Process (9)
20150804 10:49:34.485 - INFO - +-- START KW: ${result} = Process.Wait For Process [ handle=${handle} | on_timeout=kill | timeout=15 s ]
20150804 10:49:34.485 - INFO - Waiting for process to complete.
20150804 10:49:49.534 - INFO - Process did not complete in 15 seconds.
20150804 10:49:49.535 - INFO - Forcefully killing process.

The adb process is not killed and to recover I have manually kill the adb process. I did expect the adb process be killed after 15 and keyword not to hang forever.
Adb is part of the Android SDK: http://developer.android.com/tools/adk/index.html

Sounds weird. Killing should definitely kill the process in all conditions. Sometimes the process is started by a wrapper and killing the wrapper doesn't kill the process, but in those cases Wait For Process should still return.
I have no idea why this problem occurs or is there any way to fix it. It would be great if you could test this with RF 2.9, although I don't remember there being much enhancements to the Process library since 2.8.7. After that it would be good if you could investigate this issue yourself. Reproducing it doesn't seem to be too easy, and I don't think I have a change to try it in the foreseeable future.

I will try it also with 2.9 and I can run it with the debugger to see where it actually hangs.
If a miracle happens and I do find the reason for the issue and I am able to fixit, will you take pull request to 2.8 series?

We do not plan to make more 2.8 releases. They can be considered if there are critical bugs, but I don't consider this that urgent. Making a local fix shouldn't be hard for you if upgrading to 2.9 isn't possible. Should first find why this happens, though.

Have you tested using terminate instead of kill? See library docs for differences.

Good point, I did only try with kill

You should also try redirecting stdout/stderr to files. There's a possibility that default streams get full and the process hangs.

When adb is launch first time, as in my case it is, it will also launch adb server [1] in the background.
On RF 2.8.7

The Terminate works as designed. The adb status-window process is terminated and adb server is kept running the background.
kill hangs on robot\libraries\process.py line 785: return self._format_output(stream.read()).
Doing this almost works:

*** Settings ***
Library           Process

*** Test Cases ***
Example
    ${handle} =    Process.Start Process
    ...    adb
    ...    status-window
    ...    shell=yes
    ...    cwd=${OUTPUT_DIR}
    ...    stdout=${OUTPUT_DIR}/log.log
    ...    stderr=STDOUT
    ${result}=    Process.Wait For Process
    ...    handle=${handle}
    ...    on_timeout=kill
    ...    timeout=15 s

The keyword returns but both adb server and adb status-window process are left running.
In RF 2.9 result are same, but line number is 768: return self._format_output(stream.read()).
As a summary: using force is not always good thing. But any idea, why the kill behaves badly on the _format_output?
[1] http://developer.android.com/tools/help/adb.html

And this is how it looks when I run it from console:
D:\workspace\test\adb_and_process_lib>adb status-window
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
←[2J←[2HAndroid Debug Bridge
State: unknown

Those tiny arrows are really there, funny.

You shouldn't use shell=yes. It isn't a good idea unless you really need it in general, but here the started shell may actually interfere communicating with the process.

Looking at the commit logs, there doesn't seem to be any changes related to this between RF 2.8.7 and 2.9.

It would be great if you could try starting and terminating the process using the subprocess module directly.  That also allows you to play with different Popen configuration options. I'd especially recommend testing close_fds=True. Notice that, as explained in the docs, you cannot redirect stdin, stdout or stderr on Windows in that case.

I will try with Popen options and lets see how that goes, but not today, it is time for some sleep.

If I have similar setup, the adb server is not running and if I have this:
import subprocess
from time import sleep

f = open('C:\log.log')
p = subprocess.Popen(['adb', 'wait-for-device'], shell=True, stdout=f, stderr=subprocess.STDOUT)
print p.pid
sleep(5)
p.terminate()
f.close()

Or this:
import subprocess
from time import sleep

f = open('C:\log.log')
p = subprocess.Popen(['adb', 'wait-for-device'], shell=True, close_fds=True)
print p.pid
sleep(5)
p.terminate()
f.close()
print 'Done'

Or any other combination of the Popen, which I could thing of.
When I run the script from command line, it does not leave the python script hanging and the python scripts returns normally. I must say that the shell=True causes some problems, because also with Popen, there adb wait-for-device process does not die cleanly and must be manually cleaned.
So a a good workaround, from Robot Framework, is use on_timeout=kill and shell=False. But what next? In my mind, this is a bug, but only a minor one.

Could you clarify what exactly is a bug?

Also, why do you use shell=True? That's False by default and I don't see any reason why you should enable it. In general there is very seldom need to use it on Windows. subprocess docs say this:

The only time you need to specify shell=True on Windows is when the command you wish to execute is built into the shell (e.g. dir or copy). You do not need shell=True to run a batch file or console-based executable.

Bug is that Robot Framework Wait For Process keyword hangs on certain combinations

I totally agree that shell=True is not needed.

Although it's a bug, in best case it's a minor one. Also when I did read the subprocess doc, it's clear that shell=True is not needed. Should we enhance the RF docs also to say similar things as the subprocess docs say?

Yeah, the keyword hanging is a bug. Processes possibly left running on the background wouldn't necessarily be.
What was the combination that hang? You originally reported using on_timeout=kill but later said that on_timeout=kill with shell=False is a good workaround? Was it shell=True that caused the whole problem? In that case I'd understand why the underlying process didn't die because killing just kills the started shell, hanging is still weird.
Adding a note that shell=True is very seldom needed on Windows is a good idea, especially if using that possibly causes problems. It's also a potential security risk, but that shouldn't be an issue with Robot.

Made a copy/paste error when I did say this:
So a a good workaround, from Robot Framework, is use on_timeout=kill and shell=False.
Should have said this:
So a a good workaround, from Robot Framework, is use on_timeout=terminate and shell=False. kill -> terminate. Sorry about the error. The process left in background is not a bug, at least not in my mind.
Setting the shell=True is the root of the problem, if I do not change the default, it works like a charm. With both on_timeout=kill and on_timeout=terminate options. Although the Python subprocess is not the root cause, because with subprocess the shell=True works and does not hang.
I can write update to the documentation and make a pull request. I was thinking to write something to the Process configuration chapter and perhaps linking to the subprocess documentation.
Because there is better/correct way the configure the Start Process keyword and if we update documentation, I do not have an interest to debug the problem any further, why the Wait For Process keyword hangs (Although the tester inside me, is quite pissed off to me, because the root cause is not found and a perfect solution is not found to the bug). @pekkaklarck what you want to do?

The difference between terminate and kill on Windows with CPython is that the former sends CTRL-BREAK event and the latter ends up calling TerminateProcess() Win32 function. The CTRL-BREAK event is send also to possible child processes by default (typically a good thing) but the latter only affects the main process.
It would be interesting to know where exactly the code related to kill hangs. Could you try running it on a debugger or putting  import sys; sys.__stdout__.write('message\n') inside _kill method around process.kill() and also somewhere inside _process_is_stopped method?
I do agree that this problem is pretty minor and not worth spending that much time. It could be argued that the problem is even caused by a user error because it doesn't occur in default configuration. That, then again, really tells us that the docs should be enhanced. Making it more explicit in Running processes in shell section that shell is very rarely needed on Windows is a good idea. Doc enhancements should perhaps get their own issue, tough.

I did run it with debugger, download from here: https://www.dropbox.com/s/jt9kj8e987vuu6a/pdb.log?dl=0
I you want more details, just let me know and I will do it.

That debug log is pretty long and I'm not familiar with the format. Did it hang at the end? The last marked line is return self._format_output(stream.read()) which would indicate that reading process output hangs. That could mean that the process isn't fully stopped or at least its output streams aren't closed.
Did you specify output files when running tests of not? If not, Process library uses subprocess.PIPE and these in-memory streams may become full (that ought to be documented). Did you already test running same hanging example with and without stdout/stderr redirected to files?

Yeah, it is quite long. For me it seemed like Process library did call subprocess to kill the process and when formatting the output it did, for some reason, hang. I can try it make shorter, by not using pdb.step and by more using pdb.return. I did use winpdb [1] console for running the debugger and just stepped and listed the code over. But I am not that familiar with Python debugging, so if there is something that is needed point me to right direction. But it did hang on line return self._format_output(stream.read()) and debugger did also freeze.
I did not specify the output and but if I do it, it looks like this:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Android Debug Bridge
State: unknown

[1] http://winpdb.org/

It cannot be formatting that hangs but stream.read(). Does your latest example hang if you do not redirect stdout/stderr? How big is the output in log.log file?

Any new info about this?

I did try to debug yesterday but I did not find out the reason why it failed. Mainly because the Popen and that part of the RF code is not familiar to me.

Hello Pekka and Tatu,
I struggle also about an equal failure in RF 2.8.7 , reproducible under RF 2.9.2 (Win8.1 64bit, Py 2.7.10).
It seams, that Wait For Process waits , till all sub processes of an observed main process has finished (or maybe handles to logging streams are closed). If such a process starts via subprocess.Popen additional server processes, Wait For Process does not come back.
In my opinion, this implementation is wrong, Wait For Process must come back, when the main process has finish, even when a sub process is still running.
To simulate and test such situation, I published on Gist
a) dummy_worker.py, which simulates a longer running process, which starts a subprocess
b) RF test wait_process_tests.txt Wait and Terminate running Process logging to STDOUT, which fails, cause it waits till also the sub process is finished
c) run_dummy_worker.py, which starts dummy_worker.py and uses equal args as Wait and Terminate running Process logging to STDOUT . It come back much earlier than RF.
I'm not really sure, if my tests uses correct args to start the processes. But my hope is, that this  helps to discover the problem.
Regards Luiko

Does your example pass if you write stdout to a file?
Process lib uses some additional config compared to your example. See its sourrce for details if you want to emulate its behavior with pure Python.
I doubt I have time to look at this in more detail in the near future. It would be great if you could investigate this more and propose a fix if you find out what's causing the problem.

I updated wait_process_tests.txt with additional tests, redirecting STDOUT and STDERR.
Redirecting both STDOUT and STDERR helps, Wait For Process comes back directly, after the main process has finished, even when the start sub process is still running (see Wait For running Process with SubProcess logging to STDOUT - redirect STDOUT STDERR )
Redirecting only STDOUT does not helps, Wait For Process waits, till also the sub process has finished (see Wait For running Process with SubProcess logging to STDOUT - redirect STDOUT)
So the workaround seams to be, that process, starting other processes , must be  started with a configuration redirecting STDOUT and STDERR.
I will try to debug and understand  what happens in one or two weeks.

Sounds like process output streams would get full which causes the process to hang. You can try emulating how Start Process configures stdout/stderr by default on pure Python by setting stdout=subprocess.PIPE and stderr=subprocess.PIPE.
Process library docs mention that stdout/stderr can get full unless directed to files. Perhaps that note should be made more visible.

For most of the time, diverting to stderr and stdout to file works for me (when I use adb). But at least once a week, there is a problem with Wait For Process which needs manual intervention. But I think I use process library few thousands times in a week so it is not bad ratio. And there usually is also problem with the adb/device which also needs some maintenance.

I think, the problem is not, that the process output streams get full. The problem is, that the streams are still in use by the  sub process.
a) after the sub process has finished , Wait For Process is able to return the complete content written to STDOUT from the process and the sub process.
b) the used example dummy_worker.py creates an output of 21 lines (or 2k), which is not much
I update the samples with a new test

Wait For running Process with SubProcess logging to STDOUT - PIPE sub process streams

It shows, that  starting the sup process using separate stdout and stderr streams also avoid the "endless waiting" situation. But in cases like the ADB we could not influence, how these process start there sub processes.
So a doc note seams to be the best way as a kind of safety tip. It should recommend, starting process with sub process should divert stdout AND stderr to a file

It seems there's nothing simple we could do on Process library itself other than possibly enhancing docs. If you have concrete ideas how to enhance the docs, please submit a new issue and/or pull request.

i met the same issue


Added circular reference detection in DI

Q
A

Is bugfix?
yes

New feature?
yes

Breaks BC?
no

Tests pass?
yes

Merged. Thank you very much!


RFC: Rename @simplewebauthn/typescript-types to something shorter

Describe the issue
"@simplewebauthn/typescript-types" is a mouthful of a package name. I am once again feeling the need to explore shortening this, to probably "@simplewebauthn/types". It's already implied that TypeScript is what the types are for, so including "typescript" in the package name has always been redundant.
If I decide to go through with this then I found out I can make the transition to the new package name easier by using npm deprecate to communicate the new name:
https://docs.npmjs.com/cli/v10/commands/npm-deprecate
I'll chew on this for a few days, and consider any feedback anyone might stop by with.

would make my package.json neat if it was @types/simplewebauthn :)

I went ahead with the package name change with #508. I also ran the following npm command to deprecate @simplewebauthn/typescript-types and point people to simplewebauthn/types instead:
npm deprecate @simplewebauthn/typescript-types "This package has been renamed to @simplewebauthn/types. Please install @simplewebauthn/types instead to ensure you receive future updates."

@simplewebauthn/typescript-types will no longer shows up in searches on npmjs because of this:

The package rename is complete.

Docs site has been updated accordingly here:
https://github.com/MasterKale/SimpleWebAuthn-homepage/pull/43


[WIP] chore(umd): use importHelpers from TS instead of rollupInject

Description:
This follows up my previous PR on this aspect, now it's time to finish the second half in v6.
Related issue (if exists):

#2121

Coverage increased (+0.2%) to 96.947% when pulling 3890a5c2591ffc3c9582c442d55512908b6c3f41 on imcotton:import-tslib-helpers into 37c5c090c04a4bd1bfa31fbfc289c825e8e2a81e on ReactiveX:master.

Now the build & test worked, but changes seem affect the SystemJS user, which requires to have tslib mapped in the config.
I'm not familiar with SystemJS, so if that's the case, shall this be treat as breaking change in next major release (v7)?

@jasonaden or @robwormald can you please have a look at this PR. You're needed for your Rollup and SystemJS expertise, thanks.

After some review and discussion, I think we need to close this. The UMD bundle is designed for standalone use, mostly for prototyping or for developers that don't care that they're including the world anyhow. This would be a breaking change, so we definitely can't do it in 6, and frankly I'm not sure we would do it in 7 either, given what the use case is for the umd bundle.
Thank you so much for the time you've put into this, @imcotton. I just don't think we're going to do this one. Sorry.


Csv::addStreamFilter() - Unable to locate filter bug

Bug Report

Information
Description

Version
9.8.0

PHP version
8.0.19

OS Platform
Alpine Linux 3.14

Summary

Similar issue as described in https://github.com/thephpleague/csv/issues/72

Using the CSV's library Csv::addStreamFilter() gives an error unable to locate filter whereas the fopen() and stream_filter_append() method works fine.
$reader = Reader::createFromPath($tempFile);

// This block below fails
if ($reader->supportsStreamFilterOnRead()) {
    $reader->addStreamFilter('convert.iconv.ISO-8859-1.UTF-8//TRANSLIT');
}

// This block below succeeds
$stream = fopen($tempFile, 'r');
$stream2 = stream_filter_append($stream, 'convert.iconv.ISO-8859-1.UTF-8//TRANSLIT', STREAM_FILTER_READ);

I have tried using this filter with the following modifications:

Using escaped slashes (%2F)
Using a slash (and escaped slash)  instead of the period between the ISO & UTF formats
Removing the //TRANSLIT option
Changing the //TRANSLIT option to //IGNORE

Expected result
No errors
Actual result

unable to locate filter "convert.iconv.ISO-8859-1.UTF-8//TRANSLIT"
same result for all the other variants of the conversion string

@rafaello104 thanks for reporting the issue could you provide a simple reproducible script. The smaller the easiest for me to debug and fix the issue if it exists because I fail to reproduce it myself.
The described error should only occurs if the $path is not internally converted to a stream by the package.

@rafaello104 Was the type of the variable $stream2 from your example a resource? I could only recreate the behavior if I disable the iconv extension. In this case $stream2 was false for me. However, no error is thrown.

closing the issue until further information is given by its author


Update aider

Simple update
https://github.com/Aider-AI/aider/releases
@luxus this includes a litellm update
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[x] 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

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

[ ] Fits CONTRIBUTING.md.

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

it build.. but i got a error on x86_linux when i run aider

litellm
Traceback (most recent call last):
  File "/nix/store/2nmykg5n74y3riv5py0iyvhxyxlc2ayj-python3.11-litellm-1.53.9/bin/.litellm-wrapped", line 6, in <module>
    from litellm import run_server
  File "/nix/store/vv006v2fs7jk6znk47xgzdr9dmyvh6dp-python3.12-litellm-1.53.9/lib/python3.12/site-packages/litellm/__init__.py", line 9, in <module>
    from litellm.llms.custom_httpx.http_handler import AsyncHTTPHandler, HTTPHandler
  File "/nix/store/vv006v2fs7jk6znk47xgzdr9dmyvh6dp-python3.12-litellm-1.53.9/lib/python3.12/site-packages/litellm/llms/custom_httpx/http_handler.py", line 10, in <module>
    from litellm.caching import InMemoryCache
  File "/nix/store/vv006v2fs7jk6znk47xgzdr9dmyvh6dp-python3.12-litellm-1.53.9/lib/python3.12/site-packages/litellm/caching/__init__.py", line 1, in <module>
    from .caching import Cache, LiteLLMCacheType
  File "/nix/store/vv006v2fs7jk6znk47xgzdr9dmyvh6dp-python3.12-litellm-1.53.9/lib/python3.12/site-packages/litellm/caching/caching.py", line 22, in <module>
    from openai.types.audio.transcription_create_params import TranscriptionCreateParams
  File "/nix/store/1kc7r0m32d634pslwasrck02v7aqbpln-python3.12-openai-1.56.1/lib/python3.12/site-packages/openai/__init__.py", line 8, in <module>
    from . import types
  File "/nix/store/1kc7r0m32d634pslwasrck02v7aqbpln-python3.12-openai-1.56.1/lib/python3.12/site-packages/openai/types/__init__.py", line 5, in <module>
    from .batch import Batch as Batch
  File "/nix/store/1kc7r0m32d634pslwasrck02v7aqbpln-python3.12-openai-1.56.1/lib/python3.12/site-packages/openai/types/batch.py", line 7, in <module>
    from .._models import BaseModel
  File "/nix/store/1kc7r0m32d634pslwasrck02v7aqbpln-python3.12-openai-1.56.1/lib/python3.12/site-packages/openai/_models.py", line 24, in <module>
    from pydantic.fields import FieldInfo
  File "/nix/store/shsz3hpyc0zfivd3kslx5zpas1d3gsci-python3.12-pydantic-2.9.2/lib/python3.12/site-packages/pydantic/fields.py", line 17, in <module>
    from pydantic_core import PydanticUndefined
  File "/nix/store/hns2sknhszq1y8105g97y5b6yffvvrfw-python3.12-pydantic-core-2.23.4/lib/python3.12/site-packages/pydantic_core/__init__.py", line 6, in <module>
    from ._pydantic_core import (
ModuleNotFoundError: No module named 'pydantic_core._pydantic_core

hmm it looks like the dependencies of litellm have been updated.
I'm probably going to wait until the next aider update before trying again.

Note that there's also #362466

0.68 is released as well..
hopefully this will fix the issue

nurl https://github.com/BerriAI/litellm v1.54.1 2>/dev/null
fetchFromGitHub {
  owner = "BerriAI";
  repo = "litellm";
  rev = "v1.54.1";
  hash = "sha256-cc7ka0xkPH6kaMhAzw7L9UmJ1YlxFdbNjDh5SDoBONM=";
}

nurl https://github.com/Aider-AI/aider v0.68.0 2>/dev/null
fetchFromGitHub {
  owner = "Aider-AI";
  repo = "aider";
  rev = "v0.68.0";
  hash = "sha256-46qonjLyAF4IycNMybezU3Ci2fvZYjc7qnLi592GOFY=";
}

@luxus I've updated aider but I've left the litellm version as is so as to not cause problems.
(As far as I know no other package is relying on bleeding edge litellm).
Usually aider updates the dependencies every two version releases or so, so I'm inclined to wait for the next aider update for the next litellm update.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 363275

x86_64-linux

:x: 7 packages failed to build:

aider-chat
aider-chat.dist
python311Packages.txtai
python311Packages.txtai.dist
python312Packages.txtai
python312Packages.txtai.dist
vimPlugins.aider-nvim

:white_check_mark: 8 packages built:

open-interpreter (python312Packages.open-interpreter)
open-interpreter.dist (python312Packages.open-interpreter.dist)
python311Packages.litellm
python311Packages.litellm.dist
python311Packages.open-interpreter
python311Packages.open-interpreter.dist
python312Packages.litellm
python312Packages.litellm.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 363275

x86_64-darwin

:fast_forward: 10 packages marked as broken and skipped:

open-interpreter
open-interpreter.dist
python311Packages.open-interpreter
python311Packages.open-interpreter.dist
python311Packages.txtai
python311Packages.txtai.dist
python312Packages.open-interpreter
python312Packages.open-interpreter.dist
python312Packages.txtai
python312Packages.txtai.dist

:white_check_mark: 7 packages built:

aider-chat
aider-chat.dist
python311Packages.litellm
python311Packages.litellm.dist
python312Packages.litellm
python312Packages.litellm.dist
vimPlugins.aider-nvim

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 363275

x86_64-linux

:x: 3 packages failed to build:

aider-chat
aider-chat.dist
vimPlugins.aider-nvim

:white_check_mark: 12 packages built:

open-interpreter (python312Packages.open-interpreter)
open-interpreter.dist (python312Packages.open-interpreter.dist)
python311Packages.litellm
python311Packages.litellm.dist
python311Packages.open-interpreter
python311Packages.open-interpreter.dist
python311Packages.txtai
python311Packages.txtai.dist
python312Packages.litellm
python312Packages.litellm.dist
python312Packages.txtai
python312Packages.txtai.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 363275

x86_64-linux

:white_check_mark: 15 packages built:

aider-chat
aider-chat.dist
open-interpreter (python312Packages.open-interpreter)
open-interpreter.dist (python312Packages.open-interpreter.dist)
python311Packages.litellm
python311Packages.litellm.dist
python311Packages.open-interpreter
python311Packages.open-interpreter.dist
python311Packages.txtai
python311Packages.txtai.dist
python312Packages.litellm
python312Packages.litellm.dist
python312Packages.txtai
python312Packages.txtai.dist
vimPlugins.aider-nvim

it build.. but i got a error on x86_64-linux and aarch64-darwin when i run aider and litellm
⋈┈◎ aider --version
Traceback (most recent call last):
  File "/nix/store/s63jvz4x2kxhsa868hjhy81pgwqalfyl-aider-chat-0.67.0/bin/.aider-wrapped", line 6, in <module>
    from aider.main import main
  File "/nix/store/s63jvz4x2kxhsa868hjhy81pgwqalfyl-aider-chat-0.67.0/lib/python3.11/site-packages/aider/main.py", line 17, in <module>
    from aider import __version__, models, urls, utils
  File "/nix/store/s63jvz4x2kxhsa868hjhy81pgwqalfyl-aider-chat-0.67.0/lib/python3.11/site-packages/aider/models.py", line 14, in <module>
    from PIL import Image
  File "/nix/store/gpa376dl0r8pwjjbfrj58xrwymq8nnli-python3.12-pillow-11.0.0/lib/python3.12/site-packages/PIL/Image.py", line 97, in <module>
    from . import _imaging as core
ImportError: cannot import name '_imaging' from 'PIL' (/nix/store/gpa376dl0r8pwjjbfrj58xrwymq8nnli-python3.12-pillow-11.0.0/lib/python3.12/site-packages/PIL/__init__.py)

Was this issue solved?

I made an update to another version and onky tested the build on linux, did yiu experience this error ?

I made an update to another version and onky tested the build on linux, did yiu experience this error ?

Not me but someone opened an issue complaining about it before this PR got merged, so I was wondering if it can be closed now.

This has to be tested again im afraid

sorry i cannot access my linux machine right now, i'm in holiday in japan


Muxxee

removed addr

addeding to master

addeding to master

GO

GO

If you provide me the changes you would like to have applied, I can update all the scripts

If you provide me the changes you would like to have applied, I can update all the scripts


rds.resourceProxy Panic

Panic in rds.resourceProxy reported by a customer. Will upload full log separately.
Top level error
         [stdout]  2024-04-17 14:09:45 INFO     panic: interface conversion: interface {} is nil, not map[string]interface {}
         [stdout]  2024-04-17 14:09:45 INFO
         [stdout]  2024-04-17 14:09:45 INFO     goroutine 270 [running]:
         [stdout]  2024-04-17 14:09:45 INFO
         [stdout]  2024-04-17 14:09:45 INFO     github.com/hashicorp/terraform-provider-aws/internal/service/rds.resourceProxy.SimpleSchemaSetFunc.func1({0x0?, 0x0?})

@zbuchheit do you have an example program we can use to reproduce this issue? Thanks!

Also, if you happen to know what the previous working version and the current working version are that could help us narrow down the issue.

Ok, here is the repro
import * as aws from "@pulumi/aws";

const proxyRole = new aws.iam.Role(
  "role",
  {
    assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal(
      aws.iam.Principals.RdsPrincipal,
    ),
    managedPolicyArns: [],
  },
  {},
);

const vpc = new aws.ec2.Vpc("vpc", {
  cidrBlock: "<IP_ADDRESS>/16",
});

const subnet = new aws.ec2.Subnet("subnet", {
  vpcId: vpc.id,
  cidrBlock: "<IP_ADDRESS>/24",
  availabilityZone: "us-east-2a",
});

const anotherSubnet = new aws.ec2.Subnet("another-subnet", {
  vpcId: vpc.id,
  cidrBlock: "<IP_ADDRESS>/24",
  availabilityZone: "us-east-2b",
});

const example = new aws.rds.Proxy("example", {
  name: "example",
  debugLogging: false,
  engineFamily: "MYSQL",
  idleClientTimeout: 1800,
  requireTls: true,
  roleArn: proxyRole.arn,
  vpcSubnetIds: [subnet.id, anotherSubnet.id],
  auths: [{}],
  tags: {
    Name: "example",
    Key: "value",
  },
});

The issue is caused by a change in upstream where Proxy.auth was changed from TypeList to TypeSet.

We have filed https://github.com/hashicorp/terraform-provider-aws/issues/36965 as this reproduces upstream. Our first suspicion was an issue in the bridge, but even with the PlanResourceChange the issue reproduces. I poked in the debugger and found this:
In SimpleDiff(c ResourceConfig)
(dlv) print c.Config["auth"]
interface {}([]interface {}) [
        map[string]interface {} [],
]

(dlv) print c.Raw["auth"]
interface {}([]interface {}) [
        map[string]interface {} [],
]

(dlv) print c.CtyValue
github.com/hashicorp/go-cty/cty.Value {
        ty: github.com/hashicorp/go-cty/cty.Type {
                typeImpl: github.com/hashicorp/go-cty/cty.typeImpl nil,},
        v: interface {} nil,}

When we enter diffSet we get this:
*github.com/hashicorp/terraform-plugin-sdk/v2/terraform.InstanceDiff {
        mu: sync.Mutex {state: 0, sema: 0},
        Attributes: map[string]*github.com/hashicorp/terraform-plugin-sdk/v2/terraform.ResourceAttrDiff [],
        Destroy: false,
        DestroyDeposed: false,
        DestroyTainted: false,
        RawConfig: github.com/hashicorp/go-cty/cty.Value {
                ty: (*"github.com/hashicorp/go-cty/cty.Type")(0xc002c8ce50),
                v: interface {} nil,},
        RawState: github.com/hashicorp/go-cty/cty.Value {
                ty: (*"github.com/hashicorp/go-cty/cty.Type")(0xc002c8ce70),
                v: interface {} nil,},
        RawPlan: github.com/hashicorp/go-cty/cty.Value {
                ty: (*"github.com/hashicorp/go-cty/cty.Type")(0xc002c8ce90),
                v: interface {} nil,},
        Meta: map[string]interface {} nil,}

So when passing an empty object to a single-element set,  this hash customizer doesn't work very well:
sdkv2.SimpleSchemaSetFunc("auth_scheme", "description", "iam_auth", "secret_arn", "username")
The various diff reader code in TFSDK is rather difficult for me to follow but I suspect right now that there might be an issue there in the reader code, not necessarily the set customizer itself. Alas.

If we could back out the upstream change via a patch that would be ideal, so customers are not affected until such time as the root cause is fixed.

OK there is another Pulumi-level issue here. Check turns an unknown property into a list of a single-known element.
{
  "method": "/pulumirpc.ResourceProvider/Check",
  "request": {
    "urn": "urn:pulumi:dev::golevel::aws:rds/proxy:Proxy::proxy",
    "olds": {},
    "news": {
      "auths": "04da6b54-80e4-46f7-96ec-b56ff0331ba9",
      "engineFamily": "MYSQL",
      "roleArn": "04da6b54-80e4-46f7-96ec-b56ff0331ba9",
      "vpcSubnetIds": [
        "04da6b54-80e4-46f7-96ec-b56ff0331ba9",
        "04da6b54-80e4-46f7-96ec-b56ff0331ba9"
      ]
    },
    "randomSeed": "J0Aw7NUBOt6y1jrDNci17siIDTE0toDNdhPxKB6L5w8="
  },
  "response": {
    "inputs": {
      "__defaults": [
        "name"
      ],
      "auths": [
        {}
      ],
      "engineFamily": "MYSQL",
      "name": "proxy-e01ed94",
      "roleArn": "04da6b54-80e4-46f7-96ec-b56ff0331ba9",
      "vpcSubnetIds": [
        "04da6b54-80e4-46f7-96ec-b56ff0331ba9",
        "04da6b54-80e4-46f7-96ec-b56ff0331ba9"
      ]
    }
  }
}

Go program:
package main

import (
	"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ec2"
	"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/iam"
	"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/rds"
	"github.com/pulumi/pulumi-aws/sdk/v6/go/aws/secretsmanager"
	"github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
	pulumi.Run(func(ctx *pulumi.Context) error {

		assumeRolePolicy, _ := iam.GetPolicyDocument(ctx, &iam.GetPolicyDocumentArgs{
			Statements: []iam.GetPolicyDocumentStatement{
				{
					Actions:    []string{"sts:AssumeRole"},
					Principals: []iam.GetPolicyDocumentStatementPrincipal{{Type: "Service", Identifiers: []string{"lambda.amazonaws.com"}}},
				},
			},
		})
		role, _ := iam.NewRole(ctx, "myrole", &iam.RoleArgs{
			AssumeRolePolicy: pulumi.String(assumeRolePolicy.Json),
		})

		vpc, _ := ec2.NewVpc(ctx, "Vpc", &ec2.VpcArgs{
			CidrBlock: pulumi.String("<IP_ADDRESS>/16"),
		})
		subnet, _ := ec2.NewSubnet(ctx, "subnet", &ec2.SubnetArgs{
			VpcId:            vpc.ID(),
			CidrBlock:        pulumi.String("<IP_ADDRESS>/24"),
			AvailabilityZone: pulumi.String("us-east-2a"),
		})
		anotherSubnet, _ := ec2.NewSubnet(ctx, "another-subnet", &ec2.SubnetArgs{
			VpcId:            vpc.ID(),
			CidrBlock:        pulumi.String("<IP_ADDRESS>/24"),
			AvailabilityZone: pulumi.String("us-east-1a"),
		})

		secret, err := secretsmanager.NewSecret(ctx, "secret", &secretsmanager.SecretArgs{})
		if err != nil {
			panic(err)
		}

		if 1+2 == 3 {
			rds.NewProxy(ctx, "proxy", &rds.ProxyArgs{
				VpcSubnetIds: pulumi.StringArray{
					subnet.ID(),
					anotherSubnet.ID(),
				},
				Auths: secret.Arn.ApplyT(func(arn string) []rds.ProxyAuth {
					return []rds.ProxyAuth{
						{
							AuthScheme: pulumi.StringRef("SECRETS"),
							IamAuth:    pulumi.StringRef("DISABLED"),
							SecretArn:  &arn,
						},
					}
				}).(rds.ProxyAuthArrayInput),
				RoleArn:      role.Arn,
				EngineFamily: pulumi.String("MYSQL"),
			})
		}
		return nil
	})
}

https://github.com/pulumi/pulumi-terraform-bridge/pull/1881


LICENSE.txt not supported

This is a neat project!
It would be nice if this script could support LICENSE.txt files in addition to plain LICENSE files.

You can change here to make it work. Also, please see #2. PR welcomed.


Validate on TF 0.13 for PowerVM and PowerVS

Use the latest terraform version 0.13.
Handle ignition provider plugin (not part of TF registry) and use v2.

Fixes #48
Signed-off-by: Yussuf Shaikh<EMAIL_ADDRESS>

Keywords which can automatically close issues and at(@) mentions are not allowed in commit messages.
The list of commits with invalid commit messages:

288fbb4 Validate on TF 0.13 for PowerVM and PowerVS

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.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: yussufsh
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

config/jobs/ocp-automation/OWNERS [yussufsh]

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

/cc @mkumatag

/lgtm

@yussufsh: Updated the job-config configmap in namespace prow at cluster default using the following files:

key ocp4-upi-powervm-presubmit.yaml using file config/jobs/ocp-automation/ocp4-upi-powervm/ocp4-upi-powervm-presubmit.yaml
key ocp4-upi-powervs-presubmit.yaml using file config/jobs/ocp-automation/ocp4-upi-powervs/ocp4-upi-powervs-presubmit.yaml

In response to this:

Use the latest terraform version 0.13.
Handle ignition provider plugin (not part of TF registry) and use v2.

Fixes #48
Signed-off-by: Yussuf Shaikh<EMAIL_ADDRESS>
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.


API is consuming ~4GB memory, why that much?

Since our analytics server is quite small, this could become an issue since ETL runs on the same server. There's no reason API should be using that much memory. How is that possible?

Hmm... must be some kind of memory leak after serving requests.

It's rather DuckDB keeping data in cache (I've checked the app and there don't seem to be leaks). By default it uses 13gb max memory, so I reduced it down to 2gb.


Can't use default export for pages

Description
The docs say export default can also be used, but in fact it doesn't support it and throw an error instead.
Error Stack
Server running at http://localhost:3000
Error<EMAIL_ADDRESS>Usage] The `export default` of /pages/index/index.page.tsx should be an object.
    at /workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:59:41
    at Array.forEach (<anonymous>)
    at getExportValues (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:51:10)
    at /workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:9:30
    at Array.forEach (<anonymous>)
    at getExports (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:8:15)
    at loadPageFilesServerSide (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/analyzePageServerSide/loadPageFilesServerSide.js:9:78)
    at async Promise.all (index 0)
    at async loadPageFilesServer (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:364:69)
    at async renderPageContext (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:65:23)
    at async renderPage (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:151:16)
    at async /workspaces/.github/vite-ssr-project/server/index.ts:33:25
Error<EMAIL_ADDRESS>Usage] The `export default` of /pages/index/index.page.tsx should be an object.
    at /workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:59:41
    at Array.forEach (<anonymous>)
    at getExportValues (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:51:10)
    at /workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:9:30
    at Array.forEach (<anonymous>)
    at getExports (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/getExports.js:8:15)
    at loadPageFilesServerSide (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/shared/getPageFiles/analyzePageServerSide/loadPageFilesServerSide.js:9:78)
    at async Promise.all (index 0)
    at async loadPageFilesServer (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:364:69)
    at async renderPageContext (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:65:23)
    at async renderPage (/workspaces/.github/vite-ssr-project/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:151:16)
    at async /workspaces/.github/vite-ssr-project/server/index.ts:33:25

Docs updated. Thanks.