Fedora Distribution support

Hello, Fedora is a linux distribution that strives to stay very close to upstream and has a 6 month update cycle so one can find pretty much the latest dev tools on it. It will be very useful to have RPM repo for installing on Fedora linux. Useful for the ROCm project - to see how things work with latest available kernels and tools as well for Fedora users.
Presently only Ubuntu and RHEL repos are available.

Presently not useful but good to know. Fun quote:

Instructions not filled in by author. Author knows what to do. Everybody else should avoid this repo.

One thing we have been working on is getting the core kernel driver upstream so it will be easier to support other Distros.
WIth 1.9.1 with the current upstream Linux kernel, it should be possible to get Fedora working again.   let me talk to the team about getting build instruction out for this

It does work on Fedora 28 and current kernel.
However, the pain points for building from source are:

Not a obvious relation between existing binary packages and which repo they come from. The packages that compose the system change between releases, so the game starts again with each release.
If you find the repo, it may not have the version or checkout that was used to build the binary release yet;
Binary-only artefacts in binary packages, that are not in any repo;
Certain stubborness wrt paths; some packages do not like being outside /opt/rocm + /opt/rocm/packagename, so patching is required. Distributions will insist on other path;
Build system for some packages may not like ninja-build (cmake -GNinja; ROCm-Device-Libs/opencl won't build), but when building with gnu make, you will either run out of memory when using all your cores, or you have to limit the number of cores, which makes it build for eternity. Makes it not a fun debugging why the build failed.

So these are those points that I remember since I did the build the last time.

How about having the binary distribution working? I only had two roadblocks, one of them serious:
the hcc package requires pth which seems to have been renamed in latest fedora
the rocm-dkms fails to compile...
/var/lib/dkms/amdgpu/1.9-224.el7/build/amd/amdgpu/amdgpu_drv.c: In function ‘amdgpu_pmops_runtime_suspend’:
/var/lib/dkms/amdgpu/1.9-224.el7/build/amd/amdgpu/amdgpu_drv.c:768:2: error: implicit declaration of function ‘vga_switcheroo_set_dynamic_switch’; did you mean ‘vga_switcheroo_process_delayed_switch’? [-Werror=implicit-function-declaration]
  vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  vga_switcheroo_process_delayed_switch
  CC [M]  /var/lib/dkms/amdgpu/1.9-224.el7/build/amd/amdkcl/main.o
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:317: /var/lib/dkms/amdgpu/1.9-224.el7/build/amd/amdgpu/amdgpu_drv.o] Error 1

If we could get these sorted Fedora users should be able to use the binary distribution (which some of us would prefer to building from source)

How about having the binary distribution working? I only had two roadblocks, one of them serious:
1. The hcc package requires pth which seems to have been renamed in latest fedora

https://fedora.pkgs.org/27/fedora-x86_64/npth-1.5-3.fc27.x86_64.rpm.html

The rocm-dkms fails to compile...

For kernels 4.18+, I believe you aren't supposed to use rocm-dkms. Eg, [url=https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1047471-amd-rocm-1-9-available-with-vega-20-support-plus-upstream-kernel-compatibility/page2#post1047548]this comment[/url].

Thanks, will re-evaulate later on (I did install npth and forced the hcc rpm to install without deps). Will try to understand why clinfo isn't showing the GPU device despite the dkms module failing to compile. Maybe I missed a step. In any case, I could contribute a "for fedora users" installation guide if I get it running.

Will try to understand why clinfo isn't showing the GPU device despite the dkms module failing to compile.

Check if you have amdkfd loaded and /dev/kfd has the correct permissions.
Amdkfd needs to be loaded when amdgpu loads, it cannot be modprobed later. In Fedora, amdgpu is being loaded from initramfs, and initramfs is missing the amdkfd module, so you must add it manually and rebuild initramfs.
How to handle permissions is in the ROCm readme, add the udev rule.
Also try running rocm-smi, rocminfo and dmesg|grep kfd, what they do say. clinfo is OpenCL-specific info tool.

rocm-dkms was red herring, it looks like I got close but not quite there:

====================    ROCm System Management Interface    ====================
================================================================================
 GPU  Temp    AvgPwr   SCLK     MCLK     Fan      Perf    SCLK OD    MCLK OD
  0   66c     47.9W    1330Mhz  2000Mhz  33.73%   auto      0%         0%
================================================================================
====================           End of ROCm SMI Log          ====================

  Device Type:             CPU
  Device Type:             GPU ```

```# dmesg|grep kfd
[    1.663581] kfd kfd: Initialized module
[    1.917791] kfd kfd: Allocated 3969056 bytes on gart
[    1.917912] kfd kfd: added device 1002:67df

DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0
  Device Type:					 CL_DEVICE_TYPE_CPU
  Device Type:					 CL_DEVICE_TYPE_GPU
DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0
ERROR: clGetDeviceIDs(-1)

(Sorry for wall of debugging stuff)....
And finally....
./HelloWorld.cpp: In function ‘_cl_command_queue* CreateCommandQueue(cl_context, _cl_device_id**)’:
./HelloWorld.cpp:116:69: warning: ‘_cl_command_queue* clCreateCommandQueue(cl_context, cl_device_id, cl_command_queue_properties, cl_int*)’ is deprecated [-Wdeprecated-declarations]
     commandQueue = clCreateCommandQueue(context, devices[0], 0, NULL);
                                                                     ^
In file included from ./HelloWorld.cpp:23:
/opt/rocm/opencl/include/CL/cl.h:1364:1: note: declared here
 clCreateCommandQueue(cl_context                     /* context */,
 ^~~~~~~~~~~~~~~~~~~~
./HelloWorld.cpp:116:69: warning: ‘_cl_command_queue* clCreateCommandQueue(cl_context, cl_device_id, cl_command_queue_properties, cl_int*)’ is deprecated [-Wdeprecated-declarations]
     commandQueue = clCreateCommandQueue(context, devices[0], 0, NULL);
                                                                     ^
In file included from ./HelloWorld.cpp:23:
/opt/rocm/opencl/include/CL/cl.h:1364:1: note: declared here
 clCreateCommandQueue(cl_context                     /* context */,
 ^~~~~~~~~~~~~~~~~~~~
[root@future-yaxxie ocltest]# ./HelloWorld
DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.

You know what ignore all that, I had loads of OpenCL trash laying around on my system from previous attempts to make it work -- once I binned them it worked like a charm.

After going through my shell history I distilled it down to this (which means it actually wasn't too difficult)
vi /etc/yum.repos.d/rocm.repo

# Install prereqs for hcc
dnf install npth-devel hsa-ext-rocr-dev rocm-utils
# force hcc installation
dnf download hcc
rpm -ifvh  hcc-1.2.18354-Linux.rpm --nodeps

dnf install hsa-rocr-dev rocm-profiler rocm-opencl-devel rocm-cmake rocminfo rocm-dev  rocm-libs rocm-utils rocm-clang-ocl clang-devel cxlactivitylogger miopengemm miopen-hip

# These probably gave me some trouble
dnf erase libclc pocl
# dunno if we need to get rid of this but I did, but it should be providing the intel CPU openCL
dnf erase  beignet

you might notice the miopen stuff, I was trying to run tensorflow-rocm, but it segfaults...
I'm going to play around some more and see if this is actually functioning (I'm going to try arrayfire next)

Brilliant!
Just installed Fedora 29, followed your steps, minus having to erase libclc. pocl, and beignet.
However, the HelloWorld program gives me:
$ ./HelloWorld
X server found. dri2 connection failed!
DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0
DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0
Could not create GPU context, trying CPU...

From there (with the CPU), the program executes succesfully.
I also tried the vectorAdd HIP example:
$ make
/opt/rocm/hip/bin/hipcc -g   -c -o vectoradd_hip.o vectoradd_hip.cpp
/opt/rocm/hip/bin/hipcc vectoradd_hip.o -o vectoradd_hip.exe
./vectoradd_hip.exe
make: *** [Makefile:30: test] Segmentation fault (core dumped)

I'm not optimistic now though, given the failure of all the HIP examples.

Its not that it won't work (I'm going to try source build tonight), it just seems like the RPM distribution won't work (Which is a shame) -- although actually if you're only looking for OpenCL (unlikely at this point) it does look like it works (I tried the arrayfire openCL examples, seemed to work fine)

Hmm, how is that going?
I wish I'd tried a few more examples on Debian before switching to Fedora, so I'd have more reference points.
Before uninstalling hcc and trying to compile it from source, I figured I'd try the saxpy hcc example.
$ hcc -hc saxpy.cpp -o saxpy
ld: /tmp/saxpy-a33022.o: in function `hc::completion_future hc::parallel_for_each<main::$_2>(hc::accelerator_view const&, hc::extent<1> const&, main::$_2 const&)':
saxpy.cpp:(.text+0xcf5c): undefined reference to `Kalmar::CLAMP::CreateKernel(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, Kalmar::KalmarQueue*)'
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)

$ hcc -hc -I/opt/rocm/hcc/include saxpy.cpp -o saxpy
ld: /tmp/saxpy-0b561d.o: in function `hc::completion_future hc::parallel_for_each<main::$_2>(hc::accelerator_view const&, hc::extent<1> const&, main::$_2 const&)':
saxpy.cpp:(.text+0xcf5c): undefined reference to `Kalmar::CLAMP::CreateKernel(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, Kalmar::KalmarQueue*)'
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)

I don't know C++ very well, so I was expecting including the directory that contains kalmar_launch.h and company to solve this undefined reference.

I built hcc from source. Now:
$ /home/chriselrod/Documents/languages/hcc/build/bin/hcc -hc saxpy.cpp -o saxpyobjdump: /usr/lib64/libm.a: file format not recognized

$ ./saxpy
0 errors

So did you compile hcc or whole runtime? Because this would indicate the runtime worked but I had segfaults with tensorflow-rocm and when I get time I need to figure out if I need to build the whole runtime and tensorflow or what

Once I built hcc from source the saxypy example worked. OpenCL was already working before that (I built arrayfire and clinfo showed good outputs)
tensorflow-rocm still failed though, with a segfault when downloaded from pip. I can believe its due to tensorflow-rocm being compiled on different system but I couldn't build it myself, bazel is too fiddly.

I am able to run the tensorflow-rocm wheel on NixOS by setting its constituent libraries’ rpaths to pick up our built from source ROCm libraries, and then LD_PRELOAD to force our libstdc++.so. One or both of those may be needed on other distros, too.

Thanks for the tip. It good to know it does actually work!
NixOS will be one of my targets once I manage this, but RPATH patching and LD_PRELOAD sounds way too hacky for my tastes, so I'd probably fight a bit more with bazel and see over in ROCmSoftwarePlatform/tensorflow-upstream what tricks I'm missing for building.

Also In response to:

It's also worth trying if the tensorflow-rocm docker works.

