Error building shared libraries for MacOS

Is shared lib even supported on macOS?
MacOS Monterey (12)
LLVM-10, clang and flang from the classic flang project
CPU: Ryzen 5 (ZEN)
Build script:
#!/bin/bash

RANLIB="/usr/local/bin/llvm-ranlib"

TARGET_SDKROOT="$(xcrun --show-sdk-path)"
CC="/usr/local/bin/clang"
FC="/usr/local/bin/flang"

COMMON_FLAGS="-isysroot $TARGET_SDKROOT"
FFLAGS=$COMMON_FLAGS" -L/usr/local/lib"
LDFLAGS=" -L/usr/local/lib"

HOST_SDKROOT="$(xcrun --show-sdk-path)"
HOSTCC="/usr/local/bin/clang -isysroot $HOST_SDKROOT"

make TARGET=ZEN BINARY=64 HOSTCC="$HOSTCC" CC="$CC" CFLAGS="$COMMON_FLAGS" FC="$FC" FFLAGS="$FFLAGS" RANLIB="$RANLIB" VERBOSE=1 USE_OPENMP=0 NO_LAPACK=0 NOFORTRAN=0 PREFIX=/Users/tuco/Projects/OpenBLAS/macOS/install libs netlib re_lapack shared install

The "interesting" part of the error:
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm  -lflang
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
ld: warning: dylib (/usr/local/lib/libflang.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libflangrti.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libpgmath.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libompstub.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: object file (/usr/local/lib/libflangmain.a(flangmain.c.o)) was built for newer macOS version (10.17) than being linked (10.8)
Undefined symbols for architecture x86_64:
  "_MAIN_", referenced from:
      _main in libflangmain.a(flangmain.c.o)
ld: symbol(s) not found for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libopenblas_zenp-r0.3.19.dev.dylib] Error 1
make: *** [shared] Error 2

The full enormous log (VERBOSE=1): https://gist.github.com/meow464/3d55454c05d581a042f35616172b8bb1
(There are a lot of warnings about target overriding, this is a flang problem, the output is for the correct target)

Is shared lib even supported on macOS?

Yes, but you are using an extremely new and experimental fortran compiler which is not supported yet.
Probably f_check file needs to drop flangmain as it's only used for executable.

I checked the f_check file but it seems to only add -lflang.

I then tried passing -v to flang and ld

