Containers can get orphaned and stuck when running in rootless mode

When running rootless mode if you kill the agent the old containers will stick around but they are in an orphaned network namespace.
This is a tracking issue for https://github.com/rancher/k3s/pull/1343

This is a tracking issue for #1343

Just to confirm, you mean that #1343 resolves this issue?

Unable to install k3s with --rootless flag. k3s does not start.
Env and Steps followed.
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"

sudo apt-get install uidmap
Reading package lists... Done
Building dependency tree
Reading state information... Done
uidmap is already the newest version (1:4.5-1ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

ubuntu@ip-172-31-9-159:~$ cat /etc/subuid
lxd:100000:65536
root:100000:65536
ubuntu:165536:65536

ubuntu@ip-172-31-9-159:~$ cat /etc/subgid
lxd:100000:65536
root:100000:65536
ubuntu:165536:65536

export KUBECONFIG=~/.kube/k3s.yaml

./k3s server --rootless >k3s.log 2>&1 &
[1]+  Exit 1                  ./k3s server --rootless > k3s.log 2>&1

cat k3s.log
time="2020-04-24T19:57:23.087549729Z" level=fatal msg="failed to setup network &{binary:slirp4netns mtu:65520 ipnet:0xc0008957d0 disableHostLoopback:true apiSocketPath: enableSandbox:false enableSeccomp:false}: waiting for ready fd (/home/ubuntu/.rancher/k3s/data/1cd84d78e73d1835ec46d86660cd74dd4d52357ced9b4050a211168c4b1da90a/bin/slirp4netns --mtu 65520 -r 3 --disable-host-loopback --cidr <IP_ADDRESS>/16 1986 tap0): slirp4netns failed"
time="2020-04-24T19:57:23.089651925Z" level=fatal msg="child diedparsing message from fd 3: EOF"

slirp4netns not installed?

@AkihiroSuda Thanks for quick response. I was not able to install slirp4netns.
sudo apt install slirp4netns
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package slirp4netns

As per the ReadMe https://github.com/rootless-containers/slirp4netns, it should be Ubuntu19.04 or later.
Will test on Ubuntu 19.04.

Binary is here
https://github.com/rootless-containers/slirp4netns/releases/tag/v1.0.1

@AkihiroSuda slirp4netns  is already installed as part of k3s as seen in the error log above. Ubuntu version 20.04 as well seems to have the same error.

I can repro the issue. Seems a regression happened recently.

Does reverting https://github.com/rancher/k3s/pull/1343 solve the issue?
(I'm trying to confirm but I can't compile k3s)

Let's track the slirp4netns issue in https://github.com/rancher/k3s/issues/1709

@ShylajaDevadiga lowered rank in zube while waiting for #1709 fix.

The current master (c8282f4939ea8e36b5411936ed174787eaefaccc) seems working well for rootless

@AkihiroSuda @cjellick you feel comfortable closing this out?

yes


App takes long to end after work is done

I created this custom script based on the samples:
const {detectClones} = require("jscpd");
const {MemoryStore} = require("@jscpd/core");

const BASE_APPS = [
//several source folders here
];
const DEFAULT_OPTIONS = {
    path: BASE_APPS,
    silent: true,
    minLines: 15,
    minTokens: 60,
    output: './master-report-js',
    reporters: ['json'],
    format: 'javascript,css,less,markup'
};

(async () => {
    const store = new MemoryStore();
    await detectClones(DEFAULT_OPTIONS, store);
})();

For me it takes about 6 seconds to output:

JSON report saved to master-report-js\0\jscpd-report.json
Detection time:: 5916.966ms

After that it takes about 20 seconds more... and it is unclear to me what it is doing. It seems to happen after the await returns, because adding console.logs in a .then() clause also makes them also print out directly after the detection time, but then it takes 20 seconds more.
My quick and dirty solution is to add this to the detectClones... but it feels really horrible
await detectClones(DEFAULT_OPTIONS, store).then(()=>process.exit(0));

Could it be that the detectClones creates lots of events / async calls that need to be cleaned up?
The following turned out to be caused by a mistake I made in the file paths with the above program,so please ignore the remark below.
Running the same command using the jscpd main app takes significantly longer:
npx jscpd --output ./master-report-double/0 --format javascript,css,less,markup --min-tokens 60 --min-lines 15 --ignore *.stories.js --silent --reporters json [...lots of source dirs]
JSON report saved to master-report-double\0\jscpd-report.json
Duplications detection: Found 86 exact clones with 3507(4.59%) duplicated lines in 596 (4 formats) files.
Detection time:: 261734.781ms

Hm... looks interesting, will investigate

Small update. The extremely large detection time in the last command was due to a typo in one of the file paths... so I will cross out the last part.
But the remark in the rest of my message remains: I don't understand why after the end of my "program" it takes so long for the application to return.
After a jscpd test that has a detection time of 271500 ms (4.5 min), it takes an additional 2 minutes until it is completed
A run with the jscpd command line takes about the same time (287780ms) but does not have the additional 2 minutes

I created a simple way to reproduce it. It checks out moment.js and tries to find duplicates there.
jscpd-411.zip
const {detectClones} = require("jscpd");

(async () => {
    console.time('Total time');
    await detectClones({path:['moment/src'], silent: true, output:'jscpd-output'});
    console.timeEnd('Total time');
	//This is where the ugly hack would come in
	//process.exit(0);
})();

#!/bin/sh
if [ ! -d "/home/node/moment" ]
then
	git clone https://github.com/moment/moment.git
fi
npm install
echo "Starting execution of main script"
START_TIME=$(date +%s)
node main.js
END_TIME=$(date +%s)
echo "Execution took $(($END_TIME - $START_TIME)) seconds"

It gives this output (when run with node 15)
Cloning into 'moment'...
remote: Enumerating objects: 28136, done.
remote: Total 28136 (delta 0), reused 0 (delta 0), pack-reused 28136
Receiving objects: 100% (28136/28136), 19.51 MiB | 5.51 MiB/s, done.
Resolving deltas: 100% (19477/19477), done.
Checking out files: 100% (786/786), done.
npm WARN deprecated<EMAIL_ADDRESS>core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.

added 130 packages, and audited 130 packages in 16s

10 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
npm notice
npm notice New patch version of npm available! 7.0.8 -> 7.0.13
npm notice Changelog: https://github.com/npm/cli/releases/tag/v7.0.13
npm notice Run npm install -g<EMAIL_ADDRESS>to update!
npm notice
Starting execution of main script
Found 1302 clones.
Detection time:: 24.333s
Total time: 26.398s
Execution took 102 seconds

thank you!

same issue

same issue, how to fix~

any updates?

when you changed memory store to sth like leveldb-store, the problem will be fixed.
the key problem is about using promise in recursive maybe causing memory leak.
I tried several ways to fix that.

you can just changed the file rabin-karp.ts,  changes the loop function.

.finally(() => {
    if (!iteration.done) {
      if (clone) {
        clone = RabinKarp.enlargeClone(
          clone,
          iteration.value as IMapFrame,
          mapFrameInStore
        );
      }
      // loop
      setImmediate(loop);
    } else {
      resolve(clones);
    }
  });

i just change loop to setImmediate(loop), in that way, the event loop will not create a new task, but just execute the loop as a micro task immediate.  but it will cause more time and memory to handle.
2. I just changed store to plain function， without using promise。
for same test code, first way causing 20s, but second causing 9s.

@sonacy thank you for your investigation, will try to fix it, or can merge you your PR

I also run into this issue. Detection time for me is around 4s, but the app doesn't finish for another 12s. I investigated it and it's related to nodejs tracking rejected promise to verify that the rejection was handled.
The root cause is the store interface - when iteration.value.id is in the store, the get method is expected to resolve a promise with a value, otherwise reject it. It creates a lot of rejected promises, which need to be validated. As a fix, we could change the interface of the store to maybe something like:
{found: boolean, value?:T }


add a markdown file documenting the public API

Codecov Report

Merging #157 (290b12e) into main (070ac07) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #157   +/-   ##
=======================================
  Coverage   68.34%   68.34%
=======================================
  Files          36       36
  Lines        1744     1744
=======================================
  Hits         1192     1192
  Misses        355      355
  Partials      197      197

Continue to review full report at Codecov.

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


feat(Nylas N1) : add Nylas N1

Add Nylas N1 on web site

As much as I'd love to accept this, the icon would be duplicated which we don't want. We are in the process of powering the site via the READMEs, so if you can actually add the instructions there (See the Alfred theme), it would be appreciated.
Please change this PR to only include the screenshot. Thanks!

allright! Understood!

🍺 it's ok!


Add a example project?

But if we add a transparent section to our modal controller then we don't get the "slide up to go fullscreen" option right?


Implement Login Api

In this pull request I:

[x] Developed API endpoints for user authentication and login functionality.

Hi @Kidd254
Status: Approved ✔
Excellent job on making the changes requested by the previous code reviewer. Keep it up 👏
Your project is complete! There is nothing else to say other than... it's time to merge it 💪
Congratulations! 🎉
congratulations
To highlight 🍾
Fixed error and application is running as expected. ✔
[Optional] suggestions:
Please check my inline comments.
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


atmos terraform commands should have a --skip-init flag

Describe the Feature
A --skip-init flag would be great for situations where you know for sure that the terraform config hasn't changed. This is the case for the series of spacelit-* scripts that are executed as before_* hooks in Spacelift.
Expected Behavior
When using --skip-init, any atmos terraform * will skip over running terraform init.
Use Case
This will decrease the amount of time it takes for the atmos terraform wrapper to complete the subcommand.
Describe Ideal Solution
It saves us time?
Alternatives Considered
Haven't thought of any.
Additional Context
N / A

Seems reasonable

Closed via #193


View results as they finish

merge analysis_waiting and analysis_results pages so that results can be viewed as they are ready, hot off the press!

Did MOI take care of this or do we still need this set up in conjunction with MOI?

Superseded by the current analysis pipeline AKA doesn't apply anymore.


fix http tests

Hopefully fixes the tests in generic_io that recently started failing.

Coverage remained the same at 93.753% when pulling cb0e46883a9f44aceb144bd17268d61de0a67469 on nden:fix-url-tests into d3c89da4eb1208c0edce28a923a9cb5631c97a09 on spacetelescope:master.


Don't make unnecessary calls to updateStatus in React Native

What:
Don't call the updateStatus method at all in RN

Why:
No reason why we would want that (that I can tell), also less code to execute

How:
Moved the RN if statement to where we call the updateState method instead of having the check inside that function.

Checklist:

[ ] Documentation N/A
[ ] Tests N/A
[x] Ready to be merged

[ ] Added myself to contributors table N/A

:tada: This PR is included in version 2.0.17 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Feat add crossconnect

Description of your changes
This PR adds: Crossconnect as crd
Checklist

I have:

[x] Add PR name as appropriate (e.g. feat/fix/doc/test/refactor)
[x] Run make reviewable and make crds.clean to ensure the PR is ready for review
[ ] Add or update tests (if applicable) Nope just copied everything from datacenter
[x] Add or update Documentation using make docs.update (if applicable)
[x] Update docs/CHANGELOG.md file (label: upcoming release)
[ ] Check Sonar Cloud Scan
[ ] Update Github or Jira Issue

thanks for the CR, I think it needs to be added to integration tests. WIll try to create some pccs to see exactly how it works.

... I currently have a ticket open for getting Information how Pccs work with k8s. Internal: #:207140121

One more small thing, in internal/controller/ionoscloud.go pcc.Setup needs to be called like for the other resources. Thanks!

@cristiGuranIonos thanks for looking at it. :)
There where some more compiling Problems today... strange i executed make reviewable after the renaming stuff.