This worked for me, I was able to launch the container on a system with the runtime and the kernel drivers installed (although I' pretty sure one only needs the kernel drivers for passing through devices to the docker container)

@jlgreathouse Thanks for sharing this!
Running it as I type (saves me the effort of rebuilding HIP and HCC for the failed upgrades).
One comment, I notice it did a dnf install dkms but we don't need that because we are using upstream and dont need the ROCK kernel drivers (as per docs)?

Good catch. I'll admit that there was some copy & paste between Fedora and CentOS/RHEL to save myself a bunch of typing. Feel free to submit a PR to the Experimental_ROC repo. It's developed in the open, so we won't need to do any "AMD-internal vs. GitHub-hosted" repo juggling. :)

PR submitted -- Do you have any comments about whether with rocm2 tensorflow-rocm wil lwork out of box or not? (I'm about to find out the hardway in an hour or two anyway) :)

I'll admit that I haven't tested that. I would hope that it does, or our "build MIOpen etc. from source" isn't working properly. However, my goal for the distro install scripts was to recreate what we ship at repo.radeon.com, except from GitHub source. Our TF implementation isn't shipped that way, so it wasn't on my (overly full) TODO list. I also didn't go out of my way to test anything major except for batches of OpenCL, HCC, and HIP test apps to verify functionality.

Not a problem, I'll just update when I know. Last time I tried it segfaulted and it looked like I needed to build from source (which I wasn't able to get going).
Thanks for your input though!

Hi All,
I was able to install 2.7.2 on Fedora30 (yum_2.7.2.tar.bz2  ) using Experimental Fedora 29 rpm install scripts as a guide and run most of commands manually. Overall things worked out out of box. I did not run any opencl app yet but looking forward to:) Problems I had faced during installation:

extracting and installation of core rocm rpms went smoothly