perl ./gensymbol osx x86_64 _ 0 0  0 0 0 0 "" "" 1 0 1 1 1 1 > osx.def
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm  -lflang
clang version 10.0.1 (https://github.com/flang-compiler/classic-flang-llvm-project.git 4a566ddfa4157ed1a24920ab7673ccc01c46fd99)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /usr/local/bin
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
 "/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -headerpad_max_install_names -platform_version macos 10.8.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -lflangmain -exported_symbols_list osx.def -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm -lflang -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem
ld: warning: dylib (/usr/local/lib/libflang.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libflangrti.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libpgmath.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libompstub.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: object file (/usr/local/lib/libflangmain.a(flangmain.c.o)) was built for newer macOS version (10.17) than being linked (10.8)
Undefined symbols for architecture x86_64:
  "_MAIN_", referenced from:
      _main in libflangmain.a(flangmain.c.o)
ld: symbol(s) not found for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libopenblas_zenp-r0.3.19.dev.dylib] Error 1
make: *** [shared] Error 2

And indeed flang has the very default looking  -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm with an additional -lflang appended at the end, which I assume comes from f_check.
Note that those flags on the ld command can be split into 3 groups:

-lflangmain -exported_symbols_list osx.def
-lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm -lflang
-lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem

As for what they are:

I don't know what this is;
I assume this is inherited from the flang command line;
What I think would be valid ld parameters.

Passing -no-flang-libs -no-flang-libs to flang doesn't yield much better results:

The new error message

/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -no-flang-libs -no-flang-libs -O2 -Mrecursive -Kieee -Wall -fPIC -m
sse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.
dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm  -lflang
clang version 10.0.1 (https://github.com/flang-compiler/classic-flang-llvm-project.git 4a566ddfa4157ed1a24920ab7673ccc01c46fd99)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /usr/local/bin
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
 "/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -
headerpad_max_install_names -platform_version macos 10.8.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -
L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -exported_symbols_list osx.def -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm -lflang -lSystem
ld: warning: dylib (/usr/local/lib/libflang.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libflangrti.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libompstub.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libpgmath.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: object file (/usr/local/lib/libflangmain.a(flangmain.c.o)) was built for newer macOS version (10.17) than being linked (10.8)
Undefined symbols for architecture x86_64:
  "_MAIN_", referenced from:
      _main in libflangmain.a(flangmain.c.o)
ld: symbol(s) not found for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libopenblas_zenp-r0.3.19.dev.dylib] Error 1
make: *** [shared] Error 2

ld now has a small improvement: -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm -lflang -lSystem
Except for the double -lSystem, the double -lflang and the single -lflangmain it looks almost right.
And indeed if I remove -lflangmain and call the linker command from the "export" directory the .dylib is generated just fine:
"/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -headerpad_max_install_names -platform_version macos 10.8.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -exported_symbols_list osx.def -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm -lflang -lSystem

The problems seem to be that flang retains the default linking options instead of using just -lflang. It's not clear to me why this is happening but I'm very open to ideas.
This message has a lot of markdown. I did my best but please let me know if it's hard to read.

The f_check script has a section near the end where it removes some libraries from the default list the compiler would use, probably flangmain would need to be included there (and possibly added back for linking the test executables...)

Given the problems below it seems like this would help but perl is not one of my strengths and I can't find what you are referring to.

These commands are ran from the export folder as before.
The problem persists if I call flang directly with only -lflang, it auto inserts all the other flags including -lflangmain in the linker command:
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflang
clang version 10.0.1 (https://github.com/flang-compiler/classic-flang-llvm-project.git 4a566ddfa4157ed1a24920ab7673ccc01c46fd99)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /usr/local/bin
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
 "/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -headerpad_max_install_names -platform_version macos 10.17.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -lflangmain -exported_symbols_list osx.def -lflang -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem
Undefined symbols for architecture x86_64:
  "_MAIN_", referenced from:
      _main in libflangmain.a(flangmain.c.o)
ld: symbol(s) not found for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)

But if I use -no-flang-libs -lflang -lflangrti -lpgmath -lompstub -lm -lpthread it works:
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -no-flang-libs
clang version 10.0.1 (https://github.com/flang-compiler/classic-flang-llvm-project.git 4a566ddfa4157ed1a24920ab7673ccc01c46fd99)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /usr/local/bin
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
 "/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -headerpad_max_install_names -platform_version macos 10.17.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -exported_symbols_list osx.def -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem

But if I add those flags to f_check#L395 the problem persists:
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm  -no-flang-libs -lflang -lflangrti -lpgmath -lompstub -lm -lpthread
clang version 10.0.1 (https://github.com/flang-compiler/classic-flang-llvm-project.git 4a566ddfa4157ed1a24920ab7673ccc01c46fd99)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /usr/local/bin
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
 "/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -headerpad_max_install_names -platform_version macos 10.8.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -exported_symbols_list osx.def -lflangmain -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lm -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem
ld: warning: dylib (/usr/local/lib/libflang.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libflangrti.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libpgmath.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libompstub.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: object file (/usr/local/lib/libflangmain.a(flangmain.c.o)) was built for newer macOS version (10.17) than being linked (10.8)
Undefined symbols for architecture x86_64:
  "_MAIN_", referenced from:
      _main in libflangmain.a(flangmain.c.o)
ld: symbol(s) not found for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libopenblas_zenp-r0.3.19.dev.dylib] Error 1
make: *** [shared] Error 2

I'll try to provide a patch in a few hours    when I have time. Btw did you build flang-classic yourself or is there a package in homebrew or whatever that I could plug into the CI job to test ?

I build it myself. MacOS is a recent addition to flang and I don't think there is a homebrew package yet. The build instructions are simple enough, just replace gcc and g++ with clang and clang++. I recommend adding -DCMAKE_BUILD_TYPE=Release to setup.sh to speed things up.
I uploaded my own build here (the tar file, not the zip). To use it simply extract to /usr/local/stow and run cd /usr/local/stow && stow flang. You need to have stow installed of course.

It seems -fno-fortran-main is not working.... I see no reason why this command line shouldn't work.
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflang -fno-fortran-main
clang version 10.0.1 (https://github.com/flang-compiler/classic-flang-llvm-project.git 4a566ddfa4157ed1a24920ab7673ccc01c46fd99)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /usr/local/bin
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
 "/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -headerpad_max_install_names -platform_version macos 10.17.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -lflangmain -exported_symbols_list osx.def -lflang -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem
Undefined symbols for architecture x86_64:
  "_MAIN_", referenced from:
      _main in libflangmain.a(flangmain.c.o)
ld: symbol(s) not found for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)

Just to make clear what works, this command ran from the command line in the exports folder succeeds:
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -fno-fortran-main -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -mavx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -no-flang-libs -lflang -lflangrti -lpgmath -lompstub -lm -lpthread

Applying this diff to f_check works. But ideally -fno-fortran-main would work.

My hunch for f_check was simply:
--- a/f_check
+++ b/f_check
@@ -363,6 +363,7 @@ if ($link ne "") {
            && ($flags !~ /gfortranbegin/)
            && ($flags !~ /frtbegin/)
            && ($flags !~ /pathfstart/)
+           && ($flags !~ /flangmain/)
            && ($flags !~ /crt[0-9]/)
            && ($flags !~ /gcc/)
            && ($flags !~ /user32/)

but this is untested

Still didn't work. It did remove -lflangmain from the flang command line which is definitely part of the solution, but LD still uses -lflanmain. Removing -all_load does the trick but that will probably break other things.
/usr/local/bin/flang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -L/usr/local/lib -v -O2 -Mrecursive -Kieee -Wall -fPIC -msse3 -msse4.1 -mavx -mavx2 -ma
vx2  -all_load -headerpad_max_install_names -install_name "/Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib" -dynamiclib -o ../libopenblas_zenp-r0.3.19.dev.dylib ../libopenblas_zenp-r0.3.19.dev.a -Wl,-exported_symbols_list,osx.def  -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem  -lflang                                                                                clang version 10.0.1 (https://github.com/flang-compiler/classic-flang-llvm-project.git 4a566ddfa4157ed1a24920ab7673ccc01c46fd99)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /usr/local/bin
clang-10: warning: argument unused during compilation: '-Mrecursive' [-Wunused-command-line-argument]
clang-10: warning: argument unused during compilation: '-Kieee' [-Wunused-command-line-argument]
 "/usr/bin/ld" -demangle -lto_library /usr/local/stow/flang/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -dylib_install_name /Users/tuco/Projects/OpenBLAS/macOS/OpenBLAS/exports/../libopenblas.0.dylib -all_load -
headerpad_max_install_names -platform_version macos 10.8.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ../libopenblas_zenp-r0.3.19.dev.dylib -L/usr/local/lib ../libopenblas_zenp-r0.3.19.dev.a -lflangmain -exported_symbols_list osx.def -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem -lflang -lflang -lflangrti -lpgmath -lompstub -lm -lpthread -lSystem                                                                                ld: warning: dylib (/usr/local/lib/libflang.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libflangrti.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libpgmath.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: dylib (/usr/local/lib/libompstub.dylib) was built for newer macOS version (10.17) than being linked (10.8)
ld: warning: object file (/usr/local/lib/libflangmain.a(flangmain.c.o)) was built for newer macOS version (10.17) than being linked (10.8)
Undefined symbols for architecture x86_64:
  "_MAIN_", referenced from:                                                                                _main in libflangmain.a(flangmain.c.o)                                                                                ld: symbol(s) not found for architecture x86_64
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libopenblas_zenp-r0.3.19.dev.dylib] Error 1
make: *** [shared] Error 2

It seems -fno-fortran-main is being ignored. See: https://github.com/flang-compiler/flang/issues/1221

-force_load ../libopenblas_zenp-r0.3.19.dev.a also seems to work, but it could also break subtly. I don't know enough about OpenBLAS to judge.

I added it to f_check#L396 and yes it works.  I also have the flangmain excluding  code you posted.
I will now test the flang patch posted on the issue.

For reference these are the changes necessary to f_check
diff --git a/f_check b/f_check
index 4825fb09..46715010 100644
--- a/f_check
+++ b/f_check
@@ -363,6 +363,7 @@ if ($link ne "") {
            && ($flags !~ /gfortranbegin/)
            && ($flags !~ /frtbegin/)
            && ($flags !~ /pathfstart/)
+           && ($flags !~ /flangmain/)
            && ($flags !~ /crt[0-9]/)
            && ($flags !~ /gcc/)
            && ($flags !~ /user32/)
@@ -392,7 +393,7 @@ if ($link ne "") {
 }

 if ($vendor eq "FLANG"){
-    $linker_a .= "-lflang"
+    $linker_a .= "-fno-fortran-main -lflang"
 }

 open(MAKEFILE, ">> $makefile") || die "Can't append $makefile";

Thanks. Putting it all in f_check does not work for me - during the build of openblas_utest the option gets passed to clang, which errors out on unknown arguments. So I guess the "no-fortran-main" bit has to stay in exports/Makefile (with an added ifdef that applies it only to flang)

The pull request above works for me.

Thank you for confirming, and for all your help with this.


hasMany via two relations fails when using through ActiveRecord::find with

I have these relations:
public function getTabInstances()
{
return $this->hasMany(\commonFiles\models\TabInstance::className(), ['related_id'=>'id'])
->with(['tab'])
->where(['related_table'=>static::tableName()]);
}

public function getComponentInstances()
{
return $this->hasMany(\commonFiles\models\ComponentInstance::className(), ['tab_instance_id' => 'id'])
->via('tabInstances')
->with(['component']);
}

public function getItemInstances()
{
return $this->hasMany(\commonFiles\models\ItemInstance::className(), ['tab_instance_id' => 'id'])
->via('tabInstances')
->with(['item'])
->orderBy(['index_number' => SORT_ASC, 'item_count' => SORT_ASC]);
}

Then when trying to acces them via the script below:
$models = \app\models\FilmShoot::find(['is_active' => true])
->with('filmProduction.itemInstances', 'place.translation')
->all();

the count of 'itemInstances' is 0.
When changing the script to lazy loading (removing itemInstances from with and load them in foreach loop) the result is what I expect, not 0.

how do the relations you use in the query relate to the relations you define above? please give more information about the schema and which models relate in which way.

The table tab_instance is linked to film_production through the fields related_table and related_id.
So what I'm trying to get is:
FilmShoot models, with the itemInstances linked to the filmProduction model


Add option for mails to be accessed by all committers

This is intended for archiving mails to which all committers should have access.
e.g. the<EMAIL_ADDRESS>archive

Ping?

This poses a question of who we want accessing the box. Perhaps a topic for the ML. I'd be inclined to think we should only allow ASF members on there, on a per-request basis.

Come to think of it...what is the point of this? non-committers won't have access to the box in any case.

The point is to potentially allow committers to have access to the<EMAIL_ADDRESS>mail archives and any other lists that are open to all committers.

Committers won't have access to mbox-vm.

Seems to me that the requirements for the archiver box need to be agreed on first.

I'm also going to say Im a -1 to this change. mbox-vm itself is not meant to be accessed.

mbox-vm was constructed to provide ASF Members with access to our archives, based on the general precedent of Members having access to the records of the Foundation (caveat of PII types of email).
Committers are subscribed to committers@ and can retain their email. The Foundation will not provide access to mbox-vm to review/recover those emails. In general, access to mbox-vm will be "upon request" rather than "automatic" for Members. It will be the "source of truth" for our email archives, and will (thus) be reasonably tight on permissions/access.


alert user if the EML is invalid

I filled out the forms out-of-order. and forgot to add a contact.
So the EML I downloaded was invalid (contact is required). For a data manager, it's conceivable they would want to download a doc that was in progress.
It doesn't make sense to see this alert all the time, but if the user is downloading the EML, the app could tell them that what they are downloading is not yet valid EML.

Done, via the "Check" feature.


Disable failing ffcv test

What does this PR do?
Disable TestFFCVDataloaders::test_ffcv[gpu-amp] test until we figure out why it started failing.
What issue(s) does this change relate to?
TBD
Before submitting

[x] Have you read the contributor guidelines?

Re-ordering test fixes the error, closing this PR


[Chainsaw Tests] Add Chainsaw tests for the sample policies

Problem Statement
Hi there👋
This is an umbrella issue for adding Chainsaw tests for Kyverno sample policies.
You can find references below to write tests:

Chainsaw doc
Example tests

Start by browsing the following sample policies, and you can pick up a task by:

create a GitHub issue on kyverno/policies repo
comment /assign to get assigned
write your tests
verify tests locally

require a Kubernetes cluster
require installing Chainsaw

create the PR

[ ] https://github.com/kyverno/policies/tree/main/aws/require-aws-node-irsa
[ ] https://github.com/kyverno/policies/tree/main/best-practices/check-deprecated-apis
[ ] refactor https://github.com/kyverno/policies/tree/main/cert-manager/limit-dnsnames
[ ] refactor https://github.com/kyverno/policies/tree/main/cert-manager/limit-duration
[ ] refactor https://github.com/kyverno/policies/tree/main/cert-manager/restrict-issuer
[ ] https://github.com/kyverno/policies/tree/main/cleanup/cleanup-bare-pods
[ ] https://github.com/kyverno/policies/tree/main/cleanup/cleanup-empty-replicasets
[ ] https://github.com/kyverno/policies/tree/main/other/advertise-node-extended-resources
[ ] https://github.com/kyverno/policies/tree/main/other/copy-namespace-labels
[ ] https://github.com/kyverno/policies/tree/main/other/expiration-for-policyexceptions
[ ] https://github.com/kyverno/policies/tree/main/other/namespace-protection
[ ] https://github.com/kyverno/policies/tree/main/other/restrict-edit-for-endpoints
[ ] https://github.com/kyverno/policies/tree/main/other/restrict-scale
[ ] https://github.com/kyverno/policies/tree/main/other/restrict-service-account
[ ] https://github.com/kyverno/policies/tree/main/pod-security/baseline/disallow-proc-mount
[ ] https://github.com/kyverno/policies/tree/main/pod-security/subrule/podsecurity-subrule-baseline
[ ] https://github.com/kyverno/policies/tree/main/pod-security-cel/baseline/disallow-proc-mount

Solution Description
n/a
Example "Good" Resource
No response
Example "Bad" Resource
No response
Other Comments
No response
Slack discussion
No response
Troubleshooting

[X] I have read and followed the documentation AND the troubleshooting guide.
[X] I have verified the policy does not exist in the samples library.

Hei @realshuting, I created a new issue and PR, but were unable to assign myself. Can you do a review?

https://github.com/kyverno/policies/issues/956
https://github.com/kyverno/policies/pull/957

Removed line item to test procMount policy since it can't be tested without a specific feature gate we don't want to enable for all clusters.


Icon gone after logout/reboot

I had no issues with this extension on Ubuntu 20.10. On 21.04 now, the extension still works as expected but only until after I log out or reboot. The icon in the tray is gone but the extension is still listed as installed (marked with "ERROR"). Is there any way I can help to debug this?
Ubuntu 21.04 still comes with GNOME 3.38, but they switched to Wayland. Maybe this is of some interest.

When loading on Wayland on Ubuntu 21.04, the extension tries to get the default GTK theme, however, due to changes in GNOME mutter when using Xwayland, GTK may not be available for extensions at loading time. This behavior is also stated in the following issue in the GNOME mutter repository: https://gitlab.gnome.org/GNOME/mutter/-/issues/960.
I've created a pull request (#9) that fixes this error.

Fixed. Thanks to @fabianthdev


🌐 Add German translation for docs/de/docs/deployment/cloud.md

← deployment/concepts.md (#10744)
→ deployment/server-workers.md (#10747)
German translation progress

📝 Docs preview for commit eaac5decb544e7abbf39a6ce9103685e24662835 at: https://d93c7573.fastapitiangolo.pages.dev

📝 Docs preview for commit 0221cb281d0a509591229ae4fbd66c036d4a5886 at: https://ae382072.fastapitiangolo.pages.dev


CC6180: if statement in C#

@BillWagner,
It seems that if statement in C# should be updated. Could you check this proposed file change, please?
This comes from this contribution: https://github.com/dotnet/docs.fr-fr/pull/32/files.
Many thanks in advance.

I'm not so sure I agree with this proposal. @BillWagner what are your thoughts on this? The statement there is supposed to represent commands you'd run, not to be a program you could actually run.

I agree with @mairaw. I don't think the change helps, and it could cause confusion.
What was the author trying to fix?

I think he was just trying to create a snippet that would compile. But I see that @nokura used that PR to merge master to live, which seems wrong. We should probably revert that change on the localized repo and close this PR.

@BillWagner and @mairaw, thanks for your quick replies.
Closing this PR since it does not apply.


listener: add TLS inspector listener filter.

Adds a listener filter that extracts the servername indicator from a TLS ClientHello, and makes this available to listener matching.
Risk Level: Medium
Testing: Unit tests written
Docs Changes: TODO
Release Notes: TODO

This is another approach to the work started by @PiotrSikora in PR #2949.
I removed the ALPN and version sniffing and TLS vs non-TLS detection,  to keep the scope smaller; we can add those back in a subsequent PR.
I expect this to have much poorer performance, with the tradeoff that the code is simpler and easier to test.
The benchmark includes isn't yet useful, because it spends almost all it's time in gmock object calls; more performant mocks are needed.

Ignoring the possible performance issues, TCP vs TLS (or ALTS, really) detection is needed in Istio, so it's not something that we can skip from this feature.

How reliable does the protocol detection need to be?
On one end of the spectrum, we could look at the first few bytes and see if they look like a TLS record at all, and maybe check that the record type is a ClientHello. On the other end of the spectrum, we could make sure the ClientHello is completely well-formed and standards-compliant.
I think that we could get the latter behavior by looking at whether done() is called with true or false, with this implementation.

Also, I didn't realize istio needed this. I was going by what is currently in FilterChainMatch (https://github.com/envoyproxy/data-plane-api/blob/4b93d3697e788dd2810613289ef83788dfe7da44/envoy/api/v2/listener/listener.proto#L50). We'll need to add to this config for protocol-matching.

On one end of the spectrum, we could look at the first few bytes and see if they look like a TLS record at all, and maybe check that the record type is a ClientHello. On the other end of the spectrum, we could make sure the ClientHello is completely well-formed and standards-compliant.

The checks in the original PR are pretty much the same as BoringSSL would ran on ClientHello, at least for the interesting extensions, so I wouldn't pay too much attention to this, really. Also, we only detect protocol here, and it's going to be consumed and validated by BoringSSL at later stage, so the only advantages of this approach are: support for ClientHello spanning multiple fragments (which isn't happening in the real world, AFAIK), and arguably cleaner code.
The downside is lack of extensibility of this approach, since the current code is limited to SNI detection and adding support for other L4 and L7 protocols is not going to work (i.e. you could also use sniffing to select between filter chains with unencrypted HTTP, REDIS or generic TCP proxy). At the same time, I'm not sure if we should be allowing mixing too many different things on the same port, so maybe that's not a deal breaker.

We'll need to add to this config for protocol-matching.

For TCP vs TLS this can inferred from the presence of tls_context in the filter chain, so no config changes are needed for this.

I'm not 100% sure I'm using the benchmark tools correctly, but here's the result it gave me. Either I used the tool wrong, or this is much faster than I expected it to be.
$ ./bazel-out/k8-opt/bin/test/extensions/filters/listener/tls_inspector/tls_inspector_benchmark
2018-04-13 13:10:22
Run on (24 X 2400 MHz CPU s)
CPU Caches:
  L1 Data 32K (x12)
  L1 Instruction 32K (x12)
  L2 Unified 256K (x12)
  L3 Unified 15360K (x2)
-------------------------------------------------------
Benchmark                Time           CPU Iterations
-------------------------------------------------------
BM_TlsInspector          5 us          5 us     154747

I think we have several options, and some decisions to make.
The biggest one I think is how do we want to do protocol sniffing? My feeling is that each protocol that we want to sniff can be in a separate filter, instead of cramming it all into a single filter.  And I think it will be most common, when doing sniffing, to be looking for a few specific protocols. I imagine it would be more common to look for TLS vs non-TLS, than looking for whether a connection is redis or mongo.
The next question is what to do with TLS and the various fields we'd like to be able to sniff out. I think for things that we can't extract with this API-driven approach, we can use a hybrid and examine specific extensions, similar to https://github.com/envoyproxy/envoy/blob/master/source/common/ssl/context_impl.cc#L617. And hopefully we can add parsing functions to BoringSSL that are made to be called from SSL_early_callback_ctx_extension_get() callbacks for parsing specific extensions. With this approach, we delegate the overall protocol parsing to BoringSSL, and only parse ourselves the pieces we have to. Does that sound like a workable compromise @PiotrSikora?

We'll need to add to this config for protocol-matching.

For TCP vs TLS this can inferred from the presence of tls_context in the filter chain, so no config changes are needed for this.

But that would preclude doing tcp-proxying (non-TLS terminated) of TLS connections; I've heard several requests for this feature. But the configuration should be simple to add.

The biggest one I think is how do we want to do protocol sniffing? My feeling is that each protocol that we want to sniff can be in a separate filter, instead of cramming it all into a single filter.  And I think it will be most common, when doing sniffing, to be looking for a few specific protocols. I imagine it would be more common to look for TLS vs non-TLS, than looking for whether a connection is redis or mongo.

Yeah, I was thinking about splitting this into separate filters, but I haven't decided yet how I feel about mixing too many protocols on the same port, especially since protocols where server speaks first (e.g. MySQL) cannot be sniffed and therefore cannot be mixed with other protocols.

The next question is what to do with TLS and the various fields we'd like to be able to sniff out. I think for things that we can't extract with this API-driven approach, we can use a hybrid and examine specific extensions, similar to https://github.com/envoyproxy/envoy/blob/master/source/common/ssl/context_impl.cc#L617. And hopefully we can add parsing functions to BoringSSL that are made to be called from SSL_early_callback_ctx_extension_get() callbacks for parsing specific extensions. With this approach, we delegate the overall protocol parsing to BoringSSL, and only parse ourselves the pieces we have to. Does that sound like a workable compromise @PiotrSikora?

I've added ALPN for HTTP vs non-HTTP filter chain selection (similarly, I had basic HTTP method and HTTP/2 client preface sniffing in the initial version), but we don't have imminent need for that, so let's not block this PR on other TLS extensions, and let's focus on TLS vs no-TLS and SNI.

But that would preclude doing tcp-proxying (non-TLS terminated) of TLS connections; I've heard several requests for this feature. But the configuration should be simple to add.

It wouldn't - you can specify sni_domains without tls_context and then it's selected non-terminating TLS connection with matching SNI.

It wouldn't - you can specify sni_domains without tls_context and then non-terminating TLS connection with matching SNI should be selected.

Note: the rest of this comment is largely unrelated to the outcome of this PR. I think we'll have check for TLS vs non-TLS either way; just figuring out the right way to configure that.
I think it would be unexpected for something outside FilterChainMatch to affect the matching, so I'm not sure that using the presence of tls_context for this purpose is a good idea.
Also, FilterChainMatch defines many fields, but currently doesn't document whether they will be AND'd or OR'd to find a match. I was assuming AND'd, but I haven't really thought about which makes more sense. If it is AND, and we used the presence of tls_context to indicate that it must be TLS, there would be no way to tcp_proxy TLS without terminating TLS.

I think it would be unexpected for something outside FilterChainMatch to affect the matching, so I'm not sure that using the presence of tls_context for this purpose is a good idea.

I see what you're saying, and that's a valid point.
I guess we could add string transportProtocol to the FilterChainMatch and compare it against detected transport protocol (this would let it work with alternative transport protocols, e.g. ALTS).
However, this would require transportProtocol: TLS (note: we really need to change the well known type from SSL to TLS) to be added to FilterChainMatch of every existing TLS-terminating filter chain, otherwise there won't be a matching chain to use, which makes this a config breaking change. Also, this would require information about termination to be always added in 2 separate places, which isn't the greatest user experience.

Also, FilterChainMatch defines many fields, but currently doesn't document whether they will be AND'd or OR'd to find a match. I was assuming AND'd, but I haven't really thought about which makes more sense. If it is AND, and we used the presence of tls_context to indicate that it must be TLS, there would be no way to tcp_proxy TLS without terminating TLS.

It's "AND if present" right now, and it would stay "AND if present" with the string transportProtocol as well, e.g.
filter_chains:

// http://static.google.com (unencrypted HTTP)
- filter_chain_match:
    transportProtocol: "TCP"
  filters:
  - name: envoy.http_connection_manager
    ...

// https://static.google.com (TLS terminated here)
- filter_chain_match:
    sni_domains: ["static.google.com"]
    transportProtocol: "TLS"
  tls_context:
    ...
  filters:
  - name: envoy.http_connection_manager
    ...

// https://mail.google.com (TLS terminated at the backend)
- filter_chain_match:
    sni_domains: ["mail.google.com"]
    transportProtocol: "TLS"
  filters:
  - name: envoy.tcp_proxy
    ...

On the side-note, this example is really asking to have HTTP Host header available at this stage (in case of unencrypted HTTP traffic) to be able to use it in domains (née sni_domains) for the filter chain matching.
cc @mattklein123 @htuch for API vision, cc @lizan for ALTS sanity check.

I think it would be unexpected for something outside FilterChainMatch to affect the matching, so I'm not sure that using the presence of tls_context for this purpose is a good idea.

+1, do not use tls_context for this purpose, you might have other implementations that does TLS with custom transport socket.
Adding a  string transportProtocol sounds reasonable, if we would like to add this one, make sure you add similar concept to TransportSocket interface, so we can validate whether the transportProtocol in FilterChainMatch can be handled by the transport socket.

What if instead of a single string transport_protocol we did something more generic like:
repeated string transport_tags

(Or pick some better name). The idea is that filters can set tags as they iterate which can then be matched by the filter chain matching system. E.g., a Redis sniffer could look for redis and then set a "REDIS" tag, similar for Mongo, TLS sniffer can sniff for that, etc. I think this would be a general approach that would work for all protocol sniffing.
My only general concern with this is what if someone wants to terminate TLS and then do protocol sniffing? That won't work at all here with any of the solution we have discussed. I'm not sure if this is a real use case but should we consider it?

@mattklein123 I'd prefer to avoid mixing transport protocols with application protocols, since those are fundamentally different things, and it's "impossible" to run application protocol sniffers without selecting transport protocol that allows you to read payload first.
For application protocols, there are 4 cases to take into consideration:

Unencrypted bytestream (TCP) - we can sniff application protocol right away,
Encrypted  bytestream (non-TCP) terminated at the proxy - we can sniff application protocol after narrowing down list of possible filter chains to a specific transport protocol and decrypting bytestream, or we can infer it from ALPN or equivalent (see below),
Encrypted bytestream (non-TCP) not terminated at the proxy - we can infer application protocol from ALPN or equivalent (this should work fine within single organization, where you can force clients to set ALPN, but it won't work at scale with random traffic from the Internet),
Unencrypted bytestream (TCP), where server sends first packet - we cannot sniff application protocol.

Ultimately, I think routing based on the application protocol is useful feature (hence ALPN in the original PR), but sniffers need to run after transport protocol is selected, and I think that we could do it in another PR in order to move this one forward.

Ultimately, I think routing based on the application protocol is useful feature (hence ALPN in the original PR), but sniffers need to run after transport protocol is selected, and I think that we could do it in another PR in order to move this one forward.

@PiotrSikora I think that's reasonable and agreed we can move this forward, however I think we should spend just a little time figuring out how application sniffing will work since I know we will need it. I guess we will need a different set of filters vs. listener filters? Something like "pre-filter chain match," "pre-connection," etc.? And those filters could potentially set tags that filter chain match can match on? cc @ggreenway

Yes that's fine with me to proceed with this PR. I agree that the general direction will allow us to do application sniffing later.

@ggreenway @PiotrSikora does this mean we should close https://github.com/envoyproxy/envoy/pull/2949?

@alyssawilk I'm waiting on integration tests until the next PR from @PiotrSikora. This PR doesn't actually do anything, ie nothing consumes the data it produces.

@PiotrSikora The easy stuff you raised is done. I'm reading the commits you linked, and I'll sort out the changes needed in this PR. Thanks for breaking it into 4 parts for readability.

@PiotrSikora I added back the detected transport code. PTAL.


WIP: feat(router): run middleware layer prior to routing

A middleware I'm using basically defines an action at the Node level.  In order for the middleware to work, I need to add an additional action to my routes.js file that I never actually intend to use.
Do we want to re-jigger our approach here so middleware run prior to route handling?  I'd be inclined to do that and then have routing fail if no routes were found after that.

I'm cautious about this for a couple reasons:

The idea of having a middleware that acts as a route handler runs counter to Denali's architecture. Middleware should run before all requests, and can preempt them if necessary, but shouldn't replace the routes. A core premise of Denali is that middleware is a weak primitive to build robust apps on. Allowing middleware to do what Actions should feels like a potential footgun.
What you are trying to accomplish (taking existing middleware based code and porting to denali) could potentially be handled at the action layer with relative ease - we could even theoretically release a MiddlewareAction addon that exposes an Action class that mimics the express middleware interface.

That said, after thinking through it a bit more, running middleware prior to routing would be good for a couple reasons:

It mimics Express and existing patterns more closely. If you do app.use(middlewareFunction) in Express, that function will run even if it 404s when it hits the router.
It allows for things like logging 404s, rate limiting, etc.

So overall, I'm 👍 on running middleware before routing, but I'd encourage us to find ways (through documentation, our own open source apps, and via Denali itself) to nudge users away from handling routing at the middleware layer.

Here's a hypothetical implementation of that MiddlewareAction class:
class MiddlewareAction extends Action {
  middleware = null; // subclasses would override this with their middleware fn
  respond() {
    return new Promise((resolve, reject) => {
      let buffer = '';
      let response = new stream.Passthrough();
      response.on('data', (d) => buffer += d);
      response.on('end', () => resolve(buffer));
      this.middleware(this.request, response);
    });
  }
}

This isn't enough, obviously - response would need to provide the additional APIs that the express response object does, on top of implementing the stream interface. But hopefully this get's the point across.

I think this just needs the one change mentioned in review (pass the instantiated Request object into the middleware rather than the raw IncomingMessage object that the router get handed), and we should be good to go.
Tests would be awesome too, but I know that's a pain right now - at least some pending tests as placeholders would be good.

Closing in favor of #189 (which is literally just this branch plus the feedback and a test)


Export YOLOV8 models from Keras to onnx

Hello everyone!
I’ve trying to export yolov8 models to other frameworks, to onnx and to tflite. I got some point in exporting to onnx but now model has very bad ocurasy.
If I try to convert it just by tf2onnx it gives me error about YOLOV8Detection layer.

Hi @AleksNet5 -
Thanks for reporting the issue.

If I try to convert it just by tf2onnx it gives me error about YOLOV8Detection layer.

Can you help me with sample code for model creation or if possible share sample model and also error traceback to dig this issue more ?

Hello!
Sorry for delay, I have successfully converted model to onnx but it works correctly only with preprocessing with TF and imageio.v3 using:
Read by imageio
Resize_with_padding with tf
Add batch dimension with tf
Otherwise if I use code from YOLOV8 outputs decoding function I got zero results

Hi @mehtamansi29!
I think that it is core question, bc I now trying to make it work with decoding that I copied from YOLOV8 decoding functions, and with depthai. And I get zero outputs, even though I tested it in onnx and it suppose to work the same in their framework
The only thing is input parameters, I need to specify mean, scale values and channels order(rgb or bgr) for the NN input

Hi @AleksNet5 -
Sorry for the delay. Here you can export the Yolov8 models from other frameworks to onnx or tflite :
from ultralytics import YOLO
model = YOLO("yolov8n.pt")
#export yolo model to onnx
model.export(format="onnx", dynamic=True,  opset=13)
# export model to tflite
model.export(format="tflite")

Attached gist here fro reference.


Use icons instead of just colors for comment types

Currently the teacher selects a color for her comment. However, this is inconsistent with the rest of the platform. We should use ticks, warnings, etc form font awesome instead.

Agree. Moreover, current approach isn't color-blind friendly.

After the introduction of messages in classroom, comment and comment types have been removed.


Proposal for re-enabled CSP rules with a CSP-rule template

and also with a pre-processor, if this is wanted.
Removed Bugsnag, because this is deprecated now and replaced by Google Stackdriver.
Fix for issue #8

Hello @phorward,
I think that it's important to reduce the amount of example to beware an information overload and hold the base compact as possible.
I created a Wiki Page for the CSP rules with your examples. I think this is a more suitable way to provide examples and documentations. Maybe you would like to take a look on it ;)

Hello @sveneberth,
this is ok for me. I'm doing the same with the preprocessor. But I think its better to put this in the server wiki rather than the base wiki. I will update this PR soon so that CSP rules are generally enabled.

I've just updated the pull request and put the requestPreprocessor into its own wiki page at the server.
Can you please to either with your CSP page?


Scroll BubbleCalendar year chart horizontally and tooltips vertically

This pull request fixes #214 and #328 .

Add a horizontal scrollbar to BubbleCalendar year chart to avoid exceeding window width in the future.

Make BubbleCalendar tooltips scrollable to avoid exceeding window height when a specific day contains too many snapshots.

I merged changes done in issue #214 (PR #317) into this PR. I expect this branch 'scrollbars' will handle all scroll-related issues.

@MohammedElsayyed It doesn't appear to be part of this pull request, but it looks to me (and I'm unfamiliar w/ the code) that there's no header included in BubbleCalendar.jsp. Shouldn't there be something like this before L17?
<jsp:include page="/WEB-INF/template/UI-header.jsp" flush="true" />

@runderwood, it is problematic that we aren't including UI-header.jsp. I will open an issue to discuss this as I think handling it properly will require more than just an include of the existing header.
I also noticed that in BubbleCalendar.jsp the submit button value is hardcoded to "Go Wayback!", but to support localization we should probably be using:
value="<%= fmt.format("UIGlobal.urlSearchButton") %>"
What do you think about changing that @MohammedElsayyed ?

@runderwood I agree with @ldko. Thank you for opening this issue.
@ldko of course, I will update the pull request.


remove legacy kubeflow operator docs

This PR removes the "kubeflow operator" docs from the website as part of https://github.com/kubeflow/website/issues/3074
However, even separate from https://github.com/kubeflow/website/issues/3074, it also reflects the reality that this is no longer a supported method of installing Kubeflow (the latest supported version is Kubeflow 1.2, from all the way back in November 2020.

@jbottum @zijianjoy @james-jwu I think this is important to remove from the website.
I am trying to close out https://github.com/kubeflow/website/issues/3074 to make the website actually clear about how to get Kubeflow installed (especially with all the new eyes about to look after the CNCF adoption).

@zijianjoy can you also approve this one, because having these old docs for an unsupported distribution really sends a bad message.

@zijianjoy also, can we please archive the kubeflow/kfctl repo, see https://github.com/kubeflow/kfctl/issues/501#issuecomment-1644871752 for more information.

LGTM

@zijianjoy this is now the last remaining section of distribution docs on the website.
As the "kubeflow operator" is no longer maintained, and is incredibly out of date (it has not been updated since Kubeflow 1.2), I think we can safely merge this PR!
PS: once we merge this, I will raise a final PR to remove and redirect the old /distribution/ docs to the "installing kubeflow" page, so we can close https://github.com/kubeflow/website/issues/3074.

@animeshsingh @Tomcli Please comment on this PR to remove the legacy kubeflow operator docs. Since we have stopped development/maintenance to this project, can we remove the documentation?

Yes this document is safe to remove.
/lgtm


Languages alphabetically sorted in settings drop down menu

Hooray Jenkins reported success with all tests good!

Tested and works fine! :-)
Could you run Checkstyle real quick? I see a * import got added, which is against our style guide. That's all that sticks out to me before merging.

Hooray Jenkins reported success with all tests good!

@Cervator Thank for the tip. I have changed the import style so the changes may be merged. Are there any other issues similar which may need to be addressed? I was thinking about https://github.com/MovingBlocks/TerasologyLauncher/issues/292.

This PR is looking good now, I'm happy to merge it, although a stray TerasologyLauncher file appears to have been added, is that an IDE related file of some sort we are lacking from the .gitignore ?
#292 would be a good change to attack yep. Or feel free to grab anything from the main project, really anything that interests you :-)

Hooray Jenkins reported success with all tests good!

Somehow I had a copy of the TerasologyLauncher within the TerasologyLauncher project. I removed it, and all is synced right now. I might take a look at #292, but i'm also going to look into the main project. I shall keep you informed :')

Thanks! Merged :-)
One thing you could also do is apply this sorting to the language list in the main game - I just checked and it doesn't look sorted at all :D Probably similar code, if not identical.
Submitted https://github.com/MovingBlocks/Terasology/issues/2350 for the request, feel free if interested :-)
Any other work anywhere would of course also naturally be appreciated!


Suggestion: Show stats near player portraits

I was thinking.. Instead of making a table in the middle, could you show the stats near the actual player portraits? I think it'll be quicker to get an overview that thrall is the one with low mmr. Or maybe a setting for display-style to let users choose between current and this method.

Hey, so I just started using your tool and I find that it's pretty sweet but the only downside to it is the time the window stays open. Is there a way to increase this time?

It is possible but currently app don't detect parties. Because parties are sorted to be on top on loading screen it may result in wrong player order. It is possible to extract parties data from lobby file but the only thing I know currently is when player is in party his data structure contains more bytes. I didn't find any signature to know for sure that player is party. Byte count still can be used to guess parties but it is obviously very unreliable.

I have forked the project, and I am working on implementing some OCR which would give us all the required information for this.
I've written some code to remove any pixels from the picture that isn't text. That makes the OCR results much better. Here is your screenshot after this process: http://imgur.com/duVON2X
The only mistake I am getting with the OCR on this picture, is that it thinks red team Greymane is called Re41ity, when in fact it's an l, and not a 1. I think it should be possible to code my way out of matching it anyway.

Or just use fuzzy matching against battletag list and hero list


Wrong namespace in ExternalController

Issue / Steps to reproduce the problem
The sample file

IdentityServer4/samples/Quickstarts/5_HybridFlowAuthenticationWithApiAccess/src/IdentityServer/Quickstart/Account/ExternalController.cs

has a wrong namespace.
It is currently Host.Quickstart.Account but should be IdentityServer.
Using the namespace name Host.Quickstart.Account causes problems when converting the project to ASP.NET Core 3.0.
Please fix the namespace name.

We will update the docs/quickstarts soon.


Search through transcript

Great plugin! I really think there's plenty of utility for a plugin like this. One feature that I would love to see implemented would be a search bar at the top. It could filter through the quote blocks and just show the matching ones.

Thank you very much for warm words. This is great idea. As soon as I will be back to work I'll try to add it

Great Plugin!
I second j-maffe feature request.

@lstrzepek I could add this if you would like. In order to do this, I would recommend using some type of reactive framework. Svelte or React would work well.

Thanks again @trey-wallis for contribution!
I'm curious about your feedback.
@trey-wallis About title and modal I think we can create discussion (sorry for removing it from release).
About title I think we should resign from external lib to fetch transcript and include this code into plugin. Thanks to that we can fetch more metadata (including title) from YouTube in one go. Maybe we can extend markup to include title when pasting link into obsidian...

@lstrzepek You're welcome. I really enjoy the plugin. I think including the title as part of the external library code was a good idea. That way only 1 request is made.


dp-change everytime i restart so i try to bind workstations 1,2,3 to monitor 1 not working

At work below
monitor=desc:BOE 0x0868, disable
monitor=desc:HP Inc. HP E243i CNK01418XX, 1920x1200@60, 0x0, 1,
monitor=desc:HP Inc. HP E243i CNK01418XX, transform,1
monitor=desc:Philips Consumer Electronics Company PHL 346P1C UK02251005830, 3440x1440@60, 1200x0, 1
workspace=monitor:desc:HP Inc. HP E243i CNK01418X,1,rounding:false,bordersize:0
workspace=monitor:desc:HP Inc. HP E243i CNK01418X,2
workspace=monitor:desc:HP Inc. HP E243i CNK01418X,3
Every time i restart my laptop connected to my docking station i get different dp numbers like before it was dp-1 and dp-2, after restart i get dp-3 and dp-4 and so own
So i decided to use monitor:desc: to bind the workspace to the monitors but it does not work only when i use DP-numbers
How can i do to fix this problem to be able to bind the workspaces to a monitor if the dp number change?
or maybe if i can request a feature to be able to add base on monitor desc name?
thank you in advance

I have the same kind of problem.  The issue is that you cannot assign a custom ID or so by matching a monitor description. If that were possible you could use the assigned ID in other rules. Maybe that would be a nice feature request?
My workaround for this is to run this bash script manually:
# puts workspaces on alternating monitors
# if you have two monitors:
#  m1: 1 3 5 7 9
#  m2: 2 4 6 8 10
# if you have three:
#  m1: 1 4 7 10
#  m2: 2 5 8
#  m3: 3 6 9
arrange_workspaces() {
    mapfile -t monitors < <( hyprctl monitors -j | jq -r '.[].name' )
    for ((ws = 1; ws <= 10; ws++)); do
        monitor="${monitors[(ws - 1) % ${#monitors[@]}]}"
        hyprctl dispatch moveworkspacetomonitor "${ws}" "${monitor}" > /dev/null
        hyprctl keyword workspace "${ws},monitor:${monitor}" > /dev/null
    done
}

Not really convenient, but does what I want.

you can now use monitor:desc: inside workspace rules on v0.27
should also be added in the wiki


Publish Test Results from GH Actions

Self-titled.
Since we are moving off of AzDO Pipelines, we will want to ensure our test results are published as part of the build process.

Hi there, I took the liberty to work on this. Thanks in advance for the review. This could certainly be improved but I'm not sure about what level you expect. :)


fix the problem of docker script which failed to run

i will not approve this because dockerfile is working as is

Hi @serengil,
I can't run the script like this either. The path and image name are not correct. @yangsijie666 has corrected the errors.
For example:
Dockerfile
If you run the script dockerize.sh in the folder "scripts", the "Dockerfile" is needed to be in the same folder, because you run "docker build". But this file is in the root folder.
https://github.com/serengil/deepface/pull/879/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R298
Image-Name
The second issue is the image name. You tagged the image with the name "deepface_image", but you call it in the run command with "deepface".
For example wrong image name: https://github.com/serengil/deepface/pull/879/files#diff-38464d794cfc7bae2c6d50ec0e067c6c749f3ab7a1961827d1d34b5c49e26631R11

@Vmadmax add the following line at the beginning of the script then
cd ..

@Vmadmax
Updating sh now


Remove can panic under heavy deletion

After long bug-hunting with the benchmarks, I discovered there is a bug in IAVLTree.Remove(), at least on the develop branch. If called enough with existing keys, and Save() called in between, it can leave to a SanityPanic.
There is only one Tree, no old Copy()s.  And only handled sequentially in a loop.
A trivial case doesn't seem to fail, so I am not sure where there error is...

You have code to reproduce?

Oh I see: https://github.com/tendermint/go-merkle/pull/10

@ebuchman see #10 (in particular: https://github.com/tendermint/go-merkle/pull/10/commits/3203bc089b9e5e3710550b700c76e4b0f1d52811)

Okay, I am playing around today with isolating the commit, mainly jumping around the history and using git cherry-pick 3203bc0
Report:
develop (8bbe696) - go test . passes.  panics after cherry-pick
master (05042c6) - go test . passes. cherry-picked test also passes
tree-saver (3624668) - go test . complains about missing go-autofile dependency.
upon installing github.com/tendermint/go-autofile I discover that neither the master not develop branch compiles
In fact, every commit between develop and master has the same error about go-autofile, not even running :(

Okay... so... all commits between 05042c6..8bbe696 import go-autofile, which seems to be a short-lived branch that redefines AutoFile from go-common. When I checkout the develop branch of go-common, I can get these tests to run.
Sorry if I come off a bit pushy, but the organization of the tendermint repo seems to work welll when there are one or two people working, focused on only one area at a time.  With more developers, these dependency management becomes more of a headache (I have had this in every job).  In order to make it easier for multiple people to collaborate on the repos, maybe we can start making a list of coding guidelines.  Here are my first two suggestions:

Make all dependencies explicit, especially when you depend on the develop branch of numerous other repos, maybe using glide (or another suggestion)

import . "github.com/tendermint/go-common" is an anti-pattern, please avoid.  Just making it import cmn "github.com/tendermint/go-common" requires like 4 more characters when using the functions, but makes the code much more clear and avoids naming conflicts like in go-autofile.

This is not the first time these two issues have bit me. And not just in tendermint.

Bisect results (after fixing go-autofile issue)
* 8bbe696 (upstream/develop, origin/develop, develop) Remove WAL; Use Batching
* 6d0a664 Merge https://github.com/tendermint/go-merkle/pull/1
*   bfc4afe Merge pull request #3 from tendermint/tree_saver
|\
| * 3624668 (upstream/tree_saver) Use new Group semantics
| * 057319c First integration w/ WAL.  Need to test and prune old files
| * a84efae (HEAD) RemoveNode() & track orphans
| * f5f1b05 Initial commit of WAL
| * 2f295d8 Add WAL
|/
* 05042c6 (upstream/master, upstream/HEAD) use less append

2f295d8: go test . fails  - compile error
f5f1b05: go test . fails  - compile error
a84efae: go test . fails  - compile error
057319c: go test . fails  - compile error
3624668: go test . passes.  after applying the test, add adjusting it to the wal syntax, it also crashes
I wonder if the changes on develop are that important, and maybe better to go back to master? I also wonder about the whole persistence design. Well, at least the release go-merkle code is bug-free 😄

This should be fixed now in develop.
https://github.com/tendermint/go-merkle/commit/a74ffd5ba75ae1b453b5b1027489f92266a54958
Inner nodes were being modified, violating immutability.  Well, in "with-DB" mode the nodes aren't exactly immutable (we prune children on each .Save()), but at least the node's hash is invariant, and we maintain the .persisted flag as necessary.  The bug here is that we completely modify the contents of the inner node (which we shouldn't do) AND we do so without clearing the hash or the .persisted flag.  I believe I introduced this by accident when experimenting w/ optimizations.

Looks good to me.  I closed the pull request, since you already merged the fix into develop.


Ignore another sks-dump test failure

If the submodule hasn't been cloned, then test_many_parsers will also fail, so ignore this failing test like the other ones that depend on the sks dump.

thanks


Runtime::init is broken if called multiple times

For example,
fn call_first() {
  let r1 = Runtime::init();
  ...
}
fn call_snd() {
  let r2 = Runtime::init();
  ...
}
pub fn main() {
  call_first();
  call_snd();
}

Currently, the second call will be unable to use the OCaml runtime, because it has been shutdown at the end of the first call.
It seems caml_startup and caml_shutdown already handle this correctly: startup increments a counter, shutdown decrements it, and the runtime is only started or stopped when that counter is 0. Removing the std::sync::Once in Runtime::init_persistent would restore this built-in behaviour, which seems to be strictly an improvement and fix this issue.

@mrmr1993 that is correct, but it is exactly the behavior you get from caml_startup and caml_shutdown from the OCaml runtime, and I don't think there is a good way to fix it. BUT an improvement here would be to track that a shutdown has happened and panic if init is called again.
See here at the end of the section:
Once a runtime is unloaded, it cannot be started up again without reloading the shared library and reinitializing its static data. Therefore, at the moment, the facility is only useful for building reloadable shared libraries.

I am even thinking that there is no need to track shutdowns, calling init more than once is just an error here, because you shouldn't ever have more than one owned instance of the runtime handle. So any call to init() after the first should panic.

I guess it should better return a Result instead of triggering a panic to let the caller decide what to do. It is an api-breaking change so probably good to leave that to the split if things end being done that way.


Fix covid19za_provincial_cumulative_timeline_deaths.csv incorrect data for 13/05/2020

The Northern Cape and North West data has been swopped incorrectly as can be seen in the twitter source as well as this https://www.nicd.ac.za/covid-19-update-56/.

Thanks for picking this up @chadwpetersen

No problemo @dmackie :)


Map data in Kommunalwahlen 2020 don't load on page load

Steps to reproduce:

Go to https://vaterstetten-in-zahlen.de/?tab=kommunalwahl2020 (directly or via an in-app link)
See this result:

See these console errors:

Changing any dropdown loads the map data as expected, also changing it back to the default value works.

Finally had some time to fix this. It seemed to be a kind of timing problem / race condition, since the map is not initialized with render() when the print function tries to find the map by its id and update its layers.


Gugu72: Watch ruggedtablets.com

Gugu72 requests the watch of the watch_keyword ruggedtablets\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

ruggedtablets\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by cigien in Charcoal HQ


⚠ Bofrost.es has degraded performance

In 8507bda, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1586 ms

Resolved: Bofrost.es performance has improved in 70c5e2b after 13 minutes.


Florin/fix init data types

Description
Fixes the tests in the TestInitDataTypes class
Backend/s tested
Mark the backends affected by this PR.

[X] OpenCL
[X] PTX
[X] SPIRV

OS tested
Mark the OS where this PR is tested.

[X] Linux
[ ] OSx
[ ] Windows

Did you check on FPGAs?
If it is applicable, check your changes on FPGAs.

[ ] Yes
[X] No

How to test the new patch?
Run the tests, including the TestInitDataTypes
tornado-test -V uk.ac.manchester.tornado.unittests.api.TestInitDataTypes

@jjfumero this is ready for review

Port works with SPIR-V and PTX. I will push the branch into the public TornadoVM and then you can reopen the PR in the main repo.
Thanks @gigiblender


Add missing dist:onDemand line to template

This line is needed for some modules.

This is on hold. dist:onDemand may be legacy

Closing, onDist was deprecated, Gallery gradle update is fix instead.


Add Workflows to update version and create version tags

Closes: https://github.com/chainguard-dev/bincapz/issues/251
This PR adds two Workflows:

One will create version update PRs via a workflow_dispatch (i.e., manually for now)
One will create tags when commits are pushed to main (only if they do not exist)

In practice, the version update PRs will be merged with an updated version string which will then cause the tag Workflow to create a new tag matching that version.
Every other commit to main will result in the tag Workflow exiting without pushing any new tags since the current version's tag will already exist.

I plan on testing the PR creation at least. If that looks good, we can do real patch PR -> merge -> tag test.


[WFCORE-4875] Provide common capability for Remoting connectors.

This PR allows Remoting subsystem connector elements to be referenced by a common capability reference.
For details, see: https://issues.redhat.com/browse/WFCORE-4875

Don't forget to indicate that CONNECTOR_CAPABILITY allows multiple registrations via RuntimeCapability.Builder.setAllowMultipleRegistrations(true).

Done.

@rachmatowicz thanks


adding stylus plugins in play.config.js

Hi, I have a bit of a problem with configuring play.config.js
I would like to use stylus on templates, with 2 plugins (nib and rupture). The plugins is where it fails. in my normal webpack.base.conf.js I just require the modules for nib and rupture, and then add the following to module.exports:
	stylus: {
		use: [nib(), rupture()]
	},

But this doesn't seem to work when I add it to play.config.js. I get the build error:
ERROR in ./~/css-loader?sourceMap!./~/vue-loader/lib/style-rewriter.js?id=data-v-b4c98aaa&scoped=true!./~/stylus-loader!./~/vue-loader/lib/selector.js?type=styles&index=0!./src/components/Hello.vue
Module build failed: Error: /Users/franz/Sites/vue-play-app/src/assets/styles/component.styl:1:9
   1| @import 'nib'
--------------^
   2| @import 'rupture'
   3| @import 'imports/mixins'
   4| @import 'imports/variables'

failed to locate @import file nib.styl

So: Is there a way to add plugins to stylus, when compiling with vue-play?
Thanks!

Can you provide your webpack.base.conf.js for me to repro?
If you're using custom webpack config, alternatively you can drop vue-play-cli and use webpack-dev-server or custom server script.

My webpack.base.conf.js looks like this.
var path = require('path')
var config = require('../config')
var utils = require('./utils')
var nib = require('nib')
var rupture = require('rupture')
var projectRoot = path.resolve(__dirname, '../')

var env = process.env.NODE_ENV
// check env & config/index.js to decide weither to enable CSS Sourcemaps for the
// various preprocessor loaders added to vue-loader at the end of this file
var cssSourceMapDev = (env === 'development' && config.dev.cssSourceMap)
var cssSourceMapProd = (env === 'production' && config.build.productionSourceMap)
var useCssSourceMap = cssSourceMapDev || cssSourceMapProd

module.exports = {
	entry: {
		app: ['./src/main.js', 'vue-play/dist/vue-play.css']
	},
	output: {
		path: config.build.assetsRoot,
		publicPath: process.env.NODE_ENV === 'production' ? config.build.assetsPublicPath : config.dev.assetsPublicPath,
		filename: '[name].js'
	},
	resolve: {
		extensions: ['', '.js', '.vue'],
		fallback: [path.join(__dirname, '../node_modules')],
		alias: {
			'vue$': 'vue/dist/vue',
			'src': path.resolve(__dirname, '../src'),
			'assets': path.resolve(__dirname, '../src/assets'),
			'components': path.resolve(__dirname, '../src/components')
		}
	},
	resolveLoader: {
		fallback: [path.join(__dirname, '../node_modules')]
	},
	module: {
		preLoaders: [
			{
				test: /\.vue$/,
				loader: 'eslint',
				include: projectRoot,
				exclude: /node_modules/
			},
			{
				test: /\.js$/,
				loader: 'eslint',
				include: projectRoot,
				exclude: /node_modules/
			}
		],
		loaders: [
			{
				test: /\.vue$/,
				loader: 'vue'
			},
			{
				test: /\.cvue$/,
				loader: 'vue'
			},
			{
				test: /\.js$/,
				loader: 'babel',
				include: projectRoot,
				exclude: /node_modules/
			},
			{
				test: /\.json$/,
				loader: 'json'
			},
			{
				test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
				loader: 'url',
				query: {
					limit: 10000,
					name: utils.assetsPath('img/[name].[hash:7].[ext]')
				}
			},
			{
				test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
				loader: 'url',
				query: {
					limit: 10000,
					name: utils.assetsPath('fonts/[name].[hash:7].[ext]')
				}
			}
		]
	},
	eslint: {
		formatter: require('eslint-friendly-formatter')
	},
	vue: {
		loaders: utils.cssLoaders({ sourceMap: useCssSourceMap }),
		postcss: [
			require('autoprefixer')({
				browsers: ['last 2 versions']
			}),
			require('lost')
		]
	},
	stylus: {
		use: [nib(), rupture()]
	},
}

I was trying to add it like so to the play.config.js, which i put in the root of my project.
var nib = require('nib')
var rupture = require('rupture')

module.exports = {
	// all the cli options can be defined here and:
	browsers: [], // autoprefixer browsers
	babel: {}, // override babel options
	postcss: [
		require('autoprefixer')({
			browsers: ['last 2 versions']
		}),
		require('lost')
	]
	loaders: [], // append to current loaders
	stylus: {
		use: [nib(), rupture()]
	},
}

Needless to say, I am very far from being a webpack expert. Any help greatly appreciated here!

Any luck with webpack --config webpack.base.conf.js ?

Not quite, this command launches the server without errors: vue-play --webpack-config build/webpack.base.conf.js. But it serves a blank page.
When I do vue-play with default settings and without loading stylus plugins, it renders just fine.

If you have time for this and want to check it out, I can post a repo with the project.

@jfcieslak sure, please do

OK, here it is: https://github.com/jfcieslak/vue-play-app

Okay, so here's the issue.
@jfcieslak you're providing stylus configuration via this config.
@egoist we don't support top level arguments. We'd need an expansion argument around here.
We'll need to add an extra key like moduleConfig and have it appended to the webpack options.

Got it. Actually, what is the main webpack config file that vue-play uses? I am using vue-play within the project scaffolded with official cli, which I assume is going to be a typical case. So perhaps there could be a more straightforward way of using the the standard build/webpack.dev.conf.js as a main config? Anyway thanks for looking into this!

@jfcieslak check out https://github.com/vue-play/vue-play-cli/blob/master/lib/make-config.js#L105
The only thing that differs from a typical vue-webpack project is it adds vue-play/dist/vue-play.css to entry and a markdown filer loader (which you may rarely use).

@jfcieslak does that solution work for you? If so we can likely just close this issue. @egoist we probably need to add some explicit documentation around this.

This does explain how webpack config is extended by vue-play, maybe few words in the docs about it would do some good. Thanks!

As version 1.0 was just released, now vue-play is to focus on being a framework for demonstrating, leaving the other things to your own bundler setup (vue-play-cli is deprecated). If you are already using the official webpack template, you can almost use the same config but with a different entry to bundle the app.
However if you want a shorthand for bundling play app, use vbuild, I believe it can bundle your components too.

OK, cool! will give it a try


Disabling AA for UT99

Game
Unreal Tournament: Game of the Year Edition
Engine
Unreal Engine 1
Linux Distribution
Mint 21
Luxtorpeda Version
63
Bug description
UT99 v469c shows unintended wireframes for invisible objects when AA is active.
Steps To Reproduce

Run UT99 with v469c patch.
Fire a gun causes lightning such as Shock Rifle into a wall.
Observe wireframes from the impact.

Expected Behavior
No wireframes for invisible objects.
Additional Context
https://github.com/luxtorpeda-dev/packages/issues/922#issuecomment-1566215742
UnrealTournament.ini within System64 should be edited like the following. It is not possible to disable AA withing in-game settings.
[OpenGLDrv.OpenGLRenderDevice]
UseAA=False
[XOpenGLDrv.XOpenGLRenderDevice]
UseAA=False
Relevant log output
No response

It looks like this is fixed in newer mesa versions, so this should be fine to keep enabled: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7537
You can disable it locally if you need to.


Edit schedule

Codecov Report

Merging #107 (2494a29) into master (4ca1351) will decrease coverage by 0.06%.
The diff coverage is 35.48%.

@@             Coverage Diff              @@
##             master     #107      +/-   ##
============================================
- Coverage     60.22%   60.16%   -0.07%
- Complexity      558      581      +23
============================================
  Files           110      112       +2
  Lines          2117     2229     +112
  Branches        244      258      +14
============================================
+ Hits           1275     1341      +66
- Misses          767      811      +44
- Partials         75       77       +2

Impacted Files
Coverage Δ

...address/logic/parser/AddScheduleCommandParser.java
0.00% <0.00%> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
66.66% <0.00%> (-2.90%)
:arrow_down:

...ddress/logic/parser/EditScheduleCommandParser.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)

src/main/java/seedu/address/model/AddressBook.java
79.10% <12.50%> (+19.10%)
:arrow_up:

.../seedu/address/model/module/schedule/Schedule.java
44.89% <12.50%> (+0.16%)
:arrow_up:

...rc/main/java/seedu/address/model/ModelManager.java
73.75% <25.00%> (+4.12%)
:arrow_up:

...du/address/logic/commands/EditScheduleCommand.java
57.57% <57.57%> (ø)

...edu/address/logic/commands/AddScheduleCommand.java
100.00% <100.00%> (ø)

...a/seedu/address/model/module/UniqueModuleList.java
94.11% <0.00%> (+1.96%)
:arrow_up:

... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


SILGen: Caller-side codegen for invoking foreign async functions

Immediately before invoking the ObjC API, get the current continuation, capture it into a block to
pass as the completion handler, and then await the continuation, whose resume/error successors
serve as the semantic return/throw result of the call. This should complete the caller-side part
of SILGen; the completion handler block implementation is however still only a stub.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 39ae951619b44049692813ea18407e39cd981a37

Build failed
Swift Test Linux Platform
Git Sha - 39ae951619b44049692813ea18407e39cd981a37

@swift-ci Please smoke test

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 7addae24396abe87d67c882a8b0df707fa6d3b6f

Build failed
Swift Test OS X Platform
Git Sha - 7addae24396abe87d67c882a8b0df707fa6d3b6f

@swift-ci Please test

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 368dc0f4016c178d2d47904abd6ad2bb72ae8757

@swift-ci Please test Linux


eebus lets evcc crash on docker

Describe the bug
Trying to get eebus up and running on a evcc running on docker on a synology NAS (DS416play).
When adding eebus to the yaml config I get the following error:

[main  ] FATAL 2024/12/03 14:09:12 failed configuring eebus: could not get machineid: open /etc/machine-id: no such file or directory; for manual configuration use plant: caf5c742810cf7bda8e093d2787c9c88b16762700a9b8125ad8807f60bcdcf85

Adding file machine-id file to the file mapping and adding the suggested machine-id.
Now evcc will start, however the webconfig never becomes accessible and the docker will reboot after 15 minutes going into an infinite loop.
Adding plant: to the yaml creates the same problem.
Steps to reproduce

add eebus to yaml
add plant: for the machine-id

Configuration details
#plant: fd2371f0ba8725a310c23f7e8e708afa77461493ac9b9794ae67f82da7bc4d9f
site:
  - title: Blaricum # display name for UI
    meters:
      grid: my_grid # grid meter reference
    residualPower: 100
tariffs:
  grid:
    type: template
    template: tibber
    token: removed
    homeid: removed
loadpoints:
  - title: Oprit # display name for UI
    charger: my_charger # charger reference
    vehicle: BMW # reference to standard vehicle
    mode: minpv # charge mode (off, now, minpv, pv)
vehicles:
  - name: BMW
    type: template
    template: bmw
    title: X5
    user: removed # User account (e.g. email address, user id, etc.)
    password: remvoed # Password of the user account (use single quotes in case of leading zeros)
    capacity: 26 # Battery capacity in kWh (optional)
    hcaptcha: [hcaptcha]
meters:
  - name: Enphase
    type: template
    template: enphase
    usage: pv
    host: <IP_ADDRESS> # IP address or hostname
    token: [token]
eebus:
  shipid: EVB-510-061-355
  certificate:
    public: |
      -----BEGIN CERTIFICATE-----
      MIIBvTCCAWOgAwIBAgIRAcyYJVawVRQ+VsR8DLaj9qkwCgYIKoZIzj0EAwIwPjEL
      MAkGA1UEBhMCREUxDTALBgNVBAoTBEVWQ0MxCTAHBgNVBAsTADEVMBMGA1UEAwwM
      RVZDQ19IRU1TXzAxMB4XDTI0MTIwMzEyMzAwNVoXDTM0MTIwMTEyMzAwNVowPjEL
      MAkGA1UEBhMCREUxDTALBgNVBAoTBEVWQ0MxCTAHBgNVBAsTADEVMBMGA1UEAwwM
      RVZDQ19IRU1TXzAxMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAESOkdLGhclC5J
      FKD6w9oNElBrd2WOHOfUgMbqUS9JyFCXTkCk0yxhQEM9vsW2okyc70sp0NrK0K/F
      Xfv+5Seq0aNCMEAwDgYDVR0PAQH/BAQDAgeAMA8GA1UdEwEB/wQFMAMBAf8wHQYD
      VR0OBBYEFGQd3P1IkhdZr6dF2xQgDGlLTTzNMAoGCCqGSM49BAMCA0gAMEUCIQCU
      POMAl3b/SUPruDNWHAQd+ufzZr3yxw8eqEWHQk8nxAIgBRH/Al5sH0V8qMGI3iAS
      znwH07ONCF5/f2LhRcRCOFA=
      -----END CERTIFICATE-----
    private: |
      -----BEGIN EC PRIVATE KEY-----
      MHcCAQEEIGpNtxIpfMFOHXlR4vDHbgyHZsC3aoKBg+w0lBR/9aS7oAoGCCqGSM49
      AwEHoUQDQgAESOkdLGhclC5JFKD6w9oNElBrd2WOHOfUgMbqUS9JyFCXTkCk0yxh
      QEM9vsW2okyc70sp0NrK0K/FXfv+5Seq0Q==
      -----END EC PRIVATE KEY-----
chargers:
  - name: my_charger
    type: template
    template: eebus
    ski: EVB-510-061-355
    ip: <IP_ADDRESS> # IP address (optional)

Log details
[main  ] FATAL 2024/12/03 14:09:12 failed configuring eebus: could not get machineid: open /etc/machine-id: no such file or directory; for manual configuration use plant: caf5c742810cf7bda8e093d2787c9c88b16762700a9b8125ad8807f60bcdcf85

What type of operating system are you running?
Docker container
Nightly build

[X] I have verified that the issue is reproducible with the latest nightly build

Version
evcc version 0.131.8

There is no crash. Error message says it all.

There is no crash. Error message says it all.

Well if I add plant: or map machine-id there is no error, it just hangs and keep restarting.

Well if I add plant: or map machine-id there is no error, it just hangs and keep restarting.

Do you have a log?

Yes:

2024-12-09T09:56:24.296574089Z	stdout	[main  ] INFO 2024/12/09 10:56:24 listening at :7070
2024-12-09T09:56:24.289152171Z	stdout	[eebus ] INFO 2024/12/09 10:56:24 Local SKI: 641ddcfd48921759afa745db14200c694b4d3ccd
2024-12-09T09:56:23.894180721Z	stdout	[db    ] INFO 2024/12/09 10:56:23 using sqlite database: /root/.evcc/evcc.db
2024-12-09T09:56:23.838477672Z	stdout	[main  ] INFO 2024/12/09 10:56:23 using config file: /etc/evcc.yaml
2024-12-09T09:56:23.830159339Z	stdout	[main  ] INFO 2024/12/09 10:56:23 evcc 0.131.8

That's it, webconfig doesnt come online and it will reboot in 15 minutes.

Again, error message says it all.
cannot create charger 'my_charger': cannot create charger type 'template': cannot create charger type 'eebus': timeout


feat: Make own message bubble text color configurable

🎯 Goal
Describe why we are making this change
🛠 Implementation details
Provide a description of the implementation
🎨 UI Changes
Add relevant screenshots

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Remove all usage of go-git repo

The go-git repo might work great for a bare repo but it's lacking for a repo you are actively working out of. Too many edge cases are not handled and at this point I am already wrapping the raw git command for lots of missing functionality so it doesn't offer anything.

The largest offenders have been removed for now. I'll slowly remove others that don't make sense over time.


Add git config UI

Before you hit that Submit button....
Please read our contribution guidelines
before submitting a pull-request.
Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

If you want to raise a pull-request with a new feature, or a refactoring
of existing code, it may well get rejected if it hasn't been discussed on
the mailing list or
slack team first.
Proposed changes
Describe the nature of this change. What problem does it address?
Checklist
Put an x in the boxes that apply

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[x] I have added suitable unit tests to cover the new/changed functionality

Thank you for your feedbacks, Nick-san. I corresponded to your feedbacks.


On mac running scripts/eosio_build.sh freezes

I am using mac to run 1.8 release , after i cloned 1.8 releaase i tried sudo ./scripts/eosio_build.sh
this command its throwing me this
Thu Feb 13 15:16:13 UTC 2020
User: root
Current branch: release/1.8.x
No installation location was specified. Please provide the location where EOSIO is installed.
Do you wish to use the default location? /Users/shikhar/eosio/.? (y/n) y
EOSIO will be installed to: /Users/shikhar/eosio/.
and nothing happening. can anyone tell me the reason?

Can you try running without sudo?

Closing due to no response


SAP deployment 8 February release

Includes [MCDEP-401], [MCDEP-304], and [MCDEP-293]

SAP portal released.


Check default dashboard is no longer available

It seems a new version of Eureka has removed the default dashboard or moved to a specific path instead the root path.
Investigate what happened.

Dashboard is disabled in the config: https://github.com/groot-mg/service-discovery/blob/main/service-discovery-app/src/main/resources/application.yml#L13


PR For Hactoberfest 2022

Hi Saurav,
Please check the PRs u asked me to consolidate. Merge it please and let me know other valid repos to contribute.
Thanks

Verified.
PR accepted @TSG405
Successfully added under HacktoberFest-22 PR.
🚀🚀✌

For Other PR just Search Hacktober Fest Repo 22 on GitHub or else you can find few forked repo in my profile.

Thank you so much! 💯🔥


PROD env often gets stuck on a block height with no errors logged

Since we have fixed some of the issues that we detected were blocking the progress of the blockchain we no longer see in the logs why the next block is sometimes stuck in nomination. We should add some other logging info or debug the situation more to find out the cause.

Example of PROD stuck again but not on payout block. Here is some log output which shows the 4 validators are nominating the same but fail to commit. Note that v3 and v5 were slashed already so all 4 remaining validators need to confirm.
StuckBlock1521.txt

I backed up the data folders for v2, v4, v6 and v7 and ran a local setup with those 4 validators and block 1521 was externalized.

I think it is just very slow to progress through the voting phase. Locally I see:
/Users/chrishewison/REVIEW/agora/.4nodes/2/log/root.log:2021-11-22 14:05:16,603 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (1,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/Users/chrishewison/REVIEW/agora/.4nodes/2/log/root.log:2021-11-22 14:05:24,447 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (2,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/Users/chrishewison/REVIEW/agora/.4nodes/2/log/root.log:2021-11-22 14:05:34,672 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (3,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/Users/chrishewison/REVIEW/agora/.4nodes/2/log/root.log:2021-11-22 14:05:47,42 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (4,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/Users/chrishewison/REVIEW/agora/.4nodes/2/log/root.log:2021-11-22 14:06:00,940 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (5,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/Users/chrishewison/REVIEW/agora/.4nodes/2/log/root.log:2021-11-22 14:06:11,355 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (6,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)

on v6 in PROD since last restart I see:
/srv/agora/7/log/scp.log:2021-11-22 04:07:42,25 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (1,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/srv/agora/7/log/scp.log:2021-11-22 04:17:00,977 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (2,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/srv/agora/7/log/scp.log:2021-11-22 04:58:05,839 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (3,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/srv/agora/7/log/scp.log:2021-11-22 05:24:45,596 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (1,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/srv/agora/7/log/scp.log:2021-11-22 05:28:05,622 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (2,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)
/srv/agora/7/log/scp.log:2021-11-22 05:55:20,541 Trace [SCP] - BallotProtocol::bumpState i: 1521 v: (3,0x1bc6c9623a24aa6fe0489edf397ec4f4958098a586dc4d4db181539be7d87614d6a01bf4a8d1b0d171b3af5ff04d70a3d28f9f41eaecad8305b95a11deb19b79)

It looks like the underlying problem was the communication between the nodes which is now resolved.

Can you relate this issue to the PR that resolved the issue?

Can you relate this issue to the PR that resolved the issue?

I believe this  was the one.


Create a github page to allow javascript in the README

Some background:
https://stackoverflow.com/questions/21340803/embed-javascript-in-github-readme-md

Done by @IsaacTowers: https://isaactowers.github.io/q2-makarsa/