@cristiGuranIonos thanks for looking at it. :)
There where some more compiling Problems today... strange i executed make reviewable after the renaming stuff.

From what I saw the lint passed. Sometimes the code generation doesn't work as good.

One small thing also, this is technically a small breaking change for lans so have to discuss about how we will release

Would be great to have this sone. :)
I would like to use this but when it takes to long i can not convince management to wait.


gym_anytrading : could not broadcast input array from shape (62,) into shape (20,3)  Please help!!

source code:
import pandas as pd
df = pd.read_csv('datasets/STOCKS_GOOGL.csv', parse_dates=True, index_col='Date')
from easydict import EasyDict
from dizoo.gym_anytrading.envs import StocksEnv
pq=EasyDict({"env_id": 'stocks-v0', "eps_length": 300, "train_range": None, "test_range": None,
"window_size": 20,"df": df})
env = StocksEnv(pq)
from stable_baselines3 import PPO
model = PPO('MlpPolicy', env, verbose=1)
model.learn(total_timesteps=1000)
Run Error
Traceback (most recent call last):
File "C:\Program Files\JetBrains\PyCharm Community Edition 2024.1\plugins\python-ce\helpers\pydev\pydevd.py", line 1535, in _exec
pydev_imports.execfile(file, globals, locals)  # execute the script
File "C:\Program Files\JetBrains\PyCharm Community Edition 2024.1\plugins\python-ce\helpers\pydev_pydev_imps_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "D:\per\AI\chinaA\dingenvtest.py", line 17, in
model.learn(total_timesteps=1000)
File "C:\ProgramData\miniconda3\envs\mypy39\lib\site-packages\stable_baselines3\ppo\ppo.py", line 315, in learn
return super().learn(
File "C:\ProgramData\miniconda3\envs\mypy39\lib\site-packages\stable_baselines3\common\on_policy_algorithm.py", line 287, in learn
total_timesteps, callback = self._setup_learn(
File "C:\ProgramData\miniconda3\envs\mypy39\lib\site-packages\stable_baselines3\common\base_class.py", line 423, in _setup_learn
self._last_obs = self.env.reset()  # type: ignore[assignment]
File "C:\ProgramData\miniconda3\envs\mypy39\lib\site-packages\stable_baselines3\common\vec_env\dummy_vec_env.py", line 78, in reset
self._save_obs(env_idx, obs)
File "C:\ProgramData\miniconda3\envs\mypy39\lib\site-packages\stable_baselines3\common\vec_env\dummy_vec_env.py", line 108, in _save_obs
self.buf_obs[key][env_idx] = obs
ValueError: could not broadcast input array from shape (62,) into shape (20,3)
Off topic suggestions
gym_anytrading, Please add this tutorial!!!

Have you modified the dizoo.gym_anytrading.envs.StocksEnv? The 'pq' needs to pass the parameter 'stocks_data_filename'='STOCKS_GOOGL' instead of "df"
There is a tutorial for gym-anytrading.

Yes, I made the changes to dizoo. gym anytrading. envs The content of the data section obtained by StocksEnv has not been modified in other locations, but even if the original 'stocks_data_file name'='STORKS_GOOGL' is used to pass parameters, this problem still occurs.
And thank you for providing the tutorial link, thank you very much!!

Sorry I can't reproduce your error because I'm not sure about your development environment.
And our repo has not yet tried to adapt gym-anytrading to stable-baseline.


[Enhancement] Support Java x64 version 11

Are there any future development to make this tool support Java x64 version 11 and higher? Thank you in advance

Can you specify the issues you're having using such JVM release?

Just for enhancement, because the latest installable version of Burp Suite (2020.1) comes bundled with OpenJDK Version 12.0.2.
As for spesific issues  that  I found is the same as  #95, maybe it's related?
Best Regards and Thank you in advance! 🙏

We've sponsored a two days bug squash, and finally fixed the incompatibility with recent versions of Java. For recent JVMs, you have to use the burp-rest-api.sh script to start the extension.

Thank you very much @ikkisoft and team!


Failed to compile Linux armv7 vvdec binary for errors of new release vvdec 2.3.0

Hi!
I have an issue about cross-compiling Linux armv7 vvdec binary on my Linux x86_64 machine.
The commit of https://github.com/fraunhoferhhi/vvdec/commit/edd47ab839a73e47d672b1f1ad071725eb955f93 doesn't work and it fails to compile armv7 vvdec binary for Linux, but last commit of https://github.com/fraunhoferhhi/vvdec/commit/85ed28d022f2aaca0e7721dca5f3d6b1b7f63c66 was successfully compiled of Linux arm64 binary.
I'm running on Ubuntu 22.04.3 LTS Server and also GCC 11.4.0 with g++.
Here is the log that may be helpful to you and used CMake Toolchain of ARMv7.
toolchain_armv7.cmake:
# name of the target operating system
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_PROCESSOR armv7l)

set( GNU_MACHINE "arm-linux-gnueabihf" )

# which compilers to use for C and C++
SET(CMAKE_C_COMPILER   /usr/bin/${GNU_MACHINE}-gcc)
SET(CMAKE_CXX_COMPILER /usr/bin/${GNU_MACHINE}-g++)

# Where is the target environment
SET(CMAKE_FIND_ROOT_PATH  /usr/bin/${GNU_MACHINE})

# Search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# For libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

CMake output logs:
martineesmaa@martineesmaa:~/vvdec/build$ cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE="../cmake/toolchains/toolchain_armv7.cmake" -DCMAKE_EXE_LINKER_FLAGS="-static" .. && cmake --build . -j 8
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/arm-linux-gnueabihf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/arm-linux-gnueabihf-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_MODULE_PATH: updating module path to: /home/martineesmaa/vvdec/cmake/modules
-- Performing Test SUPPORTED_Werror_unused_command_line_argument
-- Performing Test SUPPORTED_Werror_unused_command_line_argument - Failed
-- Performing Test SUPPORTED_msse4_1
-- Performing Test SUPPORTED_msse4_1 - Failed
-- Performing Test SUPPORTED_msse2
-- Performing Test SUPPORTED_msse2 - Failed
-- Performing Test SUPPORTED_mavx
-- Performing Test SUPPORTED_mavx - Failed
-- Performing Test HAVE_INTRIN_mm_storeu_si16
-- Performing Test HAVE_INTRIN_mm_storeu_si16 - Success
-- Performing Test HAVE_INTRIN_mm_storeu_si32
-- Performing Test HAVE_INTRIN_mm_storeu_si32 - Success
-- Performing Test HAVE_INTRIN_mm_storeu_si64
-- Performing Test HAVE_INTRIN_mm_storeu_si64 - Success
-- Performing Test HAVE_INTRIN_mm_loadu_si32
-- Performing Test HAVE_INTRIN_mm_loadu_si32 - Success
-- Performing Test HAVE_INTRIN_mm_loadu_si64
-- Performing Test HAVE_INTRIN_mm_loadu_si64 - Success
-- Performing Test HAVE_INTRIN_mm256_zeroupper
-- Performing Test HAVE_INTRIN_mm256_zeroupper - Failed
-- Performing Test HAVE_INTRIN_mm256_loadu2_m128i
-- Performing Test HAVE_INTRIN_mm256_loadu2_m128i - Success
-- x86 SIMD intrinsics enabled (using SIMDE for non-x86 targets)
-- ARM SIMD intrinsics enabled
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Performing Test SUPPORTED_mxsave
-- Performing Test SUPPORTED_mxsave - Failed
-- Performing Test SUPPORTED_mavx2
-- Performing Test SUPPORTED_mavx2 - Failed
-- Some bitstream files are missing.
--   If you want to run tests, reconfigure with -DVVDEC_ENABLE_BITSTREAM_DOWNLOAD=ON
--   (or using top level Makefile: make test enable-bitstream-download=1)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/martineesmaa/vvdec/build
[  2%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_x86_simd.dir/__/CommonLib/x86/sse41/Buffer_sse41.cpp.o
[  2%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_x86_simd.dir/__/CommonLib/x86/sse41/AdaptiveLoopFilter_sse41.cpp.o
[  3%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_x86_simd.dir/__/CommonLib/x86/sse41/InterPred_sse41.cpp.o
[  4%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_x86_simd.dir/__/CommonLib/x86/sse41/IntraPred_sse41.cpp.o
[  6%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_x86_simd.dir/__/CommonLib/x86/sse41/LoopFilter_sse41.cpp.o
[  7%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_x86_simd.dir/__/CommonLib/x86/sse41/Picture_sse41.cpp.o
[  8%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_x86_simd.dir/__/CommonLib/x86/sse41/InterpolationFilter_sse41.cpp.o
[  9%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec_arm_simd.dir/__/CommonLib/arm/neon/Buffer_neon.cpp.o
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h: In function ‘vvdec::applyLut_SIMD<(vvdec::arm_simd::ARM_VEXT)1>(short*, int, int, int, short const*)void’:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:13526:1: error: inlining failed in call to ‘always_inline’ ‘vst4q_s16’: target specific option mismatch
13526 | vst4q_s16 (int16_t * __a, int16x8x4_t __b)
      | ^~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:217:18: note: called from here
  217 |         vst4q_s16( &ptr[ x ], xtmp1 );
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:13526:1: error: inlining failed in call to ‘always_inline’ ‘vst4q_s16’: target specific option mismatch
13526 | vst4q_s16 (int16_t * __a, int16x8x4_t __b)
      | ^~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:218:18: note: called from here
  218 |         vst4q_s16( &ptr[ x + 1 * ptrStride ], xtmp2 );
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:13526:1: error: inlining failed in call to ‘always_inline’ ‘vst4q_s16’: target specific option mismatch
13526 | vst4q_s16 (int16_t * __a, int16x8x4_t __b)
      | ^~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:219:18: note: called from here
  219 |         vst4q_s16( &ptr[ x + 2 * ptrStride ], xtmp3 );
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:13526:1: error: inlining failed in call to ‘always_inline’ ‘vst4q_s16’: target specific option mismatch
13526 | vst4q_s16 (int16_t * __a, int16x8x4_t __b)
      | ^~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:220:18: note: called from here
  220 |         vst4q_s16( &ptr[ x + 3 * ptrStride ], xtmp4 );
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:6441:1: error: inlining failed in call to ‘always_inline’ ‘vsetq_lane_s16’: target specific option mismatch
 6441 | vsetq_lane_s16 (int16_t __a, int16x8_t __b, const int __c)
      | ^~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:238:40: note: called from here
  238 |         xtmp1.val[ 0 ] = vsetq_lane_s16( lut[ ptr[ x + 0 ] ], xtmp1.val[ 0 ], 0 );
      |                          ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:6441:1: error: inlining failed in call to ‘always_inline’ ‘vsetq_lane_s16’: target specific option mismatch
 6441 | vsetq_lane_s16 (int16_t __a, int16x8_t __b, const int __c)
      | ^~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:239:40: note: called from here
  239 |         xtmp1.val[ 1 ] = vsetq_lane_s16( lut[ ptr[ x + 1 ] ], xtmp1.val[ 1 ], 0 );
      |                          ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:6441:1: error: inlining failed in call to ‘always_inline’ ‘vsetq_lane_s16’: target specific option mismatch
 6441 | vsetq_lane_s16 (int16_t __a, int16x8_t __b, const int __c)
      | ^~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:240:40: note: called from here
  240 |         xtmp1.val[ 0 ] = vsetq_lane_s16( lut[ ptr[ x + 2 ] ], xtmp1.val[ 0 ], 1 );
      |                          ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:6441:1: error: inlining failed in call to ‘always_inline’ ‘vsetq_lane_s16’: target specific option mismatch
 6441 | vsetq_lane_s16 (int16_t __a, int16x8_t __b, const int __c)
      | ^~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:241:40: note: called from here
  241 |         xtmp1.val[ 1 ] = vsetq_lane_s16( lut[ ptr[ x + 3 ] ], xtmp1.val[ 1 ], 1 );
      |                          ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../CommonDefARM.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/../BufferARM.h:53,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/arm/neon/Buffer_neon.cpp:43:
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:6441:1: error: inlining failed in call to ‘always_inline’ ‘vsetq_lane_s16’: target specific option mismatch
 6441 | vsetq_lane_s16 (int16_t __a, int16x8_t __b, const int __c)
      | ^~~~~~~~~~~~~~

CMake output logs (disabled of x86 and ARM SIMD):
martineesmaa@martineesmaa:~/vvdec/build$ cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE="../cmake/toolchains/toolchain_armv7.cmake" -DCMAKE_EXE_LINKER_FLAGS="-static" -DVVDEC_ENABLE_X86_SIMD=OFF -DVVDEC_ENABLE_ARM_SIMD=OFF .. && cmake --build . -j 8
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/arm-linux-gnueabihf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/arm-linux-gnueabihf-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_MODULE_PATH: updating module path to: /home/martineesmaa/vvdec/cmake/modules
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Some bitstream files are missing.
--   If you want to run tests, reconfigure with -DVVDEC_ENABLE_BITSTREAM_DOWNLOAD=ON
--   (or using top level Makefile: make test enable-bitstream-download=1)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/martineesmaa/vvdec/build
[  3%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/AdaptiveLoopFilter.cpp.o
[  3%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/BitStream.cpp.o
[  5%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/CodingStructure.cpp.o
[  7%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/Contexts.cpp.o
[ 11%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/ContextModelling.cpp.o
[ 11%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/InterPrediction.cpp.o
[ 13%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/Buffer.cpp.o
[ 15%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/ChromaFormat.cpp.o
[ 16%] Building CXX object source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/InterpolationFilter.cpp.o
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/Slice.h:52,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/WeightPrediction.h:50,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/InterPrediction.h:51,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/InterPrediction.cpp:47:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h: In member function ‘void vvdec::InputBitstream::load_next_bits(int)’:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h:206:21: error: ‘simde_bswap64’ was not declared in this scope
  206 |       m_held_bits = simde_bswap64( *reinterpret_cast<uint64_t*>( &m_fifo[m_fifo_idx] ) );
      |                     ^~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/Slice.h:52,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/Picture.h:55,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/Buffer.cpp:54:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h: In member function ‘void vvdec::InputBitstream::load_next_bits(int)’:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h:206:21: error: ‘simde_bswap64’ was not declared in this scope
  206 |       m_held_bits = simde_bswap64( *reinterpret_cast<uint64_t*>( &m_fifo[m_fifo_idx] ) );
      |                     ^~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.cpp:47:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h: In member function ‘void vvdec::InputBitstream::load_next_bits(int)’:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h:206:21: error: ‘simde_bswap64’ was not declared in this scope
  206 |       m_held_bits = simde_bswap64( *reinterpret_cast<uint64_t*>( &m_fifo[m_fifo_idx] ) );
      |                     ^~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/Slice.h:52,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/ContextModelling.h:51,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/ContextModelling.cpp:47:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h: In member function ‘void vvdec::InputBitstream::load_next_bits(int)’:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h:206:21: error: ‘simde_bswap64’ was not declared in this scope
  206 |       m_held_bits = simde_bswap64( *reinterpret_cast<uint64_t*>( &m_fifo[m_fifo_idx] ) );
      |                     ^~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/Slice.h:52,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/CodingStructure.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/AdaptiveLoopFilter.cpp:49:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h: In member function ‘void vvdec::InputBitstream::load_next_bits(int)’:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h:206:21: error: ‘simde_bswap64’ was not declared in this scope
  206 |       m_held_bits = simde_bswap64( *reinterpret_cast<uint64_t*>( &m_fifo[m_fifo_idx] ) );
      |                     ^~~~~~~~~~~~~
In file included from /home/martineesmaa/vvdec/source/Lib/CommonLib/Slice.h:52,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/CodingStructure.h:54,
                 from /home/martineesmaa/vvdec/source/Lib/CommonLib/CodingStructure.cpp:47:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h: In member function ‘void vvdec::InputBitstream::load_next_bits(int)’:
/home/martineesmaa/vvdec/source/Lib/CommonLib/BitStream.h:206:21: error: ‘simde_bswap64’ was not declared in this scope
  206 |       m_held_bits = simde_bswap64( *reinterpret_cast<uint64_t*>( &m_fifo[m_fifo_idx] ) );
      |                     ^~~~~~~~~~~~~
gmake[2]: *** [source/Lib/vvdec/CMakeFiles/vvdec.dir/build.make:90: source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/BitStream.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: *** [source/Lib/vvdec/CMakeFiles/vvdec.dir/build.make:174: source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/InterPrediction.cpp.o] Error 1
gmake[2]: *** [source/Lib/vvdec/CMakeFiles/vvdec.dir/build.make:146: source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/ContextModelling.cpp.o] Error 1
gmake[2]: *** [source/Lib/vvdec/CMakeFiles/vvdec.dir/build.make:104: source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/Buffer.cpp.o] Error 1
gmake[2]: *** [source/Lib/vvdec/CMakeFiles/vvdec.dir/build.make:76: source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/AdaptiveLoopFilter.cpp.o] Error 1
gmake[2]: *** [source/Lib/vvdec/CMakeFiles/vvdec.dir/build.make:132: source/Lib/vvdec/CMakeFiles/vvdec.dir/__/CommonLib/CodingStructure.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:170: source/Lib/vvdec/CMakeFiles/vvdec.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

So that's my two error logs, but here is a full log if you want it:
fullerrorlogoflinuxarmv7vvdec.zip
Feel free to reply or ask question to me. Thank you! :)
Sincerely

Martin Eesmaa

We'll have a look, thanks

Hi Martin,
Thanks for your report. Your toolchain file also needs to set the compiler flag -mfpu=neon-vfpv3, for example like this:
set( ARM_COMPILER_FLAGS "-mfpu=neon-vfpv3" )
set( CMAKE_C_FLAGS_INIT   "${ARM_COMPILER_FLAGS}" )
set( CMAKE_CXX_FLAGS_INIT "${ARM_COMPILER_FLAGS}" )

I'll add an armv7 toolchain file to code base, since we have some for aarch64 already.
But aside from getting the code to compile:
If your CPU supports 64 bits, I recommend using that mode. I have seen significant performance differences (up to 50% if I remember correctly), when running the decoder either in ARMv7 mode or AARCH64 on the same CPU.
Best regards,
Gabriel

Hi Gabriel, thanks for additional command flags of CMake toolchain to me! :)
My CPU supports 64 bits, so yes I can use recommended mode if I cross compile or native.
I can make pull request to add armv7 toolchain to vvdec if you like to.
Sincerely,
Martin Eesmaa

I used the chance to clean up our provided toolchain files, so I'll create a PR for that myself. But thank you very much for the offer.
Can I close the issue?

@K-os, yes you can close the issue.
Thank you! :)
One thing, I tested it out and it worked with your additional flags, x86 SIMD and ARM SIMD on. When disabling x86 SIMD flag only to compile Linux armv7 binary, it will show results error, so we might to force enabling x86 SIMD for compiling Linux armv7 if optional.

Martin Eesmaa

Oh, good find! Something is not wrapped properly in #ifdef TARGET_SIMD_X86. I'll have a look and keep this issue open as a reminder.

Okay @K-os, alright. Take your time :)

Martin Eesmaa

got the same err with simde_bswap64 while disabling x86 SIMD flag

I'm building for wasm use case, and some browsers may not support wasm simd.


Updated wyoming package broke wyoming-piper tts

I reinstalled the requirements.txt for wyoming-piper last night and it installed a new version of the wyoming package, and now I am no longer able to use TTS from the HA interface and my piper service is logging the following:
Feb 19 08:09:11 wyoming python3[19699]: ERROR:asyncio:Task exception was never retrieved
Feb 19 08:09:11 wyoming python3[19699]: future: <Task finished name='Task-10' coro=<AsyncEventHandler.run() done, defined at /home/jeremy/wyoming-piper/.venv/lib/python3.10/site-packages/wyoming/server.py:28> exception=FileNotFoundError(2, 'No such file or directory')>
Feb 19 08:09:11 wyoming python3[19699]: Traceback (most recent call last):
Feb 19 08:09:11 wyoming python3[19699]:   File "/home/jeremy/wyoming-piper/.venv/lib/python3.10/site-packages/wyoming/server.py", line 35, in run
Feb 19 08:09:11 wyoming python3[19699]:     if not (await self.handle_event(event)):
Feb 19 08:09:11 wyoming python3[19699]:   File "/home/jeremy/wyoming-piper/wyoming_piper/handler.py", line 98, in handle_event
Feb 19 08:09:11 wyoming python3[19699]:     wav_file: wave.Wave_read = wave.open(output_path, "rb")
Feb 19 08:09:11 wyoming python3[19699]:   File "/usr/lib/python3.10/wave.py", line 509, in open
Feb 19 08:09:11 wyoming python3[19699]:     return Wave_read(f)
Feb 19 08:09:11 wyoming python3[19699]:   File "/usr/lib/python3.10/wave.py", line 159, in __init__
Feb 19 08:09:11 wyoming python3[19699]:     f = builtins.open(f, 'rb')
Feb 19 08:09:11 wyoming python3[19699]: FileNotFoundError: [Errno 2] No such file or directory: ''

Here's the command line I am using in my wyoming-piper service, and I didn't see any other flags to specify another folder, so I don't know what it's looking for in the error. Any ideas? :
ExecStart=/home/jeremy/wyoming-piper/.venv/bin/python3 -m wyoming_piper \
  --piper '/home/jeremy/.local/bin/piper' \
  --uri 'tcp://<IP_ADDRESS>:10200' \
  --data-dir /config/piper_data/data \
  --download-dir /config/piper_data/download \
  --voice en_US-libritts_r-medium \
  --max-piper-procs 16 \
  --update-voices

The error suggests that the piper executable isn't generating WAV files.

The following troubleshooting changed nothing.

Removing piper and readding in the Wyoming integation.
Moving out of my LXD container back to my piper installation in the standard Docker image
Deleting all the downloaded voices and having them redownload
Switching voices, although this did reveal that the only voice that couldn't use TTS was the one I wanted to use, which was libritts_r medium. All the others worked.

In the end, what fixed it was just restarting Home Assistant on my Pi. Now libritts_r works and the error above no longer occurs. Closing issue.

Update:
Thinking that the problem might be resolved fully by the reboot, I removed the working Docker instance of Piper from the Wyoming integration and moved back to my LXD install of Piper, and the problem occurred again with that FileNotFoundError error. This persisted even after another HA reboot.
This was my setup process in LXD (which I use just like a regular Linux VM). I am just cloning the repo and running script/setup for each of the three components:
git clone https://github.com/rhasspy/wyoming-faster-whisper.git
cd wyoming-faster-whisper
script/setup
cd ~
git clone https://github.com/rhasspy/wyoming-piper.git
~/wyoming-piper/script/setup
script/setup
cd~
git clone https://github.com/rhasspy/piper.git
~/piper/src/python_run
script/setup

And then from ~/piper/src/python_run I run the following to verify Piper is working:
echo the time is now 3 15 pm | script/piper --cuda --model /config/piper_data/data/en_US-libritts_r-medium.onnx --output_file time.wav

This works fine, and generates the appropriate wav file, which I verified matches the text I gave, so Piper is definitely able to generate TTS audio.
I'm not doing any other special configuration beyond my service file, which looks like this:
# /etc/systemd/system/piper.service
[Unit]
Description=Piper
After=network.target

[Service]
Type=simple
User=jeremy
WorkingDirectory=/home/jeremy/wyoming-piper
ExecStart=/home/jeremy/wyoming-piper/script/run \
  --piper '/home/jeremy/piper/src/python_run/script/piper' \
  --uri 'tcp://<IP_ADDRESS>:10200' \
  --data-dir /config/piper_data/data \
  --download-dir /config/piper_data/download \
  --voice en_US-libritts_r-medium \
  --max-piper-procs 16 \
  --update-voices
Restart=always

[Install]
WantedBy=multi-user.target

The main difference as far as I understand at the moment is that the older Docker version is running an older version of wyoming-piper that works, and what I'm using in LXD is just the latest from your repo, which is where the FileNoteFoundError is generated.
All of this is probably putting the cart before the horse though since the main reason I wanted to do any of this was to get Cuda support in Piper, but the merge request to add it looks like it's been sitting idle waiting on final approval for the last two months now. Why is that by the way?

All of this is probably putting the cart before the horse though since the main reason I wanted to do any of this was to get Cuda support in Piper, but the merge request to add it looks like it's been sitting idle waiting on final approval for the last two months now. Why is that by the way?

I'd love to get CUDA support in, but I have a lot on my TODO list. For wyoming-piper and CUDA, I think a better approach than https://github.com/rhasspy/wyoming-piper/pull/5 would be to switch over to the Python version of piper and install onnxruntime-gpu into the container.

@jerblack
Did you ever figure this out? I am having the same issue. The wav files do not seem to be coming into the /tmp directory as they are supposed to. I followed the same process in my LXC that you did. I believe it worked the first command I sent, but after a couple changes it no longer seems to be working. Another note, from homeassistant > media > TTS > Piper I can send a request like "test". I get the same logs as you with file not found. If I try to send "test" again I don't even get any further logs. I have to change the message to something new, like "testing" to see the file not found error again.

FYI @synesthesiam @jerblack here's how I got it to work in our Home Assistant integration project on Jetson devices: https://github.com/dusty-nv/jetson-containers/pull/481/commits/4ba5dc4d20e8fb92f3059e16cc4cfd3648aa88be


Nothing seems to work with run dev, run generate, run build

Hi. I just started following the nuxt-electron documentation. I first tried yarn dev and it did not work it constantly refreshed the port or something like that.
Doing this solved it for my nuxt config.
// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  compatibilityDate: "2024-04-03",
  devtools: { enabled: true },

  modules: [
    (options, nuxt) => {
      if (!nuxt.options.dev) {
        nuxt.options.nitro.runtimeConfig ??= {};
        nuxt.options.nitro.runtimeConfig.app ??= {};
        nuxt.options.nitro.runtimeConfig.app.baseURL = "./";
      }
    },
    "nuxt-electron",
  ],
  electron: {
    disableDefaultOptions: true,
  },
  ssr: false,
  router: {
    options: {
      hashMode: true,
    },
  },
});

However when trying to run yarn generate or yarn build i get this error;
yarn generate
yarn run v1.22.22
$ nuxt generate
Nuxt 3.13.0 with Nitro 2.9.7                                                                                21:16:11
ℹ Using Nitro server preset: static                                                                                21:16:11
ℹ Building client...                                                                                21:16:13
ℹ vite v5.4.2 building for production...                                                                                21:16:13
ℹ ✓ 130 modules transformed.                                                                                21:16:13
ℹ .nuxt/dist/client/manifest.json                   1.06 kB │ gzip:  0.29 kB                                                                                21:16:13
ℹ .nuxt/dist/client/_nuxt/error-500.CIkJDsQj.css    1.88 kB │ gzip:  0.72 kB                                                                                21:16:13
ℹ .nuxt/dist/client/_nuxt/error-404.DXySnQZL.css    3.56 kB │ gzip:  1.10 kB                                                                                21:16:13
ℹ .nuxt/dist/client/_nuxt/entry.BRWiKlTd.css       12.40 kB │ gzip:  2.57 kB                                                                                21:16:13
ℹ .nuxt/dist/client/_nuxt/DAOlUdga.js               2.74 kB │ gzip:  1.23 kB                                                                                21:16:13
ℹ .nuxt/dist/client/_nuxt/DbDNr14Q.js               8.62 kB │ gzip:  3.46 kB                                                                                21:16:13
ℹ .nuxt/dist/client/_nuxt/KgBQtgOK.js             215.93 kB │ gzip: 61.93 kB                                                                                21:16:13
ℹ ✓ built in 718ms                                                                                21:16:13
✔ Client built in 726ms                                                                                21:16:13
ℹ Building server...                                                                                21:16:13
ℹ vite v5.4.2 building SSR bundle for production...                                                                                21:16:13
ℹ ✓ 1 modules transformed.                                                                                21:16:13
ℹ .nuxt/dist/server/styles.mjs  0.07 kB                                                                                21:16:13
ℹ .nuxt/dist/server/server.mjs  0.10 kB │ map: 0.22 kB                                                                                21:16:13
ℹ ✓ built in 7ms                                                                                21:16:13
✔ Server built in 9ms                                                                                21:16:13

 ERROR  options.build is not iterable                                                                                21:16:13

  at build:done (node_modules/nuxt-electron/dist/index.mjs:71:38)
  at node_modules/hookable/dist/index.mjs:48:66
  at node_modules/hookable/dist/index.mjs:48:56
  at async build (node_modules/nuxt/dist/index.mjs:5532:5)
  at async Object.run (node_modules/nuxi/dist/chunks/build.mjs:102:5)
  at async Object.run (node_modules/nuxi/dist/chunks/generate.mjs:60:5)
  at async runCommand$1 (node_modules/nuxi/dist/shared/nuxi.d8541eab.mjs:1648:16)
  at async runCommand$1 (node_modules/nuxi/dist/shared/nuxi.d8541eab.mjs:1639:11)
  at async runMain$1 (node_modules/nuxi/dist/shared/nuxi.d8541eab.mjs:1777:7)

 ERROR  options.build is not iterable                                                                                21:16:13

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

When I run yarn main (as advised by the docs) i get this error;
 yarn main
yarn run v1.22.22
$ dist-electron/main.js
/bin/sh: dist-electron/main.js: Permission denied
error Command failed with exit code 126.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Any ideas? Sorry im a bit new to this..

how does you're package.json scripts look?


Revert "CB-11835 Remove Mock IDBroker Mappings from API test project and E2E tests"

This reverts commit 8e229e8e096dd632e3f088e0d192bf6ca2ede406.

build.eng is still down, overriding.


Record storage objects metadata in database

Feature Description
This idea came to my mind for weeks.
Now, it's almost impossible to inspect the storage usage on Gitea, like how many objects there are, and how much space they took. If I want to know that, I have to write a tool to iterate all objects on disk/s3/blob.
However, things could be much easier if Gitea maintains the info in database when add/remove objects to/from storage. It can record the path and size of the objects, then I can search them with path prefix (it's friendly to database) and get the list, number count and size count.
Is it difficult to implement?
Not really, Gitea has the interface for object storage
// ObjectStorage represents an object storage to handle a bucket and files
type ObjectStorage interface {
	Open(path string) (Object, error)
	// Save store a object, if size is unknown set -1
	Save(path string, r io.Reader, size int64) (int64, error)
	Stat(path string) (os.FileInfo, error)
	Delete(path string) error
	URL(path, name string) (*url.URL, error)
	IterateObjects(path string, iterator func(path string, obj Object) error) error
}

So we can add a new implementation which wraps the inner one and writes to the database after Save and Delete.
Than, add a new page in admin zone, maybe "Code Asserts" > "Objects".
What to do with the existing instances?
Add a cron job that supports manual triggering only, and when users trigger it, call IterateObjects to sync the data into database.
What is it used for?
TBH. the only usage I can think of is just inspecting. It's risky to manage (like remove) them manually. But maybe there will be some new uses in the future.
What if I don't need this and want to save database space?
Add a new config option to disable it, and the "Objects" page will be hide in admin zone.

Another benefit is we can have tags for LFS files on the tree UI.

Another benefit is we can have tags for LFS files on the tree UI.

I am not sure about how to do this. The path of the LFS object in storage is different from the path in the work tree, like images/a.png vs lfs/fe/33/cd16d18ed2009e1aa561a67e6800394a57196225b2cbd8a9ee2a1340ea4e.
And if there's any database tables that could help with that, it should be LFSMetaObject.

Maybe benefit for #31162

Maybe benefit for #31162

It still should be LFSMetaObject.


allows for the exec_service pod image to be pulled from a custom repo

What type of PR is this?
/kind feature

What this PR does / why we need it:
Some clusters may not be able to reach the upstream Kubernetes image repos, like registry.k8s.io, but can reach some internal mirror of these. This will allow to set a custom image repo for the exec_service that cluster loader uses to create the exec pods. You can supply the image repo via a clusterloader2 CLI flag --registry-k8s-repo
Which issue(s) this PR fixes:

Fixes # https://github.com/kubernetes/perf-tests/issues/2704
Special notes for your reviewer:

/ok-to-test

@wojtek-t @mboersma would you be able to take a look?

/lgtm
/approve

/retest

@wojtek-t @mboersma I rebased my changes and lost the LGTM tags. but also, these tests seem to be failing for things unrelated to my change. how could I troubleshoot this? CC @vincepri


Complex expressions in lambda operation not working

Tried to use the latest update on my own project and realised that it doest work for what I actually needed it for. Current solution only supports single simple expressions.
I have made an update that seems to work much better. I will do some more testing and then update tests and documentation.

Sounds good! Thanks!

Sorry been flat out. I will submit a pull request soon

Awesome, thanks!


allow projection of vector fields

I'm trying to project on a Basis which has a Vector, like the following:
import numpy as np
import matplotlib.pyplot as plt

from skfem import *

mesh = MeshTri.init_tensor(x=np.linspace(-1, 1, 20), y=np.linspace(-1, 1, 20))

basis = Basis(mesh, ElementVector(ElementTriP1(), 2))

x = basis.project(lambda w: (w[1], -w[0]))

basis.plot(x)
plt.show()

Like this I get an error like
  File ".../scikit-fem/skfem/assembly/basis/abstract_basis.py", line 410, in _projection
    assert len(interp) == len(self.basis[0])
AssertionError

This pull-request would fix this for this case, but it seems that it should be fixed somehow different.

I think it should work already, the output of the lambda just needs to be a numpy array and not tuple.

Okay, thanks, that fixed it!

The more I think about this the more I have the question:
Is there a reason that project doesn't accept a lambda which returns a tuple/list?
Would there be a reason not to convert a tuple/list in project to a numpy array?
Would somehow let it look cleaner 🤔
Just curious, if there's any reason against it

Perhaps there isn't. One needs to carefully think about the distinctiom between ElementComposite and ElementVector. If those work in a consistent fashion, then it'd be fine.

If you look here: https://github.com/kinnala/scikit-fem/blob/master/skfem/assembly/basis/abstract_basis.py#L389
You can see that it is not as simple as you think. If the output of the callable is tuple, those are already interpreted as different components of ElementComposite. It wouldn't be possible to make this change backwards-compatible.


Epic: Golang SDK for building functions

Forking from https://github.com/GoogleContainerTools/kpt-functions-catalog/pull/196#discussion_r604334320
We currently have a SDK for TS. We should have a similar SDK in golang.
IMO it may look like kubebuilder. It should provide

[WIP] Standard Go pkg for KRM function https://github.com/GoogleContainerTools/kpt/issues/2568
scaffolds source files (including tests). User only need to fill in the funcion logic.
a Dockerfile
a usage doc template
scaffold a Makefile that manages the build lifecycle including build binary, run tests, build and push images and etc.
utilities to convert the usage markdown file to code. We can either pre-generate before compiling or convert it at runtime.

@mengqiy any guess as to the size of this effort?

In Q4, we are focusing on improving the library (kyaml).

IMO it may look like kubebuilder
@mengqiy FWIW, I love this idea so that the function code can be decorated to produce a CRD validation schema among other useful side-effects ala controller-tools


Detecting data corruption for checkpoint files

Issue
Currently, we rely on windows file system API to write, flush and protect the files that have important meta information regarding checkpoints and session recovery points. We need to be able to ensure whatever data we read back during recovery is protected and free from any data corruption.
Proposal
One way to do this is using checksum integrity verifiers. Simply, we can generate a hash for each file and ensure that the hash of the file being used for recovery is consistent.

Closing as this is not on the roadmap as a core FASTER feature at this point. One may implement a custom IDevice that supports this outside the core library. We may re-open the issue in future, or accept contributions from users.


Running Kubernetes as Service

This document explains that I can configure kubernetes to run in the background as a service. Can you expand upon that? start.ps1 has alot to it that needs to be considered if setting this up to run as a service.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8d162332-10db-b9f2-92cc-19475ca448ed
Version Independent ID: 82e7e978-51d0-e563-87bf-e0c82c2bb04a
Content: Troubleshooting Kubernetes
Content Source: virtualization/windowscontainers/kubernetes/common-problems.md
Product: containers
GitHub Login: @gkudra-msft
Microsoft Alias: gekudray

@adagioajanes Rough instructions on how to set this up will be included in the next docs update. We will take some of the functionality out of start.ps1 and move it into a install.ps1 script so that you can run
1 .\install.ps1
2. .\register-svc.ps1  or .\start.ps1
For now, assuming you have run start.ps1 previously, you can run stop.ps1 and then use nssm.exe to launch binary of your choice as a service similar to this

@adagioajanes Rough instructions for this have been added here now: https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/kube-windows-services

There is also more work being done for automatically launching this as a service: https://github.com/microsoft/SDN/blob/master/Kubernetes/windows/kubeadm/Kubecluster.md


gettransaction shows wrong data for spending-address to cold-staking address transaction

Using navcoin-qt I made a new cold-staking address using two addresses where the private key for each one is in the wallet, then I sent navcoin to the cold-staking address from the spending address and when i inputted the transaction id in gettransaction it said false to the ability for the cold-staking address to stake and true to the ability for the cold-staking address to spend.

the rights of a cold staking script are mutually exclusive with spending having priority over staking, thats how its coded.

committed patch f4c9aab

this opens an issue tho. how would that balance be accounted? normal balance? cold staking balance? both?

Yeah we need to have a discussion around how to display this in the GUI

any idea around this? @matt-auckland @djksa

if both the spending key and the staking key are in the same wallet, then either:

The spending key was imported into the staking key wallet or vice versa; or
The cold staking address was created with two addresses from the same wallet.

If both keys are in the same wallet, doesn't this defeat the purpose of coldstaking in the first place? I couldn't find any way to remove keys from a wallet after adding them, so essentially, the coldstaking address is made redundant.
Maybe we could stop either event occurring at the source instead? (i.e. stop two keys from being in the same wallet in the first place at importprivkey() and getcoldstakingaddress())

Can we close this @aguycalled @marcus290 ?


Auto-show/get images when image is free

Also just show it where the video is with a button to full-screen it


Add Brush example to sandbox

Closes #97

I'm curious to test a few things with this, so going to merge and then refactor based on my comments in another commit.


EVP_MD_CTX_[gs]ettable_params take wrong argument type.

They took an EVP_MD_CTX pointer and all the other equivalent functions for other
types accept an algorihtm pointer instead.
Digests also had EVP_MD_[gs]ettable_ctx_params function which worked the way the
EVP_MD_CTX_[gs]ettable_params should.

[x] documentation is added or updated
[ ] tests are added or updated

Uhm, no, don't revert that change, it actually makes better sense

If you want to do something, align the other functions similarly

Okay, I'll rework all the names to EVP_XXX_[gs]ettable_ctx_params.
I still want to delete the EVP_MD_CTX functions, I don't see a need for both.  Especially when they are implemented separately instead of in terms of one another.

I still want to delete the EVP_MD_CTX functions, I don't see a need for both. Especially when they are implemented separately instead of in terms of one another.

They are needed don't delete them! They are required by the EVP_DigestSign functionality

There are scenarios where you have an active EVP_MD_CTX that can get and set parameters but there is no associated EVP_MD object available to the application. #10013.

Personally, I find that whole EVP_PKEY / EVP_MD API quite horrible, but revamping it with something completely new isn't a target for 3.0.  Maybe we could investigate that for 4.0?

Personally, I find that whole EVP_PKEY / EVP_MD API quite horrible, but revamping it with something completely new isn't a target for 3.0. Maybe we could investigate that for 4.0?

Yes, its a mess. EVP_DigestSign's misuse of EVP_MD_CTX is particularly horrible.

Okay, I'll change the EVP_XXX_CTX_ versions to take a context and add the EVP_XXX_ versions that take the algorithm.
The continuance of the EVP_MD abuse was kind of disappointing.  I understand why.  Post 3.0 perhaps.

I've slept on it and I'm unsure of the need for both flavours of the context gettables.
The original code is:
const OSSL_PARAM *EVP_MD_gettable_ctx_params(const EVP_MD *md)
 {
    if (md != NULL && md->gettable_ctx_params != NULL)
         return md->gettable_ctx_params();
      return NULL;
}

const OSSL_PARAM *EVP_MD_CTX_gettable_params(EVP_MD_CTX *ctx)
 {
     if (ctx != NULL
             && ctx->digest != NULL
             && ctx->digest->gettable_ctx_params != NULL)
         return ctx->digest->gettable_ctx_params();
     return NULL;
}

The second function is, sans error checking, equivalent to:
const OSSL_PARAM *EVP_MD_CTX_gettable_params(EVP_MD_CTX *ctx)
{
    return EVP_MD_gettable_ctx_params(ctx->digest);
}

Which is equivalent to a call of EVP_MD_gettable_ctx_params(EVP_MD_CTX_md(ctx))
It seems like only one of the flavours of the context gettable function is necessary (and that the name is incorrect for all other types).
Do we want both flavours still or just a naming fix up?

Arguably, EVP_MD_CTX_gettable_params is a convenience function, and there's really nothing wrong with having those per se.  I agree, though, that it should be rewritten in terms of EVP_MD_gettable_params (but do check that ctx != NULL!).
Either way, for asking the method (not its corresponding context), I would say that EVP_MD_gettable_ctx_params is less confusing than EVP_MD_CTX_gettable_params, because already established patterns...

I've slept on it and I'm unsure of the need for both flavours of the context gettables.

I disagree.

Which is equivalent to a call of EVP_MD_gettable_ctx_params(EVP_MD_CTX_md(ctx))

Right now this is true. It won't be after #10013 is merged. As I said above there are scenarios where you will be able to get and set parameters on an active EVP_MD_CTX, but there is no available EVP_MD object (EVP_MD_CTX_md(ctx) will return NULL).
Please don't make any changes in this area until #10013 is in.

D'oh, forgot. Sorry
(might be a case of selective memory, that I don't want to remember the inner workings :wink:)

@mattcaswell, okay the way forward would seem to be to align all the other types.
Is there a chance that this would be cleaned up at some point in the future?  If so, should we internalise the context based queries?

Closing in favour of #10052 which renames all the other context gettable/settable function to match the naming here.
The EVP_*_CTX_ functions also defined for MDs haven't been added yet.  Should they be public or not?


Create Readme

add introduction and point to leaderboard repo for further instructions.

Hii @sainak can I work on this issue


[Feature] Reduce the calculation load of points2image

New Feature
Points2image is too computation-intensive for processing content.
Since this node occupies about 50% to 110% CPU, improvement is necessary.

@yn-mrse if your fix successfully reduced the computation time please close this issue.

OK


issue with npm install

Hello,
I keep facing the issue with the below error with npm install on my local after I run npm install @upstash/redis although this error is being bypassed with yarn install
node_modules/@upstash/redis/zmscore-uDFFyCiZ.d.ts:283:5 - error TS5084: Tuple members must all have names or all not have names.

283     ...TRest

Since my code is already set up with npm (no issue without this new dependency), it is hard to change everything with yarn only for this dependency.
Do you have any clue how to make it work with npm?
Thanks!

I don't why this happens, but I don't think it's related with the SDK. Maybe clean install would work. Please, remove your lock file and node_module, then run tsc using your current package manager to check the types in your project.

Hi @ogzhanolguncu
Okay after I removed the lock file, that issue is resolved.
Thanks for the prompt response.

Let us know if you need further help.


Add Microsoft.Build.CopyOnWrite

Add new Microsoft.Build.CopyOnWrite package to support Copy on Write.

Most of the code here is copied from MSBuild and minified. The Copy task is fairly complicated, and I wanted to maintain as much compatibility as possible(error codes, etc.).


fixed a typo

Changed "Afer" to "After" in Contributing.md

          3 Messages

:book:
iOS: Executed 253 tests, with 0 failures (0 unexpected) in 11.279 (11.417) seconds

:book:
tvOS: Executed 253 tests, with 0 failures (0 unexpected) in 11.197 (11.344) seconds

:book:
macOS: Executed 253 tests, with 0 failures (0 unexpected) in 12.111 (12.232) seconds

  Generated by :no_entry_sign: Danger


release: v1.0.0-beta1 release fixes

Description

This patch fixes a slew of broken things ranging from unsupported brew
options to missing ldflags and S3 binary uploads.

Updates the Goreleaser image to Go 1.13.x
Updates the Goreleaser version itself to v0.123.3
Removes the Brew section since we're not updating binaries via
goreleaser renders the automatic brew formula generation unusable.
Adds missing BUILT ldflag to .goreleaser.yml
Modifies the goreleaser config so it doesn't upload artifacts GitHub
or create a GitHub release at all
Corrects the v1.0.0-beta1.md release notes.
Updates scripts/goreleaser so that it uploads binaries and checksums
to AWS S3, and publish the GitHub release via hub.

Motivation and Context

Kind of broken release
How Has This Been Tested?

make release
Types of Changes

[x] Bug fix (non-breaking change which fixes an issue)

@ppapapetrou76@karencfv I've changed the format to use bullet points so that doesn't happen anymore. Next releases will have this format.


WIP migration to ES6

https://github.com/dagrejs/graphlib/issues/91
my main concern to use this library is size, but you should be able to start using es6 syntax.
benchmark with rollup and lodash-es size:
before graphlib.min.js - 489 kB
after graphlib.min.js - 33.5 kB
concerns that I want to discuss and hear your opinion:

[ ]  there are breaking changes in library internals (for example now you have to write export {version} from './version'), as I used named exports only, didn't want to resolve all the problems with default compatibility.
[ ] haven't checked that graphlib.core.min.js can work with global lodash. should it? some versions could be incompatible.
[ ]  didn't manage to run karma + istanbul. shouldn't we switch to jest+puppeter? there are no browser-specific logic
[ ] all scripts in package.json are just for demo purposes. we can put them in makefile later
[ ]  need to fix version.js generation. it's okay to have the file in es6 format?

The change would have to be consistent for dagre etc. as well
Can you have a look at #86 which seems a lower risk change to get some size benefits?
You can open a ticket or PR for switch to puppeteer. More of a question who would do the work and sign up to maintain those and again would have to happen across all projects.

The change would have to be consistent for dagre etc. as well

you mean that would be good to have a common setup for several libs?

Can you have a look at #86 which seems a lower risk change to get some size benefits?

I did, but PR is open for quite a long time. and I noticed https://github.com/dagrejs/graphlib/issues/91. updating to es6 modules solves the problem out-of-the-box

You can open a separate ticket or PR discussing the switch to puppeteer. More of a question who would do the work and sign up to maintain it. This would also have to happen across all projects. Maybe start with trying to get karma to work and fix issues?

we could try if maintainers are interested in this PR.
as an option we could disable istanbul temporarily. updating to puppeteer shouldn't be hard. I can help with it as well.

you mean that would be good to have a common setup for several libs?

Yes, the libraries under dagrejs should be consistent.

I did, but PR is open for quite a long time. and I noticed #91. updating to es6 modules solves the problem out-of-the-box

Exactly. There are PRs adopting #86 to all of the projects and not sure the risks are fully understood. Getting this lower risk change reviewed and committed would be more valuable than PRs with higher risk changes at this point.

we could try if maintainers are interested in this PR.
as an option we could disable istanbul temporarily. updating to puppeteer shouldn't be hard. I can help with it as well.

You would have to become the maintainer for this effort. You should first get all test for all the current libraries to work, then understand all the scenarios that need to be covered, and do the migration. Disabling coverage temporarily is problematic as others couldn't make changes. You'd then be responsible to maintain tests in the future.


Add Scala 2.13 support

This is my third attempt to add Scala 2.13 support to FIRRTL
Since we have issues in code, tests and CI, I decided to follow this strategy:

Port main only to 2.13 - Done except of one error for 2.13 - THIS PR
Port tests - TBD in the following 2-nd PR
Update CI - - TBD in the following 3-d PR

In this PR, I added my updates to support 2.13, but still managed tests for 2.11 and 2.12 to pass and avoided Travis-CI issues
Once these changes are merged, I'll move steps 2-3, e.g port tests and update CI
Pls review asap

@jackkoenig @seldridge @ekiwi-sifive @sequencer
Pls review and merge this asap

@ekiwi has a PR based on your earlier PR https://github.com/freechipsproject/firrtl/pull/1796 that I think is almost complete

close since #1796 merged.


Error When i Try To Compile

Terminal Exit Code:
✖ ｢wds｣:  Error: listen EACCES: permission denied <IP_ADDRESS>:80
at Server.setupListenHandle [as _listen2] (node:net:1307:21)
at listenInCluster (node:net:1372:12)
at doListen (node:net:1510:7)
at processTicksAndRejections (node:internal/process/task_queues:84:21) {
code: 'EACCES',
errno: -13,
syscall: 'listen',
address: '<IP_ADDRESS>',
port: 80
}
node:internal/crypto/hash:67
this[kHandle] = new _Hash(algorithm, xofLen);
^
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:67:19)
at Object.createHash (node:crypto:130:10)
at module.exports (/home/ihlahyconley/sm64js/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash (/home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:417:16)
at handleParseError (/home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:471:10)
at /home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:503:5
at /home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:358:12
at /home/ihlahyconley/sm64js/node_modules/loader-runner/lib/LoaderRunner.js:373:3
at iterateNormalLoaders (/home/ihlahyconley/sm64js/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
at Array. (/home/ihlahyconley/sm64js/node_modules/loader-runner/lib/LoaderRunner.js:205:4) {
opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

If you're trying to run it on linux try sudo npm run start and if that doesn't work, try seeing if anything is using port 80

Nope Didn't Work

and no i did not have any thing using port 80

This Error Code May Lead To Testing
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:67:19)
at Object.createHash (node:crypto:130:10)
at module.exports (/home/ihlahyconley/sm64js/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash (/home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:417:16)
at handleParseError (/home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:471:10)
at /home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:503:5
at /home/ihlahyconley/sm64js/node_modules/webpack/lib/NormalModule.js:358:12
at /home/ihlahyconley/sm64js/node_modules/loader-runner/lib/LoaderRunner.js:373:3
at iterateNormalLoaders (/home/ihlahyconley/sm64js/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
at Array. (/home/ihlahyconley/sm64js/node_modules/loader-runner/lib/LoaderRunner.js:205:4) {
opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'

What OS are you using and what Node JS version are you using?
This seems more like something wrong with Node JS itself maybe, try to see if you can compile any other Node JS project

Debian 11

dang silent treatment

dang silent treatment

run these commands, just paste the whole list. then try again.
sudo apt update
sudo apt install nodejs
sudo apt install npm

dang silent treatment

run these commands, just paste the whole list. then try again.
sudo apt update sudo apt install nodejs sudo apt install npm

n o p e it didn't work

dang silent treatment

run these commands, just paste the whole list. then try again.
sudo apt update sudo apt install nodejs sudo apt install npm

n o p e it didn't work

apt or npm?

@Agent-11 you can close this.

oh I didn't even realize this thread was still going on until you pinged me
My guess is your node js install is corrupted, don't know how an error with node js internal is relevant to sm64js if everyone can compile perfectly fine.

after re-installing Debian It Still Will Not Work


formulae_detect: actually use origin/master for starting SHA1

Here, origin_ref points to the temporary merge group branch, so it
will be the same as GITHUB_SHA.

Success! https://github.com/Homebrew/homebrew-core/actions/runs/4700582256/jobs/8335467036

Nice work @carlocab!


Add nox and synth templates.

Convert tox to noxfile.py
Add some templates from synth (mainly for .kokoro)
Blacken tests, googleapiclient, apiclient.

Please review the first commit (before files are blackened).

Obsolete. See #852


Special requirements for 1.1.0?

Versions

sequelize: 5.21.2
sequelize-typescript: 1.1.0
typescript: 3.7.3

I'm submitting a ...

[x ] bug report
[ ] feature request
(More of a question than a bug.)
Actual behavior:

I've inherited a project that uses sequelize-typescript bundled via webpack. The project breaks when I updated sequelize-typescript to from 1.0.0 to 1.1.0 (or from 1.0.0 to 1.1.0-beta.0). I don't see any errors other than the database activity that should happen on app start simply doesn't occur. In tracking it down, I can see that webpack is bundling far fewer references to sequelize-typescript when 1.1.0 or 1.1.0-beta.0 are installed than when 1.0.0 is installed.
I know that's not much to go on, so I've scoped the question to asking if there are any new requirements I might not be aware of when updating to 1.1.0. Specifically, it looks like https://github.com/RobinBuschmann/sequelize-typescript/commit/de6f6ab7d050cbf8f04a32399460b0c995a5ab52 was the last major change between 1.1.0 and 1.1.0-beta.0. Is anything special required as a result of that change?
Expected behavior:

Given that 1.1.0 was a minor release, I'd expect no breaking changes.
Steps to reproduce:

I don't have any readily reproducible steps, unfortunately.
Related code:
<!-- If you are able to illustrate the bug or feature request with an example, please provide a sample application via one of the following means:
Not able to provide a sample.

Hey @chscott , thanks for reporting. In order to be able to use the models on client side, the feature implemented with the commit you've mentioned, was developed. Since you've bundling your app for server side, this feature shouldn't apply 🤔 What target is set in you webpack config? (Here is a link to the PR including the discussion)

The target is electron-renderer. That's not something I was looking at, but a quick search of that and webpack turns up this issue. I haven't fully digested it yet, but I wonder if it's related.

The target is electron-renderer. That's not something I was looking at, but a quick search of that and webpack turns up this issue. I haven't fully digested it yet, but I wonder if it's related.

@Toxicable Can you have a look at this issue? Is there something we can do? Is there a workaround you can think of?

From the issue I linked, it may have nothing to do with sequelize-typescript at all and that the only reason 1.0.0 works for me is that it omitted the browser support, thus not giving webpack a chance to make the wrong decision. I'm on webpack 4.41.2, which I believe is impacted by that issue.
I'll try some of the workarounds from the webpack thread and update here for posterity.

The solution here worked for me. I'm not sure it's the most desired solution, but it's enough for me to believe this isn't an issue with sequelize-typescript.
Thanks for the help!

 Good to here you find a solution.


Feature/social login linkedin | WIP

Description
Add LinkedIn login.
Checklist

[x] I have performed a self-review of my own code

Right now there's a bug I can't resolve:
I can get the linkedin auth page, but the callback doesn't work at all, I get a 500 without further explanation.
Default example is there (passportjs docs are not up to date):
https://github.com/auth0/passport-linkedin-oauth2

LinkedIn is not going to be added for now because of unknown bug and other priority for our app.
Feel free to reopen if you want to tackle that issue.


fix (#minor); makerdao; fixed inaccurate TVL

This PR fixes inaccurate TVL/inputTokenBalance in maker markets, esp. ETH-A and ETH-B, as reported in #1695 . Basically, a refactoring I did to consolidate handlers causes liquidated collateral not removed from TVL. To fix this, I moved liquidatePosition call up to Cat.Bite() and Dog.Bark() when liquidation auction was first set up, from when liquidation auction ends (handleFlipEndAuction() and handleClipTakeBid()).
Deployment & validation (sync in progress)

test deployment: https://thegraph.com/hosted-service/subgraph/tnkrxyz/makerdao-ethereum?version=pending&selected=logs
validation dashboard: https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/id/QmdWkF7LsHEq88hrMAMHdoCeNxLyzSqNZdd2qyHiCCpCXQ&tab=protocol

@tnkrxyz Was going to take a look at this, but looks like the deployment failed.

@tnkrxyz Was going to take a look at this, but looks like the deployment failed.

Fixed (hopefully) and redeployed.

looks like the syncing is failing

looks like the syncing is failing

Yup, a different issue. Fixed & restarted.

Issue resolved, thanks @tnkrxyz

@tnkrxyz deployment failed

thnks @tnkrxyz

@tnkrxyz @ishraq8 the protocol side revenue looks like there was an issue


Extra copy of S3 GetObj Body

I don't know why. But this resolves the problem I saw when Saucer sometimes failed to read the Meta header completely.
See this error:
https://poolside.grafana.net/a/grafana-lokiexplore-app/explore/service/cep-saucer-ingester/logs?patterns=[]&var-fields=&var-levels=&var-ds=grafanacloud-logs&var-patterns=&var-lineFilter=|~ `(%3Fi)cannot read`&var-filters=service_name|%3D|cep-saucer-serve&urlColumns=[]&visualizationType="logs"&displayedFields=[]&from=now-5m&to=now

oops. wrong repo to open this PR....


Why is this package not on PyPI?

Why is this package not on PyPI, is there a particular reason? It would be extremely useful if it was, I know it is unrelated but I am having a lot of trouble getting to work as dependency for my own package  because of it.

Hi.  Thank you for the reminder, I will look into it "sometime soon".

Actually, I just did it. There's a release-candidate on PyPI now. I did some quick testing, but please give it a try and let me know if it works for you; this is my first package on PyPI.

Closing the issue. Please open new issues if the PyPI package doesn't work.

Sorry, have been on vacation, just tested it, it seems to be working fine.

Cool, no worries and thanks for the feedback!


ubuntu ppa dont exist ;-;

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

WARNING
All invalid issues will be rejected!!

Before going further

If your problem is a bug with youtube-dl or a request for new site support please report it here

Make sure you are using the latest youtube-dl-gui version (Click the Settings icon and then About to view the current version)

Make sure you are using the latest youtube-dl version (Click the Settings icon and then Update to update to the latest youtube-dl version)

Make sure you searched the bugtracker for similar issues including closed ones

Make sure to read the FAQs file

[ ] I think my problem is NOT with youtube-dl
[ ] I've verified and i assure that I'm running youtube-dl-gui 0.4
[ ] I assure that i am using the latest version of youtube-dl
[ ] Searched bugtracker
[x ] I've read the FAQs file

What is the purpose of your issue?

[ ] Bug report
[ ] Feature request (request for a new functionality)
[ ] Question
[ x] Other

Please remove any sections between (---) if they are not related to your issue

Bug report
If the problem occurs when downloading a URL please provide the full verbose output as follows:

Restart youtube-dl-gui
Go to Options > Extra tab
Enable Debug youtube-dl
Go to Options > Advanced tab and Clear your log content
Try to download the URL
Copy the whole log content and insert it between the ``` part below

delete me and insert your log content here

What operating system do you use ?
ubuntu 20.04
List of actions to perform to reproduce the problem:

.. I o to the official GitHub page, in the download section
.. Click in the Ubuntu PPA link
.. And the page that opens says " Not Found, The requested URL was not found on this server.
Apache/2.4.18 (Ubuntu) Server at ppa.launchpad.net Port 443 "

What is the expected behaviour ?
that have the ppa '-'
What happens instead ?
dont have '-'

Feature request (request for a new functionality)
Please make sure that the requested feature is NOT already in the TODO list

[ ] I've verified and i assure that my requested feature is NOT in the TODO list

What operating system do you use ?

This project is abandoned. The ppa has been removed because all python 2 software is being removed, and youtube-dl-gui is written in python 2.
You can try this fork or my fork.


delft3dfm WARNINGS

When running the workflow on 2023-03-31 I get the following errors, but the data is still generated.
tttz_waq_0000.dia:** WARNING: Requested time was: 2023-03-17T00:01:00Z !
tttz_waq_0000.dia:** WARNING: Updating target failed, quantity='waterlevelbnd', itemId=      56
tttz_waq_0000.dia:** WARNING: Updating source failed, quantity='polytim_item', item=      57, location=
tttz_waq_0000.dia:** WARNING: Updating target failed, quantity='polytim_item', itemId=      57
tttz_waq_0000.dia:** WARNING: Updating source failed, quantity='WATERLEVELBND', item=      58, location=EAST2_0001
tttz_waq_0000.dia:** WARNING: Datablock end (new [forcing] block) has been prematurely reached.
tttz_waq_0000.dia:** WARNING:    File: input/steric_east2.bc, Location: EAST2_0001, Quantity: WATERLEVELBND
tttz_waq_0000.dia:** WARNING: Error while updating boundary forcing at time=258984060.000
tttz_waq_0001.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq_0001.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq_0001.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.

tttz_waq_0001.dia:** WARNING: Requested time was: 2023-03-17T00:01:00Z !
tttz_waq_0001.dia:** WARNING: Updating target failed, quantity='waterlevelbnd', itemId=      56
tttz_waq_0001.dia:** WARNING: Updating source failed, quantity='polytim_item', item=      57, location=
tttz_waq_0001.dia:** WARNING: Updating target failed, quantity='polytim_item', itemId=      57
tttz_waq_0001.dia:** WARNING: Updating source failed, quantity='WATERLEVELBND', item=      58, location=EAST2_0001
tttz_waq_0001.dia:** WARNING: Datablock end (new [forcing] block) has been prematurely reached.
tttz_waq_0001.dia:** WARNING:    File: input/steric_east2.bc, Location: EAST2_0001, Quantity: WATERLEVELBND
tttz_waq_0001.dia:** WARNING: Error while updating boundary forcing at time=258984060.000
tttz_waq_0002.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq_0002.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq_0002.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.
tttz_waq_0003.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq_0003.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq_0003.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.
tttz_waq_0004.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq_0004.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq_0004.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.

ttz_waq_0004.dia:** WARNING: Requested time was: 2023-03-17T00:01:00Z !
tttz_waq_0004.dia:** WARNING: Updating target failed, quantity='waterlevelbnd', itemId=      56
tttz_waq_0004.dia:** WARNING: Updating source failed, quantity='polytim_item', item=      57, location=
tttz_waq_0004.dia:** WARNING: Updating target failed, quantity='polytim_item', itemId=      57
tttz_waq_0004.dia:** WARNING: Updating source failed, quantity='WATERLEVELBND', item=      58, location=EAST2_0001
tttz_waq_0004.dia:** WARNING: Datablock end (new [forcing] block) has been prematurely reached.
tttz_waq_0004.dia:** WARNING:    File: input/steric_east2.bc, Location: EAST2_0001, Quantity: WATERLEVELBND
tttz_waq_0004.dia:** WARNING: Error while updating boundary forcing at time=258984060.000
tttz_waq_0005.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq_0005.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq_0005.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.

tttz_waq_0005.dia:** WARNING: Requested time was: 2023-03-17T00:01:00Z !
tttz_waq_0005.dia:** WARNING: Updating target failed, quantity='waterlevelbnd', itemId=      56
tttz_waq_0005.dia:** WARNING: Updating source failed, quantity='polytim_item', item=      57, location=
tttz_waq_0005.dia:** WARNING: Updating target failed, quantity='polytim_item', itemId=      57
tttz_waq_0005.dia:** WARNING: Updating source failed, quantity='WATERLEVELBND', item=      58, location=EAST2_0001
tttz_waq_0005.dia:** WARNING: Datablock end (new [forcing] block) has been prematurely reached.
tttz_waq_0005.dia:** WARNING:    File: input/steric_east2.bc, Location: EAST2_0001, Quantity: WATERLEVELBND
tttz_waq_0005.dia:** WARNING: Error while updating boundary forcing at time=258984060.000
tttz_waq_0006.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq_0006.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq_0006.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.
tttz_waq_0007.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq_0007.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq_0007.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.
tttz_waq.dia:** WARNING: The keyword DtMassBalance in the Processes section is now replaced by MbaInterval in the Output section.
tttz_waq.dia:** WARNING: MbaInterval was not specified, will use DtMassBalance for backwards compatibility.
tttz_waq.dia:** WARNING: readMDUFile: [processes] procesdatabasefile=proc_def.dat was in file, but not used. Check possible typo.

cc @lorincmeszaros @arthurvd

Seems like it didn't download cmems data for 18 March, will need to investigate that.

Running the download rules individually downloads the correct data:
snakemake -R download_cmems_physics --cores 1 and snakemake -R download_cmems_biogeochemistry --cores 1 fetches data up to 18 March.
Will test snakemake --cores 1 all, to double check things aren't going wrong with the parallelisation.
cc @sebastian-luna-valero

snakemake --cores 1 all seemed to work without problems

Now it seems to work...


Add OpenAI ArXiv Dataset

This PR adds a 2 million size embedding dataset of 1536-dimensional OpenAI ada-002 embeddings of the abstracts of ArXiv papers. The original ArXiv dataset was released by Cornell University on kaggle under a CC0 license. We provide a set of 20000 queries also embedded from the abstracts of ArXiv articles, as well as groundtruth for the first 100000 vectors and the full 2321096 vectors.

Added comment in datasets.py describing the dataset, marking as ready for review.


fix: json wasn't encoding properly

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: jibon57:x: code-factorYou have signed the CLA already but the status is still pending? Let us recheck it.


Provide ability to move EDB content to SQL DB

Now we have SQL support in Server 1803 (SAC) / 2019 (LTSC), it would be nice if we could get the content out of the EDB and insert it directly in the SQL Database to preserve existing node registrations and reporting data.
Right now my thinking is to have the ability to either create a new SQL DB from scratch or be able to connect up with an existing one.

[ ] Cmdlet/Function to create a new DB
[ ] Cmdlet/Function to connect with existing DB (created by either the Pull Server itself or by using the previously mentioned Cmdlet/Function)
[ ] Cmdlet/Function to convert EDB data to SQL INSERT Statements and execute on DB if not exists

perhaps its worth depending on the sqlserver module. There are two very easy commands read-sqltabledata and write-sqltabledata. Saves use reinventing the wheel. IMO this is a one time this so a simple Import-DSCPullServerData -edbfile -sqlserver -sqlinstance should be sufficient

I can start working on some of the helper functions to split this feature into multiple PRs. Do you want to create a new branch to separate the incomplete version from master?

master is pretty much alpha so I'm fine taking PRs to this branch. Thanks for helping out @rdbartram!

Version 0.1.0 is now released implementing all envisioned features. 🎉