hcc manual installation:(https://github.com/RadeonOpenCompute/Experimental_ROC/blob/master/distro_install_scripts/Fedora/common/component_scripts/01_09_hcc.sh)

I had to hardcode MAX_THREADS, script wasnt very generous by default , 32 thread took 20G of memory otherwise I stuck with 5 thread
I believe only this issue critical: during packaging phase CPack aggressively complained about python shebangs conflict for some files (i.e. rpt, hmaptool,run-find-all-symbols, ) and terminated process (https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error)

rocm libs installation:

I have just removed trusth

HIP examples:

rocm agent enumerator was not in opt/rocm/bin but in /bin i had to create symlink

After test:
Out of topic but I have a feeling my results are a bit low for comparing to GPU device gflop values on wikipedia, I do not know which device is used but do you think those numbers are normal for TR1950x,FuryX and Vega pair, logs attached (no dmesg error present)

Using HIP_PATH=/opt/rocm/hip
hipcc -std=c++11 -O3 -o rtm8_hip rtm8.cpp
memory (MB) = 984.096000
pts (billions) = 1.122751
Tflops = 0.075224
dt = 0.213201
pt_rate (millions/sec) = 5266.159529
flop_rate (Gflops) = 352.832688
speedup = 0.126594

kernel&amdgpu latest: vanilla with fedora config, 5.3 release
build on commit cbafe18c71028d5e0ee1626b4776fea5d5824a78
glxinfo: https://pastebin.com/QvGvxCBQ
rocminfo: https://pastebin.com/5vmbSJa5
clinfo: https://pastebin.com/kfar2KLE
hip_examples_log: https://pastebin.com/jvdFw3gk

I'm actually surprised how painless it was to setup. Almost nothing works on the first try. I'm running Fedora 32 and Kernel 5.6.7-300. I also have 5700 XT and a Ryzen 2700.
This post caught my eye: https://www.reddit.com/r/Fedora/comments/er8odt/davinci_resolve_on_fedora_31_with_amd_gpu/
I decided to use version 3.3 instead (which does works with Resolve).
name=ROCm
baseurl=https://repo.radeon.com/rocm/yum/3.3/
enabled=1
gpgcheck=0

I then began the installation and forcing hcc to install. Unfortunately I did not check if hcc actually needed to be forced.
sudo dnf install npth-devel hsa-ext-rocr-dev rocm-utils
sudo dnf download hcc
sudo rpm -ifvh hcc-3.1.20114-Linux.rpm --nodeps

At this point it wasn't quite working, but it sounded like it needed dkms (and maybe the runtime).
sudo dnf install rocm-runtime rocm-dkms

I then added myself to the video group, and voila. It was immediately recognized in Blender and Resolve.
Now performance is a different story. While rendering in Blender I have two cores maxed, and the gpu will bounce from ~3% to 99%. It renders blocks very slowly because of this. Each spike does carry a lot of samples, so if this could could consistently use 100% I'm sure it would be very fast.
In a blender render race my CPU blazes past the GPU.

@DeathTBO I followed your instructions but I had nothing but crashes when trying to use the any render device, and the kernel-core update installs but fails on the amdgpu driver build.  Rebooting into the new 5.6.8 kernel that just dropped yielded a broken kernel.  Simple fix for me was to remove all this and reinstall kernel-core.  Now all seems fine.  You run into this?

@andrewschott Yes I had the same issue when upgrading to 5.6.8, but I think it's a dkms issue rather than a rocm issue. I have an openrazer dkms package that also fails and breaks the kernel install. I had to remove both rocm and openrazer dkms for it to work.

but I think it's a dkms issue rather than a rocm issue

sudo dnf install rocm-runtime rocm-dkms

When I was testing a while back, I didn't need to add the rocm-dkms module. Somewhere in the docs I think it was saying this was to load a version of amdkfd kernel module but I believe this has been mainlined for a long time now

So what is the easy button for fedora 32?

ROCm 3.5 works fine with my Vega M GPU on Fedora 32. See my comment here: https://github.com/RadeonOpenCompute/ROCm/issues/651#issuecomment-640245153. I mostly followed @DeathTBO's instructions above.

@DeathTBO For the record, I was able to have a fully functional DR 16.2.7 with Fedora 33 using the in-kernel amdgpu driver and OpenCL part of ROCm provided in AMDGPU-PRO 20.45 (seems to be something like ROCm 3.8).
The main ingredients are the re-wrapped RPM package of Ubuntu binaries https://github.com/ptitjes/opencl-amd and the OpenCL fix of https://github.com/h33p/resolve-amdocl-fix.

Thanks @JLTastet and @ptitjes for the latest update on Fedora.
Request everyone, who is looking for Fedore support, to go with tweaks and install ROCm as mentioned above.
Thank you.

Thanks @JLTastet and @ptitjes for the latest update on Fedora.
Request everyone, who is looking for Fedore support, to go with tweaks and install ROCm as mentioned above.
Thank you.

@ROCmSupport This fix is outdated. My ROCm install eventually broke, and I did not succeed in reinstalling it (neither on Fedora 32 nor 33).

@ROCmSupport This fix is outdated. My ROCm install eventually broke, and I did not succeed in reinstalling it (neither on Fedora 32 nor 33).

@JLTastet, with Fedora 32 and ROCm 4.0.0, I had put the fullpath for the ICD (Installable Client Driver) in and did it in a new file. My focus is on OpenCL though, so I do not know if this helps with everything.
echo /opt/rocm-4.0.0/opencl/lib/libamdocl64.so | sudo tee /etc/OpenCL/vendors/amdocl64_rocm_custom.icd

Previously, with ROCm 3.10.0, I had to correct the shebang for python in /opt/rocm-3.10.0/bin/rocm_agent_enumerator and also do the fullpath for the ICD.
Otherwise, I mostly followed past suggestions above (and have been doing so since, I think, Fedora 28, except am now not using rocm-dkms). To condense and summarize again:
FYI: the installation guide recommends a fresh ROCm install for v4.0, so it is best to remove all old version of ROCm before moving forward (sudo dnf list --installed | grep "@ROCm").
sudo dnf remove libclc pocl beignet hsakmt mesa-libOpenCL
sudo dnf install npth-devel kmod
sudo dnf install --setopt=install_weak_deps=False hsa-ext-rocr-dev rocm-utils
# May have had to do a similar rpm forcing as above for "rocminfo" but that may have been for 3.10.0.
sudo rpm -ifvh --nodeps --replacepkgs --replacefiles $(sudo dnf repoquery --quiet --location hcc)
sudo dnf install rocm-dev
# Some said they did not need udev stuff, but it is in the v4.0 documentation.
sudo mkdir -p /etc/udev/rules.d
echo 'SUBSYSTEM=="kfd", KERNEL=="kfd", TAG+="uaccess", GROUP="video"' | sudo tee /etc/udev/rules.d/70-kfd.rules
sudo dnf install rocm-opencl rocm-opencl-devel opencl-headers

The documentation also has some user group stuff. Like the udev stuff, I am unsure of its need, but here it is for completeness:
echo -e '\nADD_EXTRA_GROUPS=1\nEXTRA_GROUPS=video\n' | sudo tee -a /etc/adduser.conf
sudo usermod -a -G video $(whoami)

I have not tested much on the host. I run it in a container with the below. Inside there, I have every bin under /opt/rocm and /opt/rocm-${ROCM_VERSION} in /etc/profile.d/rocm-custom.sh. Then every lib and lib from those same roots in /etc/ld.so.conf.d/rocm-custom.conf followed calling sudo ldconfig.
docker build --tag opencl:rocm-fedora - < Dockerfile
docker run --rm -i -t --privileged --device /dev/dri:/dev/dri opencl:rocm-fedora

References
Not everything from these was needed for me because I was already following

https://rigtorp.se/notes/rocm/
https://linuxreviews.org/Radeon_Open_Compute#Fedora_32.2F33.2C_OpenCL_only
https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html#centos-rhel

@JLTastet, with Fedora 32 and ROCm 4.0.0, I had put the fullpath for the ICD (Installable Client Driver) in and did it in a new file. My focus is on OpenCL though, so I do not know if this helps with everything.
echo /opt/rocm-4.0.0/opencl/lib/libamdocl64.so | sudo tee /etc/OpenCL/vendors/amdocl64_rocm_custom.icd

Previously, with ROCm 3.10.0, I had to correct the shebang for python in /opt/rocm-3.10.0/bin/rocm_agent_enumerator and also do the fullpath for the ICD.
Otherwise, I mostly followed past suggestions above (and have been doing so since, I think, Fedora 28, except am now not using rocm-dkms). To condense and summarize again:
FYI: the installation guide recommends a fresh ROCm install for v4.0, so it is best to remove all old version of ROCm before moving forward (sudo dnf list --installed | grep "@ROCm").
sudo dnf remove libclc pocl beignet hsakmt mesa-libOpenCL
sudo dnf install npth-devel kmod
sudo dnf install --setopt=install_weak_deps=False hsa-ext-rocr-dev rocm-utils
# May have had to do a similar rpm forcing as above for "rocminfo" but that may have been for 3.10.0.
sudo rpm -ifvh --nodeps --replacepkgs --replacefiles $(sudo dnf repoquery --quiet --location hcc)
sudo dnf install rocm-dev
# Some said they did not need udev stuff, but it is in the v4.0 documentation.
sudo mkdir -p /etc/udev/rules.d
echo 'SUBSYSTEM=="kfd", KERNEL=="kfd", TAG+="uaccess", GROUP="video"' | sudo tee /etc/udev/rules.d/70-kfd.rules
sudo dnf install rocm-opencl rocm-opencl-devel opencl-headers

The documentation also has some user group stuff. Like the udev stuff, I am unsure of its need, but here it is for completeness:
echo -e '\nADD_EXTRA_GROUPS=1\nEXTRA_GROUPS=video\n' | sudo tee -a /etc/adduser.conf
sudo usermod -a -G video $(whoami)

I have not tested much on the host. I run it in a container with the below. Inside there, I have every bin under /opt/rocm and /opt/rocm-${ROCM_VERSION} in /etc/profile.d/rocm-custom.sh. Then every lib and lib from those same roots in /etc/ld.so.conf.d/rocm-custom.conf followed calling sudo ldconfig.
docker build --tag opencl:rocm-fedora - < Dockerfile
docker run --rm -i -t --privileged --device /dev/dri:/dev/dri opencl:rocm-fedora

References
Not everything from these was needed for me because I was already following

https://rigtorp.se/notes/rocm/
https://linuxreviews.org/Radeon_Open_Compute#Fedora_32.2F33.2C_OpenCL_only
https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html#centos-rhel

@ROCmSupport  It would be nice if ROCM could package the rocminfo and rocm-smi-lib64 so I didn't need to fiddle with the python shebang to make it work.. just re-iterating from: https://rigtorp.se/notes/rocm/ but you have to find the packages, force an "ignore deps" install and then sed the rocm_agent_enumerator:
 dnf repoquery --location rocminfo
rpm -Uvh --nodeps http://repo.radeon.com/rocm/centos8/rpm/rocminfo-<IP_ADDRESS>.rocm-rel-4.0-23-605b3a5.rpm
 sed -i 's/^#!.*/#!\/usr\/bin\/python/' /opt/rocm-4.0.0/bin/rocm_agent_enumerator
dnf repoquery --location rocm-smi-lib64
rpm -Uvh --nodeps http://repo.radeon.com/rocm/centos8/rpm/rocm-smi-lib64-<IP_ADDRESS>-rocm-rel-4.0-23-4b49d2d.x86_64.rpm

then you can proceed w/ installing rocm-dev:
 dnf install rocm-dev rocm-opencl rocm-opencl-devel opencl-headers

This is kind of a pain to keep doing when there's a known fix..

Something which would ease this pain which I use:
This is an RPM spec file

Name:       rocm-python-dummy
Version:    1.0.0
Release:    2%{?dist}
Summary:    Makes ROCm be quiet about missing "platform-python"
License:    MIT
Source0:    yapyap.tar
BuildArch:  noarch

Provides: /usr/libexec/platform-python

%description
Makes ROCm be quiet about missing "platform-python"

%files

%changelog

then build it using rpmbuild -bb dummy.spec and then install the generated RPM.
Then if you do ln -s /usr/bin/python /usr/libexec/platform-python  you don't have to force nodeps to install packages and you don't have to replace the interpreter in any files. It's not great, it just makes it less unbearable.

So it's been close to a year, and I decided to check out ROCm once again. The process seemed... Easier? Keep in mind this is not a fresh install, but I did remove (all of?) the ROCm files last year.
I added my repo file, this time using version 4.0.1.
[ROCm]
name=ROCm
baseurl=https://repo.radeon.com/rocm/yum/4.0.1/
enabled=1
gpgcheck=0

I noticed the hcc package was missing, a package I had to force on version 3. @DaveWK mentioned needing to fiddle around with python sed and nodep installs, but the rocm_agent_enumerator package wasn't in the 4.0.1 repo.
I figured I could skip that step, so I decided to go ahead and run his install command.
 dnf install rocm-dev rocm-opencl rocm-opencl-devel opencl-headers
And voila. After a reboot it was immediately recognized as a device, and I am currently rendering in Blender.
Performance is far better than last time. However, my 8/16 Ryzen cpu still renders overall faster, but each individual square now renders at a constant rate. I noticed in #887 that the 5700xt isn't fully supported... A shame since that is probably the only thing holding me back now.
I would love for @ROCmSupport to officially support Fedora, especially since CentOS is moving to a rolling release. It feels like Fedora would be a more stable ground.

Hi @DeathTBO
Thanks for your kind response.
We do not have plans to support Fedora right now.
Please stay tuned for the updates via our Documentation.
Thank you.

Because of open drivers performance and installation issues, I decided to sell my card and do whatever I want in the cloud for the time being. I guess this is not possible for everybody but for those that can do that, you can sell your cards now prices are huge to return some of your investment. When prices of new cards become low or after a few years I may try again.

I would love for @ROCmSupport to officially support Fedora

Me either, but I also wonder why ROCm isn't yet in the official repos. Is it still a packaging hell?
Most users believe clover will be usable before ROCm does.

I gave up long time ago but reading follow ups it is impressive what AMD has achieved with linux contributions, built a great team with lot of knowledge and failed to provide a proper,high performance,backward compatible low level SDK/language to its own hardware... If I am not getting most of it from your software where I should look, I had a feeling even your old AMD opencl sdks had better performance ratio by percentage, not even mentioning distro supports... So gpus waiting in my storage fury-x, vega 64, sapphire toxic... Would there be a next generation? I doubt it, I turn to CPUs with threadrippers,still a AMD supporter and I hope you will do better on FPGA

Not sure whether it is still useful for anybody here, but I am also an owner of a 5700XT card and a while ago I thought I'll give it a try and self-compile ROCm for Fedora 33, not knowing what obstacles would wait for me. However, I managed to compile a huge part and packaged it for COPR. It is available here. It is just Fedora 33 and ROCm 3.9 IIRC, and I am not sure yet whether I really want to go again through the daunting task of patching things for the newer releases, but lets see. Unfortunately, the COPR repository is missing the higher level libraries like BLAS etc., which from my understanding are those libraries that miss support for my 5700XT.


[2.2.x] Refs #31485 -- Backported jQuery upgrade to 3.5.1.

CI failures:

flake8: new flake8 version
Docs: WARNING: term feature release not found in case sensitive match.made a reference to Feature release instead.

Thanks @felixxm. Updated.

buildbot, test on selenium.

buildbot, test on selenium.


Mapbox-4.0.0 : Can't add a marker : markerOptions.title is not a function

Hi, I've got an issue with your mapbox-4.0.0 branch. I know it's under development, but I needed a mapbox 4 version to make it run on 64bits devices so I gave it a shot.
I succeeded to make the map show up by adding :
<service android:name="com.mapbox.mapboxsdk.telemetry.TelemetryService" />
in the android manifest. I don't know why the one in the plugin doesn't work.
Then I tried to put a marker on the map but I go this error :

JS: Error in mapbox.addMarkers: TypeError: markerOptions.title is not a function
JS: EXCEPTION: Error: Uncaught (in promise): TypeError: markerOptions.title is not a function
JS: STACKTRACE:
JS: Error: Uncaught (in promise): TypeError: markerOptions.title is not a function
JS:     at resolvePromise (/data/data/org.nativescript.gpadri/files/app/tns_modules/zone.js/dist/zone-node.js:496:32)
JS:     at /data/data/org.nativescript.gpadri/files/app/tns_modules/zone.js/dist/zone-node.js:473:14
JS:     at /data/data/org.nativescript.gpadri/files/app/tns_modules/nativescript-mapbox/mapbox.js:189:7
JS:     at new ZoneAwarePromise (/data/data/org.nativescript.gpadri/files/app/tns_modules/zone.js/dist/zone-node.js:542:30)
JS:     at Object.mapbox.addMarkers (/data/data/org.nativescript.gpadri/files/app/tns_modules/nativescript-mapbox/mapbox.js:175:10)
JS:     at GeotrackPage.addMarkers (/data/data/org.nativescript.gpadri/files/app/geotrack/geotrack.components.js:66:16)
JS:     at DebugAppView._View_GeotrackPage0._handle_tap_12_0 (GeotrackPage.template.js:92:28)
JS:     at /data/data/org.nativescript.gpadri/files/app/tns_modules/@angular/core/src/linker/view.js:316:24
JS:     at ZoneDelegate.invoke (/data/data/org.nativescript.gpadri/files/app/tns_modules/zone.js/dist/zone-node.js:281:29)
JS:     at Object.NgZoneImpl.inner.inner.fork.onInvoke (/data/data/org.nativescript.gpadri/files/app/tns_modules/@angular/core/src/zone/ng_zone_impl.js:45:41)
JS: Unhandled Promise rejection: markerOptions.title is not a function ; Zone: angular ; Task:  ; Value: TypeError: markerOptions.title is not a function
JS: Error: Uncaught (in promise): TypeError: markerOptions.title is not a function

By checking the mapbox documentation, your implementation looks good. I can't figure out why it doesn't want to find the title function.
I saw some Todo around so maybe it's something that you already know.

Ha, that's exacltly the reason why I stopped working on that branch until this issue is resolved. Please follow that issue for updates. I will continue my work once that's fixed and released.

Ok, I see I'm just on time :). Hope they gonna fix this soon.


[WFCORE-704] Adding initial Elytron capability definitions.

For the Elytron integration it should be possible to completely remove the subsystem and provide an alternative that satisfies the same set of capabilities.  This PR is to get the initial class in place to hold the capability definitions (more to be defined later).

Windows Build 1421 is now running using a merge of f2e85d7315ab5ed46e2ea2341aa3446b7429d5b2

Linux Build 1873 is now running using a merge of f2e85d7315ab5ed46e2ea2341aa3446b7429d5b2

Core - Full Integration Build 1017 is now running using a merge of f2e85d7315ab5ed46e2ea2341aa3446b7429d5b2

Windows Build 1421 outcome was SUCCESS using a merge of f2e85d7315ab5ed46e2ea2341aa3446b7429d5b2
Summary: Tests passed: 3109, ignored: 69 Build time: 0:20:18

Core - Full Integration Build 1017 outcome was SUCCESS using a merge of f2e85d7315ab5ed46e2ea2341aa3446b7429d5b2
Summary: Tests passed: 2866, ignored: 374, muted: 1 Build time: 0:50:14

I don't like this at all, particularly in controller.

Yes that was the reason for getting this PR in - I assumed it would be one to drive some debate ;-)
So here is the problem - we have multiple subsystems providing the capabilities and they are used in multiple places - both within our core codebase and within other subsystems, some of those subsystems are in the WildFly / Core codebase and others are not.
Essentially there are three pieces of information that everything needs to be in agreement with when it comes to the capability definitions: -

The base name.
Whether the capability is dynamic.
The Service type

Regarding location of the definitions the reason I selected controller was really driven by maven dependencies and controller did already contain a 'security' package.  To define a RuntimeCapability I need a dependency on controller as that is where that class lives, I did consider the existing security and security-api modules but controller already had a dependency on them so would have created a cycle - this is also more than domain management so did not really fit in that module either.
So we need two discussions: -
1 - How we coordinate the three requirements described above between different components.
2 - Where that coordination lives.
Number 2 probably only makes sense after 1.

It has been decided that the capabilities will be co-ordinated using documentation: -
https://developer.jboss.org/wiki/WildFlySecurityElytron-CapabilitiesAndRequirements-Reference
Static definitions can still be used within code but these would be for the local module they are defined within.

Core - Full Integration JDK8 Build 29 outcome was FAILURE using a merge of f2e85d7315ab5ed46e2ea2341aa3446b7429d5b2
Summary: Compilation error: Compiler (new) Build time: 00:03:30

Core - Full Integration JDK8 Build 44 outcome was FAILURE using a merge of f2e85d7315ab5ed46e2ea2341aa3446b7429d5b2
Summary: Compilation error: Compiler Build time: 00:02:04


Would you please share resources used in your implementation like “ukwac.model”，“ukwac_id2word.pkl“，“ukwac_word2id.pkl”

Would you please share these resources？Looking forward to your reply.

The ukwac.model is trained using gensim word2vec tools based on the corpus ukWac. The official download site is https://wacky.sslmit.unibo.it/doku.php?id=corpora since we are not supposed to distribute it.

The ukwac.model is trained using gensim word2vec tools based on the corpus ukWac. The official download site is https://wacky.sslmit.unibo.it/doku.php?id=corpora since we are not supposed to distribute it.

Thanks to your replay.

I've already downloaded ukwac（non dependency-parsed, non-pos tagged, plain text version）  according to your description.  Is this the version you utilized?

Besides, I encountered "UnicodeDecodeError" when I tried to use gensim with "word2vec.Word2Vec(LineSentence('ComHyper main/ukwac_preproc/cleaned_pre.pos.corpus'),size=300,min_count=1,sg=1)". Have you encountered similar problems? I would be very grateful if you can share the script about training word embeddings, considering hyper parameters like "min-count" will affect the final result.

Generally I use the following code to train the gensim word2vec model as introduced in his official blog.  https://rare-technologies.com/word2vec-tutorial/.  The parameters are set default such as min_count = 5.
class MySentences(object):
    def __init__(self, dirname):
        self.dirname = dirname

    def __iter__(self):
        for fname in os.listdir(self.dirname):
            for line in open(os.path.join(self.dirname, fname)):
                yield line.split()

sentences = MySentences('/some/directory') # a memory-friendly iterator
model = gensim.models.Word2Vec(sentences)

Generally I use the following code to train the gensim word2vec model as introduced in his official blog. https://rare-technologies.com/word2vec-tutorial/. The parameters are set default such as min_count = 5.
class MySentences(object):
    def __init__(self, dirname):
        self.dirname = dirname

    def __iter__(self):
        for fname in os.listdir(self.dirname):
            for line in open(os.path.join(self.dirname, fname)):
                yield line.split()

sentences = MySentences('/some/directory') # a memory-friendly iterator
model = gensim.models.Word2Vec(sentences)

Thanks a lot! Wish you a happy day.


Temperature Card in Screenshot?

Hey, love your theme just wondering what the temperature card in the screenshot is?

Hey,
it’s a mini-graph-card and card-mod (you can get it in the HACS) with the following configuration. Maybe it helps as a reference.
type: custom:mini-graph-card
name: Temperatur
line_width: 2
points_per_hour: 0.5
animate: false
entities:
  - entity: sensor.aqara_weather_kitchen_temperature
    name: Küche
  - entity: sensor.aqara_weather_living_room_temperature
    name: Ofen
  - entity: sensor.aqara_weather_bedroom_temperature
    name: Bett
  - entity: sensor.aqara_weather_bathroom_temperature
    name: Bad
  - entity: sensor.aqara_weather_wood_storage_temperature
    name: Holz
  - entity: binary_sensor.night
    name: Nacht
    color: rgba(0, 0, 0, 0.8)
    y_axis: secondary
    aggregate_func: min
    show_state: true
    show_line: false
    show_points: false
state_map:
  - value: 'off'
    label: Tag
  - value: 'on'
    label: Nacht
show:
  labels: true
  labels_secondary: false
card_mod:
  style: |
    .name > span {
      font-size: 14px;
      opacity: 1 !important;
      color: var(--secondary-text-color) !important;
    }


647: Fixing OpenApiPlugin

Adresses/Fixes #.
I changed the OpenApiParser to receive SwaggerPasrerException. The OpenApiPlugin now returns InputReaderException while parsing XML.
#647
#427

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


mishandles code sections

Example: LibraryMake has this, a short para and indented code section.
/Build.pm
use Panda::Common;
use Panda::Builder;
use LibraryMake;
use Shell::Command;

class Build is Panda::Builder {
    method build($workdir) {
        my $makefiledir = "$workdir/src";
        my $destdir = "$workdir/blib/lib/My/Module";
        mkpath $destdir;
        make($makefiledir, $destdir);
    }
}

p6doc renders it thusly:
/Build.pm
use Panda::Common; use Panda::Builder; use LibraryMake; use Shell::Command;

class Build is Panda::Builder {
    method build($workdir) {
        my $makefiledir = "$workdir/src"; my $destdir =
        "$workdir/blib/lib/My/Module"; mkpath $destdir; make($makefiledir,
        $destdir);
    }
}

perl6 --doc /path/to/Librarymake.pm6 renders correctly:
/Build.pm
use Panda::Common;
use Panda::Builder;
use LibraryMake;
use Shell::Command;

class Build is Panda::Builder {
    method build($workdir) {
        my $makefiledir = "$workdir/src";
        my $destdir = "$workdir/blib/lib/My/Module";
        mkpath $destdir;
        make($makefiledir, $destdir);
    }
}

Code within =begin code =end code acts the same

It's rendered correctly now, using perl6 --doc. I close.


react native is not excepting positive/negative lookbehinds as valid regex

Description
in my app when trying to use positive/negative lookbehinds i get this error: invalid regular expression invalid group specifier name my main app is on react native 62 i have made an app for testing purposes and this is on the latest react native 63.4 and the error still persists, i think this is a bug but if not any help or advice on how to fix this would be greatly appreciated.
React Native version:
System:
OS: Windows 10 10.0.19041
CPU: (8) x64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Memory: 11.31 GB / 15.94 GB
Binaries:
Node: 12.18.2 - C:\Program Files\nodejs\node.EXE
Yarn: Not Found
npm: 6.14.11 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK:
API Levels: 23, 26, 28, 29, 30
Build Tools: 28.0.3, 29.0.2, 29.0.3, 30.0.1
System Images: android-23 | Google APIs Intel x86 Atom, android-25 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-27 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom_64
Android NDK: Not Found
Windows SDK: Not Found
IDEs:
Android Studio: Not Found
Visual Studio: Not Found
Languages:
Java: 1.8.0_271 - /c/Program Files/Java/jdk1.8.0_271/bin/javac
Python: 2.7.3 - /c/Python27/python
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: 0.63.4 => 0.63.4
react-native-windows: Not Found
npmGlobalPackages:
react-native: Not Found
Steps To Reproduce
I have added a test app repo for testing. i have added 9 test buttons and only the lookbehinds fail.

press the quick test buttons for a quick test or type your own regex in the input to test.
to get the error and call stack turn off the safety switch.

Expected Results
I expected for the regex to be valid
Snack, code example, screenshot, or link to a repository:
testing repo - https://github.com/SyntappZ/react-native-regex-testing

@SyntappZ Thank you for the repo example! Great UI on it.

It seems weird that a valid regex expression does not validate correctly on React Native. This is definitely an issue, nice catch. Added the appropriate labels

@SyntappZ Thank you for the repo example! Great UI on it.

It seems weird that a valid regex expression does not validate correctly on React Native. This is definitely an issue, nice catch. Added the appropriate labels

Thanks mate 🙂

Thanks mate 🙂

Is there any update on this. I'm facing the same issue is react native version 0.68.2.

The issue is lookbehind regex is not supported in JSC (which is JS compiler in RN). Replacing JSC with Hermes fixed the issue for me.


the generator is not working

Describe the bug
after installation, nothing has changed, the stone is not replaced with ores - from generator
(plugin is fresh after install)
Console errors
empty
Config file
https://hastebin.com/fekelitewo.php
System (please complete the following information):

OS: [Win_10]
Plugin version: [1.4.1]
MC version: [1.15.2] - latest spigot jar

Sorry for the late answer. I do not know why I have not responsed to this.
It looks like you are testing it in a world called "world" which is on the disabled worlds lists by default in version 1.4.1. If you test it in another world or remove that world from the disabled worlds list then it will probably work again.
In the next version this will never happen because I will remove it by default :D


Clean private repository secret

To clone a private repository - we store credentials in the k8s secret.
After successful application provisioning, we remove this secret.
If we create an application with some errors and then remove this application - the private repository secret will not be cleaned.
We need to remove this secret in such cases.

Fixed


Make new SyncNamespace refactoring work with omnisharp-roslyn

3.x roslyn introduced sync namespace refactoring https://github.com/dotnet/roslyn/issues/14341
However it doesn't show up in omnisharp-roslyn with current version. Reason behind this is project DefaultNamespace that is null, it should be set up during project creation/updates.
Method to make it is currently internal http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/Workspace/Solution/Solution.cs,e596842b39b5f5f9
Heres proof of concept that after invoking that method via reflection it works as expected

Changes required for previous setup https://github.com/savpek/omnisharp-roslyn/commit/614d2e03f2ca51a81a2cded8605de0cdbd367ded
Roslyn issue: https://github.com/dotnet/roslyn/issues/35173

I think the better way would be to use the API on ProjectInfo (as soon as ProjectInfo is created, not when the project is added to solution) rather than the one you pointed to, but that one is also internal http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/Workspace/Solution/ProjectInfo.cs,151

I think both needed actually:

constructor case on initial / new project.
workspace update to support case where user changes RootNamespace without full restart of omnisharp.


System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (in v3.0.466)

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

System Information

OS: [e.g. Windows 10 2004]
Game version [e.g. Stream, GOG and please include the CS]
Version of the editor: [e.g. 3.0.347]

Additional context
Please also attach a save file that exhibits the issue.

Can you actually fill out the report or upload a save?

I don't know how to upload saves here, unfortunately, if you tell me I will be grateful

Can you attach a save file so I can see why this happened?
On Sun, Jan 23, 2022, 12:24 PM stas2794 @.***> wrote:

[image: 2022-01-23_20-23-43]
https://user-images.githubusercontent.com/98257858/150690246-db4e464f-027e-4a89-a61d-4afd67693f2f.png
—
Reply to this email directly, view it on GitHub
https://github.com/mburbea/koar-item-editor/issues/142#issuecomment-1019529842,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABUB4LJUSISMQWIB7NZ553UXQ2ULANCNFSM5MTEPRWQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
 If that doesn't work you
can email me at @.***
On Sun, Jan 23, 2022, 12:25 PM stas2794 @.***> wrote:

I don't know how to upload saves here, unfortunately, if you tell me I
will be grateful
—
Reply to this email directly, view it on GitHub
https://github.com/mburbea/koar-item-editor/issues/142#issuecomment-1019530017,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABUB4OU7IAZETQWHNVCSETUXQ2ZBANCNFSM5MTEPRWQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were assigned.Message ID:
@.***>

sent by mail

Closed as human error.


😬 (grimace) emoji missing?

I tried searching every term that Emojipedia uses, including copy/pasting the emoji (😬) directly and don't believe the "grimace" emoji is in the add-on! I wonder if others are missing?
Hope this can be addressed, but otherwise: fantastic plug-in. Saves a lot of time using emoji.
Edit: I should add that this is not a new emoji but part of the first release of emoji, Emoji 1.0 (source).

This should be closed, "grimace" != "grimacing"
:grimacing:

ok!


Acquire testers

I need to acquire testers - HOW?
Need testers with dedicated Gfx: ATI and NVidia

we have two potential testers from Linux Muster Net :)


Storage clients should handle AzureNamedKeyCredential as credential

Is your feature request related to a problem? Please describe.
The storage clients (blob, queue, ...) doesn't seem to support the type AzureNamedKeyCredential. This is inconsistent with many other parts of the API. For instance the table client allows it:
https://github.com/Azure/azure-sdk-for-python/blob/c8a02681b2cff658237e9ea117ee67e65a8c79ca/sdk/tables/azure-data-tables/azure/data/tables/_base_client.py#L76-L82
It is also frustrating that the credential is typed as Any.
https://github.com/Azure/azure-sdk-for-python/blob/c8a02681b2cff658237e9ea117ee67e65a8c79ca/sdk/storage/azure-storage-blob/azure/storage/blob/_shared/base_client.py#L71
This causes a lot of guessing what kind of credential the clients support 😕
Describe the solution you'd like
The signature should get proper type annotations, and this function should simply handle AzureNamedKeyCredential.
https://github.com/Azure/azure-sdk-for-python/blob/c8a02681b2cff658237e9ea117ee67e65a8c79ca/sdk/storage/azure-storage-blob/azure/storage/blob/_shared/base_client.py#L348-L359
Perhaps the private type SharedKeyCredentialPolicy should be even completely be replaced by AzureNamedKeyCredential.
Describe alternatives you've considered
Type guessing and constantly converting from and to AzureNamedKeyCredential and the plain {"account_name": str, "account_key": str} that the blob storage wants.

@bluenote10 Thanks for your feedback, we'll investigate asap.

Thanks for this report @bluenote10!
You're 100% correct - this should be added. AzureNamedKeyCredential was added to Azure Core some time after the first stable Storage SDK releases - and it looks like we forgot to go back and add support for it. Thanks for calling this out. :)

@vincenttran-msft To add onto this, AzureKeyCredential also isn't supported. I'd be happy to try to help out with this.

any update on this?  I also encountered issues that storage client does not support AzureNamedKeyCredential

Hi @bupt-wenxiaole, support for AzureNamedKeyCredential was released in the latest version of each Storage package. For blob, that would be 12.4.1 (feature first added in 12.14.0b1). Please try with the latest version, thanks.


CHANGES.txt and tests/ in pypi tarball

Could you please consider to add tests/ and CHANGES.txt into release?

Sure. Feel free to create a pull request

The pull request was created already.

#16


Expand Bake_Chapter_Introductions

Added a new way to bake chapter objectives when they already exist in the introduction page in a div format

Closed because the issues are being added to Karina's issue: https://github.com/openstax/kitchen/pull/356


Update GitHub Desktop to 216

Thank you for the contribution. It was merged directly as 5de4bce5f0da17668020172f01aa3e25e18f13cf to keep commit history cleaner. Your contribution is still credited to you.


Known-Unsupported Mastodon Clients

Mastodon Redirect can't currently add support for the following clients. This is because they don't provide any method for redirecting links to them to parse and open.

[ ] AndStatus.
[ ] Chazuke.
[ ] Dodo.
[ ] IndiePass.
[ ] Mammut.
[ ] Mastify.
[ ] Mastodon (hide1202).
[ ] MastodonClient.
[ ] Mastodroid.
[ ] Mastorithm.
[ ] Milktea.
[ ] Raki.
[ ] Shitter.
[ ] Tootrus.
[ ] Tusky - Issue.
[ ] Twidere.
[ ] Woolly.
[ ] Yukari.

I've made a issue on the yuito repo for the support regarding what its missing. The related issue is linked below:
https://github.com/accelforce/Yuito/issues/33


Pass in keys when initializing DfaEncoder

This depends on https://github.com/kpdyer/libfte/pull/24
Should address https://github.com/kpdyer/fteproxy/issues/176

Thanks!


Unreliable Autocomplete at class level

Just wondering if anyone else is having problems with autocompletion inside then closure..
It seems to work every time when using with local variables inside functions, but with class/struct level variables it simply does not autocomplete.
I'm using the Swift 2.3 version with Xcode 8 but the problem persists...
(I know this is probably a SourceKit thing, but just wondering if is happening to anyone else)

Duplicated: #14. Xcode is silly :( We could open rdar someday


Major Refactor for Python Standardization and CLI Isolation

Hey @rosenpin,
First of all, I've got to say - this project is terrific! However, I ran into some challenges, primarily due to the CLI being intermixed with other systems. This aspect somewhat hindered the product's usability for me, which prompted me to make a few adjustments.
My main objective was to ensure that the project strictly adheres to all Python standards - a move that not only retains the existing functionality but also introduces an extra feature. We can now depend on pipx for cross-system project installation.
Synopsis of Changes:

I've transitioned the project to a src layout. This strategy helps prevent unexpected path collapses when executing tests and running linters over src, among other benefits.
The tests have been relocated from being part of the main source code to the project root.
I've replaced the relative imports with absolute ones for more transparency and accuracy.
I addressed and rectified several linting errors that emerged in the process.
The project has transitioned from using setup.py/setup.cfg to pyproject.toml, making the build process more seamless.
I've included a handy Makefile to handle commonly performed tasks.
The requirements.txt file has been updated to feature the latest dependencies.
I've also introduced a requirements-dev.txt file, which will exclusively contain development dependencies.
The Github-action.yml file has been updated in line with the changes mentioned above.

On the whole, these modifications should add more value to your project for its users, including myself! Thanks for offering such an excellent product to the community.

Hello,
Thank you for the PR !
I don't know if @rosenpin will have time to review it, so I did a first quick reading.
it looks good to me (I still haven't had time to check installation and running  in my computer).
However, I don't get the "CLI isolation" thing you're talking about in your first patch ? Could you expand a bit about what was the problem and what you did to correct it ?

Hey @matclab, thanks for taking the time to look at the PR!
So, about the "CLI isolation" term—yeah, maybe it wasn't the most straightforward way to describe it. Here's what I meant:
Before, the recommended way to install i3-agenda involved installing all the system dependencies globally using sudo pip install .... This could potentially mess up users' systems due to dependency collisions. Alternatively, users could set up their own venv, but that's kind of overkill just to run a CLI tool, right? And even that approach required some tweaks in the source code.
Now, thanks mainly to the absolute imports (and probably others changes as well) I've added, you can actually install i3-agenda in a virtual environment without any changes to the source code. Even better, you can use pipx for an isolated CLI experience.
So, that's what I meant by "CLI isolation"—making it simpler and safer for users to install and use the tool without affecting their entire system.
Hope this clears things up!

Hello and thank you for the PR
I unfortunately won't have any availability to help with it in the foreseeable future due to some personal issues, but whatever @matclab says goes as far as I'm concerned.

Hey @matclab, thanks for taking the time to look at the PR!

…

Hope this clears things up!

Yes, thanks a lot.
I tried installation via modified AUR package using
python -m  build
python -m installer --destdir="$pkgdir" dist/*.whl

and installation works like a charm.
@mmngreco perhaps update the Download url with the last version, and update the Makefile accordingly to also change this line (or perhaps pyproject syntax allow the reuse of the version as a variable in the rest of the pyproject.toml  ?)  ?
As far as I concerned once this is corrected, we should merge this PR.
Thank you @mmngreco for this welcomed improvement !

I'd love to see you enjoying it, @matclab!

perhaps pyproject syntax allow the reuse of the version as a variable in the rest of the pyproject.toml ?

Unfortunately, it doesn't...

perhaps update the Download url with the last version, and update the Makefile accordingly to also change this line?

How about using https://github.com/rosenpin/i3-agenda/releases/latest instead? That is, unless you want to explicitly point out each release.

I will take care of the correct version of typing_extensions. ;-)

It seems that the latest version of typing-extensions compatible with Python 3.7 is typing-extensions==4.7.1.
https://pypi.org/project/typing-extensions/4.7.1/
I'll make this change, and it should then pass the CI.

Regarding the failed job 3.10:
Run pytest tests --junitxml=../junit/test-results.xml
Error: An error occurred trying to start process '/usr/bin/bash' with working directory '/home/runner/work/i3-agenda/i3-agenda/./i3_agenda'. No such file or directory

I will look into this; it appears to be a problem with the directories.


CMake and pkg-config files are missing from miniz-2.2.0.zip

miniz-2.2.0 ChangeLog.md mentions CMake and pkg-config support, no such files are included in the release ZIP archive miniz-2.2.0.zip.

The other (source code) ZIP file doesn't work?

V Wed, Aug 11, 2021 at 12:34:12PM -0700, Martin Raiber napsal(a):

The other (source code) ZIP file doesn't work?

The other 2.2.0.zip and 2.2.0.tar.gz work. Probably because they are git
snapshots while miniz-2.2.0.zip is a release archive.


example code?

do you want some examples? I'm happy to work on several of the cases - rasterio, odc-geo, rioxarray, and maybe the raster_tools and geoutils.
I'm interested to show how I would go about this, and discuss the various idioms available for GDAL (and how those are seen via various downstream packages).
At any rate I'm keen to discuss so I hope this is welcome.
osgeo.gdal
Here I'm using GDAL syntax for "vrt://" which saves us from some more awkward changes on Open() or via VRT otherwise.

## the file is here
#srcurl = "https://archive.podaac.earthdata.nasa.gov/podaac-ops-cumulus-protected/MUR-JPL-L4-GLOB-v4.1/20020601090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc"

## and it's best to fix the extent, else the warper goes a less efficient pathway (from the imprecise lon,lat arrays)
## https://discourse.pangeo.io/t/fixing-ghrsst-seeking-opinions/3833/6?u=michael_sumner
#dsn = f'vrt:///vsicurl/{srcurl}?a_ullr=-179.995,89.995,180.005,-89.995&sd_name=analysed_sst'

## we need earthdata creds, which I have in a file so
#import os
#os.environ["GDAL_HTTP_HEADER_FILE"] = "/home/mdsumner/earthdata"

## if we don't want to stream, we can ignore everything above (maybe this is in our earthaccess_data/)
dsn = f'vrt://20020601090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc?a_ullr=-179.995,89.995,180.005,-89.995&sd_name=analysed_sst'
## what's our target tile?  (we want native res I expect so we won't supply any other args)
te = [100, -60, 100 + 256/100, -60 + 256/100]  ## probably I need to be more careful to align to source pixel edges

from osgeo import gdal
gdal.UseExceptions()
ds = gdal.Open(dsn)
## we can get a "live" dataset or virtual one "/vsimem" or an actual file
wds = gdal.Warp("/tmp/tile.tif", ds, outputBounds = te)
wds.RasterXSize
#256
wds.RasterYSize
#256
wds.GetDescription()
#'/tmp/tile.tif'
wds.GetGeoTransform()
# (100.0, 0.010000000000000009, 0.0, -57.44, 0.0, -0.010000000000000009)

I'm very very new to profiling in python ... but I adapted the above approach to write the single zoom 0 tile from a MURSST to a png. (It won't be fully correct for scaling and so on, but I think it's probably representative of what should be possible).
Interestingly it seems to take more memory to write to PNG compared to TIF which I think is worth exploring.
Write to png.
from memory_profiler import profile

dsn = f'vrt://../earthaccess_data/20020601090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc?a_ullr=-179.995,89.995,180.005,-89.995&sd_name=analysed_sst&scale=-26800.000,7988.000&a_srs=EPSG:4326'

from osgeo import gdal
gdal.UseExceptions()

@profile
def run_tile0(dsn):
  te = [-20037508.342789244, -20037508.342789244, 20037508.342789244, 20037508.342789244]
  ds = gdal.Open(dsn)
  wds = gdal.Warp("/tmp/tile.png", ds, outputBounds = te, dstSRS = "EPSG:3857", width = 256, height = 256, outputType = gdal.GDT_Byte)
  return 1

if __name__ == '__main__':
    run_tile0(dsn)

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
    13    129.1 MiB    129.1 MiB           1   @profile
    14                                         def run_tile0(dsn):
    15    129.1 MiB      0.0 MiB           1     te = [-20037508.342789244, -20037508.342789244, 20037508.342789244, 20037508.342789244]
    16    140.9 MiB     11.8 MiB           1     ds = gdal.Open(dsn)
    17   2153.4 MiB   2012.5 MiB           1     wds = gdal.Warp("/tmp/tile.png", ds, outputBounds = te, dstSRS = "EPSG:3857", width = 256, height = 256, outputType = gdal.GDT_Byte)
    18   2153.4 MiB      0.0 MiB           1     return 1

Write to tif uses less memory (not so helpful, but maybe worth writing to /vismem/.tif and then writing that out to PNG).
from memory_profiler import profile

dsn = f'vrt://../earthaccess_data/20020601090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc?a_ullr=-179.995,89.995,180.005,-89.995&sd_name=analysed_sst&scale=-26800.000,7988.000&a_srs=EPSG:4326'

from osgeo import gdal
gdal.UseExceptions()

@profile
def run_tile0(dsn):
  te = [-20037508.342789244, -20037508.342789244, 20037508.342789244, 20037508.342789244]
  ds = gdal.Open(dsn)
  wds = gdal.Warp("/tmp/tile.tif", ds, outputBounds = te, dstSRS = "EPSG:3857", width = 256, height = 256, outputType = gdal.GDT_Byte)
  return 1

if __name__ == '__main__':
    run_tile0(dsn)

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
    13    126.8 MiB    126.8 MiB           1   @profile
    14                                         def run_tile0(dsn):
    15    126.8 MiB      0.0 MiB           1     te = [-20037508.342789244, -20037508.342789244, 20037508.342789244, 20037508.342789244]
    16    138.3 MiB     11.5 MiB           1     ds = gdal.Open(dsn)
    17    572.9 MiB    434.6 MiB           1     wds = gdal.Warp("/tmp/tile.tif", ds, outputBounds = te, dstSRS = "EPSG:3857", width = 256, height = 256, outputType = gdal.GDT_Byte)
    18    572.9 MiB      0.0 MiB           1     return 1

``

so at any rate, I don't think you should see a 12Gb spike ever.

Your contributions are super welcome, thank you @mdsumner! It's helpful to know that fixing the input coordinates can improve efficiency.
I think your results are roughly similar to what I saw using gdal with vsis3. Those preliminary results are in the table at the bottom of https://github.com/developmentseed/warp-resample-profiling/blob/add-prelim-results/02-process-profiling-results.ipynb. The memory usage was manageable, but the wall-time was rather slow. Was that in line with your experiences working with this data?

ah I see, I have a lot to do to get across your workings here. The thing that I thought I understood from here https://developmentseed.org/tile-benchmarking/02-run-tests/06-cmr-netcdf.html  is that the 12Gb spike in memory (final plot on the page) was the concern.
My general timing benchmark is 3min to convert an entire file to COG (on compute in Australia).   To do that one worst zoom=0 tile is about 30-40s, and so I guess that makes sense as each layer is subdivided with many smaller much more manageable tasks we add up to a few minutes.
The timing for that worst tile seems reasonable to me, given that it's  from a poorly structured archival format, 36000x17999->256x256.

@mdsumner I haven't been able to get the vsicurl approach from the commented out section of your first comment to work. Would you be willing to take a look at https://github.com/developmentseed/warp-resample-profiling/blob/vsicurl/examples/load-gdal-netcdf-vsicurl.ipynb to let me know where I'm going wrong? I reduced the example to just the failing load component.
Using vsis3 works...I expect I'm doing something wrong with the authentication.

Maybe your GDAL version doesn't support those args for vrt:// syntax?
I'll check, and maybe rewrite it so it's generic to older versions.

Oh, you have rewritten it in that second one. I'll have a look 😸

In the second one you are setting the extent and crs of the target, not the opened dataset. So the warp is still (possibly problematically) reading from the 1D geolocation arrays context.  I didn't actually know we could treat this source as s3 so I'll be exploring that also! 👌


Fix cbor cid serde

The zero byte prefix inside the length delimited byte array was not omitted or added.

LGTM

I haven't understood the why yet. Is this part of the cbor or the dag cbor spec? Or is this a bug in the go implementation?

@dvc94ch Part of the DagCBOR spec as linked in the source: https://github.com/ipld/specs/blob/51eb2f682f554b726021f34398843f8edf97bbd0/block-layer/codecs/dag-cbor.md#links. The CID is Multibase encoded, hence has a 0x0 prefix.

I'm pretty sure that section was added after implementing this version. We'll have to live with "historical reasons" then...

Now that that convo is resolved, ok to merge @dvc94ch ?


[SPARK-22683][CORE] Add tasksPerExecutorSlot parameter

What changes were proposed in this pull request?
let's say an executor has spark.executor.cores / spark.task.cpus taskSlots
The current dynamic allocation policy allocates enough executors
to have each taskSlot execute a single task, which wastes resources when
tasks are small regarding executor allocation overhead. By adding the
tasksPerExecutorSlot, it is made possible to specify how many tasks
a single slot should ideally execute to mitigate the overhead of executor
allocation.
How was this patch tested?
Units tests and runs on various actual workloads on a Yarn Cluster

Can one of the admins verify this patch?

Please see JIRA. I don't think this is worth doing.

Can one of the admins verify this patch?

ping @jcuquemelle  can you update this?

Sorry, I didn't see the ping, I will have a look shortly.

The new semantics (throttling w.r.t max possible parallelism) is actually simpler to understand. I'm proposing another name which doesn't have any ambiguity with the existing maxExecutors param, but I'm open to any other name proposal.

jenkins, test this please

Test build #88180 has started for PR 19881 at commit 56c3f43.

Test build #88180 has finished for PR 19881 at commit 56c3f43.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/88180/
Test FAILed.

@jcuquemelle  please fix the style

@felixcheung: updated PR title and description

jenkins, test this please

Test build #88472 has started for PR 19881 at commit a40d160.

Test build #88472 has finished for PR 19881 at commit a40d160.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/88472/
Test PASSed.

just minor comment about the test otherwise looks good.

+1

cc @rxin

I'll leave this a bit longer but then I'm going to merge it later today

Can you wait another day? I just find the name pretty weird. Do we have
other configs that use the “divisor” suffix?
On Wed, Mar 28, 2018 at 7:23 AM Tom Graves<EMAIL_ADDRESS>wrote:

I'll leave this a bit longer but then I'm going to merge it later today
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/spark/pull/19881#issuecomment-376905017, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AATvPOFekjRxMQwLNeHMCtxZt92Fv3YGks5ti5z8gaJpZM4Q1Frd
.

Yes we can wait another day or so if you are looking at it, this discussion has been going on for a long time now though, if you have a better name suggestion let us know.  No other configs have "divisor" suffix.s

more aggressive must be forbidden, because the setting of 1.0 gives enough executors so that if the executor provisioning was perfect (e.g. all executors were available at the same time) and the mapping of tasks to executors was optimal, each executor core (or taskSlot as in the original naming) would process exactly one task. If you ask for more executors, you're sure they will be wasted.
Which is why it felt natural to have a divisor semantics, because it implies the parameter can only be used to reduce parallelism.
How about fullParallelismThrottlingRate ?

@rxin I assume you are just trying to not use divisor since its not used anywhere else?  As @jcuquemelle state I don't see a use case for this to be made more aggressive if you have one please let us know, but otherwise it just wastes resources.
Personally I still like divisor because that is what you are doing.  I don't think because its not in any other configs is a good reason to not use it.   Looking at I don't see any public configs that have factor in the name of them either.  I am not fond of rate because its not a rate (ie how quickly/slowly you are allocating), its a limit on max number of executors.
I also think its more natural for people to think of this as a divisor vs a multiplier.  if I want 1/2 of the executors you divide by 2.   I think we should name it based on what is most likely understood by the end user.

SGTM on divisor.
Do we need "full" there in the config?

No we don't strictly need it in the name, the reasoning behind it was to indicate that this was a divisor based on if you have fully allocated executors for all the tasks and were running full parallelism.
Are you suggesting just use spark.dynamicAllocation.executorAllocationDivisor?  other ones thrown are were like maxExecutorAllocationDivisor.  One thing we were trying to keep from doing is confusing it with the maxExecutors config as well.  Opinions?

I thought about this more, and I actually think something like this makes more sense: executorAllocationRatio. Basically it is just a ratio that determines how aggressive we want Spark to request full executors. Ratio of 1.0 means fill up everything. Ratio of 0.5 means only request half of the executors.
What do you think?

I'm fine with that

Ok, will quickly do the change
thanks for the proposals

Test build #89467 has started for PR 19881 at commit 15732ab.

Thanks @jcuquemelle

Test build #89467 has finished for PR 19881 at commit 15732ab.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89467/
Test PASSed.

Test build #89712 has started for PR 19881 at commit 3b1dddc.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89712/
Test PASSed.

+1


Adding an extra docker-compose file decoupling OpenMetadata components from the ingestion engine

Changes
Adds an alternative docker-compose file without the ingestion framework.
Reasons
Separating out the installation of the ingestion framework is helpful:

to separate out dependencies required to run the metadata ingestion workflows from dependencies required to run the OpenMetadata application (metadata store, UI and API server)
to defer the choice of the orchestrator allowing users to choose whether they opt for a specific open-source orchestration or scheduling platform, a hosted solution, or even simple CLI ingestion jobs scheduled with CRON
to provide more flexibility, easier maintenance and an even easier way to get started with OpenMetadata due to reduced complexity when getting started.

Impact
This PR doesn't introduce any breaking changes as it adds an alternative docker-compose file without overwriting the existing one.
Additional changes

Adds prefect_ingestion to make ingestion via a Prefect flow easier.
Adds log_flow_status to allow viewing metadata ingestion logs from the Prefect UI.

Type of change

[x] New feature

Checklist:

[x] I have read the CONTRIBUTING document.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] All new and existing tests passed.

@anna-geller let us know if you need any further details to get his patch merged.

I thought about it and I will indeed follow your advice and create a Prefect Collection, i.e. a separate Python library for that integration to make it easier to manage dependencies and make everything more modular and pluggable. Once that's done I will submit another PR to reflect the usage of this new library in the docs. Thanks for catching up on this, I'll close this issue for now.


Update Spanish (Latin America) Localization

Describe the feature you want the app to have that it currently doesn't

Since the Spanish localization was added to the project new strings have been added
Update to 100% coverage

Describe alternatives you've considered

N/A

Additional context

Currently at 88% coverage at the time of creating the issue

Hello! I want to help with this issue :)

You got it!

Hi, if the original assignee is no longer up for this task, I would like to step in

@krz it is up to you, running the project you'll see the Spanish translation is only 50% complete, and the PR you linked is from Oct 5, and the project has changed drastically since then.
You could do the update to Spanish and/or add Dutch

Closing this, because it doesn't need to be an issue, anyone is welcome to update any language whenever


Moya 9 Beta breaks parameters with all requests

Using Moya 9.0.0 Beta 1 version and since that, Moya will ignore and discard all parameters built in TargetType task. This is a breaking change, requiring to revert back to version 8.x.x, as it is useless for any API that requires parameters:
enum User {
    case register([String : Any])
    case ping
}

extension User : TargetType {
    var task: Task {
        switch self {
            case .register(let parameters):
                // All parameters here are ignored.
                return .requestParameters(parameters: parameters, encoding: JSONEncoding.default)
            default:
                return .requestPlain
        }
}

What is the solution for this? Exploring MoyaProvider+Internal shows that the only time Moya will call to Task type is at line 96:
switch target.task {
    case .requestPlain, .requestData, .requestParameters, .requestCompositeData, .requestCompositeParameters:

Since this task is a Swift Enum returning parameters, here they are completely ignored. I was unable to find any other code that would call to .requestParameters task type.
How to solve this?

@Legoless The parameters get applied inside of the provider's requestClosure.
It is set to MoyaProvider.defaultRequestMapping by default.
It does this by calling the urlRequest property on Endpoint.

I created the Endpoint manually, and apparently with old API, this was not required, but with new, default will always be .requestPlain. Might be a good idea to remove default parameter, since I just wasted 3 hours figuring this out, why it doesn't work. Since task is still called again from the internal code, it can quickly be confusing where this is applied. Issue can be closed. :) Sorry.

@Legoless this is a great idea. In fact, I think we should remove all default parameters from Endpoint.init as all of them might get confusing. Would you be up for a PR maybe? :)
It will be a breaking change, but I think this is for a good cause.

I agree, let's remove them so no one else faces this issue. @Legoless Thanks for the feedback and sorry for the confusion!

@sunshinejr Do you think there's any value in making the urlRequest property throwing and then propagating the parameter encoding errors? Since defaultRequestMapping just converts a URLRequest to a Result<URLRequest,Error> we can pass on this information quite easily here. Just on my mind from looking at this part of the code.

@SD10 seems like it would be quite helpful! If you have some free time to research this one I think it would be a great update of our error handling 👍

Closing this in favor of #1249

Hi, I think I encountered similar problem when upgrade from 8 -> 11,  task never getting call when I  trying to debug.
// MyAPI_TargetType.swift
 public var task: Task {
        return .requestPlain
    }

// API_Provider.swift
var endPoint = Endpoint(url: url, sampleResponseClosure: {.networkResponse(200, target.sampleData)},
                                method: target.method, task: Task.requestParameters(parameters: target.parameters!,
                                                                                encoding: target.parameterEncoding), httpHeaderFields: httpHeader)


removed CC054 support and replaced it with support for CC014

Could the conf/xsd/CC054A.xsd file be removed now?

👍


gui-client: Check for updates periodically via website API endpoint and notify in menubar icon and menu

Is your feature request related to a problem? Please describe.
It would be nice if the gui-client could show that there is a new version available, or even better just install it (or provide apt repo so it gets updated with my system)
Describe the solution you'd like
i want to keep my system up2date
Describe alternatives you've considered
none
Additional context
Using the gui-client on PopOS (Ubuntu 22.04 derivative)

Right now it should check at startup and show a pop-up like this

We could do that check more often, maybe once a day?
Self-assigning so the issue has an assignee

Hmm yeah... I never see these notifications, Linux systems have so many notifications that I usually miss these... I was thinking something in the menu of firezone? Maybe like slack (and others do) with a blue/red dot on the icon so you know something requires attention.

I'll update this issue to mark it as a feature. @ReactorScram I'm wondering if it makes sense to add a simple JSON or API endpoint to the website that tracks versions, perhaps from the changelog page. That will keep bandwidth minimized if we're going to scale this out across all users.

@jamilbk We could but I don't think it's needed. Right now we just do a HEAD request and then parse the Location header, which is about 110 bytes, Adding a response body could shrink it a little bit, but the TLS certs are already bigger than that.
I'm thinking:

Run a stress test with like 10,000 requests, representing 1 day of 10,000 Clients checking once per day
If the website can handle that, just have the Clients pick a random time of day at startup (to avoid everyone checking at 9:00 US time) and then check daily
If the website can't handle that, see if we can do it through the WebSocket connection to the portal. Then we can re-use the TLS connection and skip HTTP overhead if we're really trying to squeeze for individual bytes.

Website should be able to handle that no problem.

Now that #5817 has merged, we could build on top of this, maybe show a ! exclamation mark if an update is ready to download


Revert "formula_installer: set specified_path on pour."

Reverts Homebrew/brew#1847
I'm not sure this was such a good idea. I think we'll want to be able to unalias things in the future but this will have the consequence of making aliases permanent, which doesn't really make sense.

I'm not sure this was such a good idea.

This just makes the behaviour consistent when pouring bottles for https://github.com/Homebrew/brew/pull/971 which was merged pre-1.0.0 so I don't think we can just revert this behaviour.

I think we'll want to be able to unalias things in the future but this will have the consequence of making aliases permanent, which doesn't really make sense.

If we wish to avoid making aliases permanent that can be what's fixed instead. We still need this functionality for versioning.

If we wish to avoid making aliases permanent that can be what's fixed instead. We still need this functionality for versioning.

Which functionality exactly?

Which functionality exactly?

Not making this make aliases permanent i.e. if the tab-referenced alias is missing then handle that gracefully.

I don't see why we need to alias it at all. Why not just have brew install gcc@6 work without creating or storing an alias?

I don't see why we need to alias it at all. Why not just have brew install gcc@6 work without creating or storing an alias?

Having brew install foo@1 install foo when they aren't named the same is an alias whether we store it on disk or not. I'd prefer to keep such aliases machine readable data rather than an implementation detail.

So you'd prefer to do alias bookkeeping even if it could be avoided?

Yes, I'd prefer not introducing a new alias system that breaks existing assumptions about how our aliases work. If there's too much busywork: that's something that can be automated/scripted.

Yes, I'd prefer not introducing a new alias system that breaks existing assumptions about how our aliases work.

I don't think anyone has an "existing assumption" that
brew install ag
brew install the_silver_searcher

is the same thing as
brew install gcc@6
brew install gcc

It would also be nice if this "just worked" for all formulae without making users learn, lookup, or remember which formulae are "non-versioned counter-parts of versioned formulae" (wow we need a word for that) and which are not.

People have existing (correct) assumptions that brew install foo means foo is either the name of a formula file or an alias.

It would also be nice if this "just worked" for all formulae without making users learn, lookup, or remember which formulae are "non-versioned counter-parts of versioned formulae" (wow we need a word for that) and which are not.

It would be nice and we can do that longer-term but that's significantly more involved so passing on it for now.
It's been (genuinely) a good discussion but passing on this revert for now. I'll make a note to address the problems you've addressed but we've already been writing tabs this way since September so can't just back it out now.

Can the branch for this be deleted now?


Service Worker Cache Expiration

I noted after sucesive improvements at https://mythbusters.js.org the website cached a old version of the web and it's necessary a hard refresh for fetch the new version.
Could be interesting implement a way to auto-expire the cache after a period of time (for example, 5 day).

@Kikobeats Could you update the docsify code on your end and check if problems still persist? You don't need the extra sw js file anymore. Compare the ./docs folder and the contained ./docs/index.html file here.

This would be good to make configurable as an option that can be passed to service worker. We should make a service worker file be consumable instead of it being embedded in the docs.


Exceptions when enabling portainer

Summary
When enabling the portainer addon in a our tests (https://github.com/canonical/microk8s-community-addons/actions/runs/5820285792/job/15881038615) the following error appears:
2023-08-14T16:22:29.8461520Z Infer repository community for addon portainer
2023-08-14T16:22:40.3430883Z Traceback (most recent call last):
2023-08-14T16:22:40.3431757Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 114, in <module>
2023-08-14T16:22:40.3432938Z     main()
2023-08-14T16:22:40.3433756Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
2023-08-14T16:22:40.3434379Z     return self.main(*args, **kwargs)
2023-08-14T16:22:40.3435016Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 717, in main
2023-08-14T16:22:40.3435503Z     rv = self.invoke(ctx)
2023-08-14T16:22:40.3436245Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
2023-08-14T16:22:40.3436824Z     return ctx.invoke(self.callback, **ctx.params)
2023-08-14T16:22:40.3438162Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
2023-08-14T16:22:40.3438765Z     return callback(*args, **kwargs)
2023-08-14T16:22:40.3439256Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 80, in main
2023-08-14T16:22:40.3440072Z     ensure_addon(metric_server_addon)
2023-08-14T16:22:40.3441007Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 35, in ensure_addon
2023-08-14T16:22:40.3441537Z     output = subprocess.check_output(
2023-08-14T16:22:40.3442066Z   File "/snap/microk8s/5764/usr/lib/python3.8/subprocess.py", line 415, in check_output
2023-08-14T16:22:40.3442630Z     return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
2023-08-14T16:22:40.3443204Z   File "/snap/microk8s/5764/usr/lib/python3.8/subprocess.py", line 516, in run
2023-08-14T16:22:40.3444124Z     raise CalledProcessError(retcode, process.args,
2023-08-14T16:22:40.3445039Z subprocess.CalledProcessError: Command '['/snap/microk8s/5764/microk8s-status.wrapper', '-a', 'core/metrics-server']' returned non-zero exit status 1.
2023-08-14T16:22:44.1902749Z Infer repository community for addon portainer
2023-08-14T16:22:44.9644588Z Traceback (most recent call last):
2023-08-14T16:22:44.9645122Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 114, in <module>
2023-08-14T16:22:44.9645467Z     main()
2023-08-14T16:22:44.9646166Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
2023-08-14T16:22:44.9647252Z     return self.main(*args, **kwargs)
2023-08-14T16:22:44.9647806Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 717, in main
2023-08-14T16:22:44.9648198Z     rv = self.invoke(ctx)
2023-08-14T16:22:44.9648728Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
2023-08-14T16:22:44.9649208Z     return ctx.invoke(self.callback, **ctx.params)
2023-08-14T16:22:44.9649759Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
2023-08-14T16:22:44.9650171Z     return callback(*args, **kwargs)
2023-08-14T16:22:44.9650602Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 68, in main
2023-08-14T16:22:44.9650980Z     ensure_addon(dns_addon)
2023-08-14T16:22:44.9651416Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 35, in ensure_addon
2023-08-14T16:22:44.9651855Z     output = subprocess.check_output(
2023-08-14T16:22:44.9652291Z   File "/snap/microk8s/5764/usr/lib/python3.8/subprocess.py", line 415, in check_output
2023-08-14T16:22:44.9652743Z     return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
2023-08-14T16:22:44.9653206Z   File "/snap/microk8s/5764/usr/lib/python3.8/subprocess.py", line 516, in run
2023-08-14T16:22:44.9653649Z     raise CalledProcessError(retcode, process.args,
2023-08-14T16:22:44.9654393Z subprocess.CalledProcessError: Command '['/snap/microk8s/5764/microk8s-status.wrapper', '-a', 'core/dns']' returned non-zero exit status 1.
2023-08-14T16:22:48.7068857Z Infer repository community for addon portainer
2023-08-14T16:22:49.4905494Z Traceback (most recent call last):
2023-08-14T16:22:49.4907078Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 114, in <module>
2023-08-14T16:22:49.4907784Z     main()
2023-08-14T16:22:49.4909007Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
2023-08-14T16:22:49.4909774Z     return self.main(*args, **kwargs)
2023-08-14T16:22:49.4910681Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 717, in main
2023-08-14T16:22:49.4911758Z     rv = self.invoke(ctx)
2023-08-14T16:22:49.4913884Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
2023-08-14T16:22:49.4914563Z     return ctx.invoke(self.callback, **ctx.params)
2023-08-14T16:22:49.4915380Z   File "/snap/microk8s/5764/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
2023-08-14T16:22:49.4915976Z     return callback(*args, **kwargs)
2023-08-14T16:22:49.4917101Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 68, in main
2023-08-14T16:22:49.4917654Z     ensure_addon(dns_addon)
2023-08-14T16:22:49.4918283Z   File "/var/snap/microk8s/common/addons/community/addons/portainer/enable", line 35, in ensure_addon
2023-08-14T16:22:49.4918927Z     output = subprocess.check_output(
2023-08-14T16:22:49.4919556Z   File "/snap/microk8s/5764/usr/lib/python3.8/subprocess.py", line 415, in check_output
2023-08-14T16:22:49.4920221Z     return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
2023-08-14T16:22:49.4920890Z   File "/snap/microk8s/5764/usr/lib/python3.8/subprocess.py", line 516, in run
2023-08-14T16:22:49.4922086Z     raise CalledProcessError(retcode, process.args,
2023-08-14T16:22:49.4923201Z subprocess.CalledProcessError: Command '['/snap/microk8s/5764/microk8s-status.wrapper', '-a', 'core/dns']' returned non-zero exit status 1.

This is probably because the prerequisite addons (eg dns) cause the snap services to be restarted. We probably need a silent retry when enabling the addons.

@testA113 have you seen this issue?


WAL can't correctly handle more than 1 million segments

The segments are created in files with names following %08d, and checkpoints %06d. We take a  list of checkpoints/files sorted as strings, but that's not going to work once there's more than 1M segments. We should do our own sorting based on the number, and also use consistent formatting between checkpoints and segments.
We're also using ioutil.ReadDir in one place and our own fileutil.Readdir on top of Readdirnames in another, we should unify this on ioutil.Readdir rather than inventing our own thing.

Closed by https://github.com/prometheus/prometheus/pull/6987 and created https://github.com/prometheus/prometheus/issues/7029 for fileutil.Readdir


Fix link to capabilities in README.md

When viewing in github's source view, the link from README.md to capabilities documentation takes you to https://github.com/google/capslock/blob/main/docs/docs/capabilities.md which does not exist.

Thanks!


chore: update app version in helm-chart to v0.5.3

Updates chart to latest released version of nidhogg.

Closing, as I see https://github.com/pelotech/nidhogg/pull/15 is pending for merge.

I'm closing this PR @bersalazar, we’re changing the flow a bit to not have to maintain versions. Changes are:

from now on, chart.yaml will not contain the version information
the release pipeline will helm package with a helm chart version based on tag events
renovate will auto-merge any container tag version bump for Kustomize (helm chart getting already the version bump through the release pipeline)


Replacing CAPC commit hash with tag

Issue #, if available:
Description of changes:
EKS-A e2e tests failed when using the commit hash with clusterctl init with error message
    cluster.go:677: Command eksctl anywhere [create cluster -f release-i-06a23-1ff28bb/cluster.yaml -v 4 --bundles-override bin/local-bundle-release.yaml] failed with error: exit status 255: Error: failed to get provider components for the
"cloudstack:c0d5e8d3735f2dace5997ed9515e437a5ec30a6a+e3b0c44" provider: failed to get repository client for the InfrastructureProvider with name cloudstack: error creating the local filesystem repository client: invalid version:
"c0d5e8d3735f2dace5997ed9515e437a5ec30a6a+e3b0c44". Version must obey the syntax and semantics of the "Semantic Versioning" specification (http://semver.org/) and path format {basepath}/{provider-name}/{version}/{components.yaml}

So we need to use a tag instead. I've added a note in the readme to hopefully prevent this issue from happening again in the future
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/cherrypick release-0.10

/retest


Add Zfinx spec

This PR contributes a new chapter to the unprivileged spec that describes the Zfinx, Zhinx, and Zdinx extensions, which add floating-point instructions that operate on the x-registers.

This was manually merged a few weeks ago.


Add missing blockheight and received_at fields to listvaults

received_at is not null to keep consistency with blockheight, we might
want to fix that in the future.
Closes #98

Are there any edge cases where timereceived in gettransaction could change for an unconfirmed tx? I don't think so but I'm quite unsure

No, in bitcoind the timereceived is set at reception and never changed afterward. time may be changed though.

Arg the functional tests are deadlocking somewhere..

ACK a82d319
Tested with a small sanity blackbox test:
diff --git a/tests/test_misc.py b/tests/test_misc.py
index e79826b..970ab74 100644
--- a/tests/test_misc.py
+++ b/tests/test_misc.py
@@ -37,6 +37,7 @@ def test_listvaults(revaultd_manager, bitcoind):
     assert vault_list[0]["amount"] == amount_sent * 10 ** 8
     assert vault_list[0]["address"] == addr
     assert vault_list[0]["derivation_index"] == 0
+    assert vault_list[0]["updated_at"] == vault_list[0]["received_at"]

     # Generate 5 blocks, it is still unconfirmed
     bitcoind.generate_block(5)
@@ -47,7 +48,9 @@ def test_listvaults(revaultd_manager, bitcoind):
     # 1 more block will get it confirmed
     bitcoind.generate_block(1)
     revaultd_manager.wait_for_log(f"Vault at .*{txid}.* is now confirmed")
-    assert revaultd_manager.rpc.call("listvaults")["vaults"][0]["status"] == "funded"
+    vault = revaultd_manager.rpc.call("listvaults")["vaults"][0]
+    assert vault["status"] == "funded"
+    assert vault["updated_at"] > vault["received_at"]

     # Of course, it persists across restarts.
     revaultd_manager.rpc.call("stop")


observers must be declared as set

private val observers = mutableListOf() // in this line use of mutableSetOf is needed
override fun observe(observer: Observer) {
observers.add(observer)//'cause you can add same observer many times
}

Thank's) It's OK!


Offload cache

Not sure if this is an mac / mps thing, but I'm still getting memory out of bounds errors when loading activations to cpu. Should probably open a separate issue for dynamically writing / loading activations to and from disk


NIFI-13495: PutChroma 'unexpected keyword argument' error

Summary
NIFI-13495
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[x] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[x] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[x] Pull Request based on current revision of the main branch
[x] Pull Request refers to a feature branch with one commit containing changes

@krisztina-zsihovszki The initial commit to this repository does not have an associated signature. As a new repository, signed commits are required. If you can sign the commit and push an update, I can proceed to merge.

@exceptionfactory Please check if the forced pushed commit is signed properly.

Thanks for updating the branch with the signed commit @krisztina-zsihovszki, looks good!


Feature/center potentials

Center the f potential in the balanced case for Sinkhorn.
Also remove the default momentum.
partially addresses #185

Codecov Report

Merging #194 (394b557) into main (5a0078f) will decrease coverage by 0.05%.
The diff coverage is 86.84%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #194      +/-   ##
==========================================
- Coverage   89.37%   89.32%   -0.06%
==========================================
  Files          52       52
  Lines        5243     5265      +22
  Branches      531      535       +4
==========================================
+ Hits         4686     4703      +17
- Misses        430      433       +3
- Partials      127      129       +2

Impacted Files
Coverage Δ

src/ott/geometry/grid.py
91.66% <ø> (ø)

src/ott/geometry/low_rank.py
96.42% <ø> (ø)

src/ott/geometry/graph.py
91.92% <83.87%> (-2.49%)
:arrow_down:

src/ott/solvers/linear/sinkhorn.py
97.88% <100.00%> (+0.03%)
:arrow_up:


[HOPS-1093] Fixing NPE in Lease Manager caused by HOPS-1031

Make sure there is no duplicate PR for this issue

Please check if the PR fulfills these requirements

[ ] Tests for the changes have been added and passed (for bug fixes / features)
[x] HOPS JIRA issue has been opened for this PR
[x] All commits have been squashed down to a single commit
[x] The commit message has the following format: [HOPS-XXX] message

Post a link to the associated JIRA issue
https://hopshadoop.atlassian.net/projects/HOPS/issues/HOPS-1093

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
bugfix

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:

Can one of the admins verify this patch?

Jenkins test this please.

This break org.apache.hadoop.hdfs.server.namenode.TestLeaseManager

Please re-run the tests. I have updated the code

Jenkins test this please.


Fully Adopt Prometheus/common HTTPClient in Consul SD

This PR fully adopts common's HTTPClient into the Consul SD.
Fixes #8924

Can you rebase this? Thanks!

I have tested this against consul.
Thanks!


Tekla: Fittings should not inherit from Plane, to prevent ToNative from  converting them as such.

Description
Everything from Tekla was sent and received back in Grasshopper during 2.9 testing. Some elements were received as planes instead of base objects. After some examination, it was determined that the elements causing the problem were the Tekla Fittings. See screenshots below👇:
Expected Behaviour
Receiving fittings as Base objects instead of Planes.
Steps to reproduce

Receive the commit below in Grasshopper
Connect a panel to the Base output and examine it.

Streams/Commits Used
https://latest.speckle.dev/streams/caec6d6676/commits/588c731104
Files Used
https://drive.google.com/drive/folders/1kUwuU1IUQM1yYDd4BxnrCo3MdQ5uWNZQ?usp=sharing
Screenshots

Closing this ticket as we are moving to Jira to reduce noise. You can access it there.