refactor(runtime): ♻  Organize & remove more occurencies of RuntimeError

What is the purpose of this Pull Request?

See Changesets for details.

Type of this Pull Request

🐛 Bug fix

♻  Code refactoring

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

38 of 45 (84.44%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.002%) to 95.904%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/runtime/source/scope/scopes/node.ts
1
2
50.0%

packages/runtime/source/variable/variable.ts
6
7
85.71%

packages/runtime/source/scope/name.ts
30
35
85.71%

Totals

Change from base Build<PHONE_NUMBER>:
-0.002%

Covered Lines:
3247

Relevant Lines:
3343

💛  - Coveralls


Enable aptX (HD) decoding support using standalone codec extracted from ffmpeg.

This is powered by a simple library ffaptx that I extracted from ffmpeg source code. I tested both aptX and aptX HD from my OnePlus 6, and it seems to be working fine.
I believe encoding support with this library can be added with little effort (and thus eliminate the need for openaptx library), but as I don't have a aptX receiver I can't test it. Hope somebody can implement it.

https://github.com/pali/libopenaptx also derives the aptx code from the FFmpeg project. Why another library?
Furthermore, the aptx decoder samples contain 24 bit signed integers stored as 32 bit signed integers. Your code right-shifts the 24 bit samples into 16 bit samples, am I right?

Using Raspbian Stretch (9.11) and default apt repositories I found this issue compiling ffaptx:
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.14 or higher is required.  You are running version 3.7.2`

So I had to upgrade it manually. This took more than an hour on a Pi 3.
After this, I configured it with ../configure --enable-aptx-sink --enable-aac --enable-ldac --disable-hcitop --with-alsaplugindir=/usr/lib/arm-linux-gnueabihf/alsa-lib but unfortunately my Mi 9T Pro won't connect to the sink.
Tested around with different combination of configurations and whenever I put --enable-aptx-sink the phone won't connect.
I'll check if could be something about my setup.

@joerg-krause I didn't notice that library before, but whatever :)
As for the 16-bit problem, bluez-alsa operates at 16-bit samples everywhere, so I have to change the sample to 16-bit. If not so, I would have to modify code throughout the project to make it 24-bit capable, which is a huge amount of work and seems unnecessary.
@dmcallejo I'll change the minimum CMake version required.
The volume problem might associate with the ignored aptX HD RTP header, I guess? I'll have a look soon. Meanwhile you can test whether the volume for aptX non-HD is working, as it doesn't contain RTP header.

After my previous observation (https://github.com/Arkq/bluez-alsa/issues/241#issuecomment-539116708) I found that a lot of parity check error happens at the time of the crackling noise and much much more error follows it. It stucks in the error.
To reproduce it just put the following code in the int ff_aptx_decode_samples(AptXContext *ctx,                                const uint8_t *input,                                int32_t samples[NB_CHANNELS][4]) function after ret = aptx_check_parity(ctx->channels, &ctx->sync_idx);
if(ret != 0)
{
    error("PARITY ERROR!!!");
}

The first parity error happens after 3-5 minutes of playing audio.
Isn't there an automatic error correction feature in bluetooth's data link layer?

@t123yh Downscaling 24-bit to 16-bit means you're losing quality.
@gpeter12 This probably means that you're not receiving all packets, so the aptx synchronization fails. You can add some synchronization handling, e.g. like pali did in his aptx decoder.

Hi @t123yh , I've been testing extensively the build and I can confirm that there's no bug with the volume control. I've used it for long sessions (4 hours of continuous play) and no problems at all.

Hi @t123yh,
I recently bought a new 24bit DAC for the RPi Zero W. Could you make it work without the right-shift in the io_thread_a2dp_sink_aptx_aptxhd() function? When I change the audio format in the aplay.c I get nothing but white noise (I used the SND_PCM_FORMAT_S24_3LE constant because that is what my DAC supports).
Thank you for your help.

@gpeter12 The internal of bluez-alsa uses 16bit samples. We will have to change all shorts to ints in order to enjoy 24-bit quality.
There's one thing I'm not very sure of: why this could not get merged. Maybe I should rebase it to the latest master?

There's one thing I'm not very sure of: why this could not get merged. Maybe I should rebase it to the latest master?

Firstly, sorry for not responding earlier :/. The reason why this PR has not been merged is mainly due to maintenance problem. This project for the last two years has been used commercially with the requirement of apt-X support. Unfortunately, ffmpeg can not be used in such way due to legal issues. In order to "allow" community to use apt-X encoding, there is a shim library openaptx, which implements commercial apt-X API (API is not a patent subject) - one needs to adopt open-source encoder to such API and you are ready to go (breaking the law, though). The problem with decoding is, that the API has not been publicly available and the only one I'm aware of is released under NDA.
So first of all switching to ffmpeg for encoding is not an option because it will make hard to maintain commercial forks. Secondly, I could mainstream decoding support but first of all I have to be sure that the API has been publicly released by Qualcomm so I'm not breaking NDA (more or less).
For apt-X HD there is also mentioned 24-bit issue. Some work has been already done by @killerkalamari, you might check his fork. However, I think that for dynamic bit-with support there is still a long way to go - mostly due to required architectural changes.

Does that mean it's best to close this PR and maintain a "illegal" fork myself?

I think that this PR might still be there, so if someone is looking for apt-X (HD), your fork could be easily found. Also, it will be a right place to notify subscribers about any progress with this feature :)

... Some work has been already done by @joerg-krause, you might check his fork. ...
I searched for the commit but i didn't find it. :(

Hello! My https://github.com/pali/libopenaptx has some fixes related to both encoding and decoding process, specially related to algorithm delay. Also in decoder I implemented simple rescue and re-synchronization. So funcionality in my libopenaptx should be better then in proprietary qualcom implementation. Also affected patents for this code already expired, so there should not be any legal problems with either using or redistributing libopenaptx code. If you found some problems in libopenaptx, please report issue to my repository.

@gpeter12 wrote:

Isn't there an automatic error correction feature in the data link layer of bluetooth?

I asked this question year ago on linux-bluetooth ML, see thread:
https://lore.kernel.org/linux-bluetooth/20190518190618.m7rdkthvpz4agxd2@pali/T/#u

If the answer is yes then how can I turn it on?

Nope, it should be turned off! Reliable sockets (like TCP) are unsuitable for real-time audio/video transports. If it is turned on then you would hear of of glitches, big and variable latency and have audio unsynchronized.
In real-time streaming it is up to the codec to do error correction, not for transport layer. Transport layer should be low latency and should not try to retransmit packets on error.
@joerg-krause wrote:

@gpeter12 This probably means that you're not receiving all packets, so the aptx synchronization fails. You can add some synchronization handling, e.g. like pali did in his aptx decoder.

Now I released a new version of libopenaptx 0.2.0 which contains new functions in libopenaptx.so library for synchronization support, so caller just needs to call new function and do not need to do anything with parity check or syncing. Also code for synchronization handling in libopenaptx is improved. I did simulation, took aptx stream, removed some bytes from random places and play it. And there is no crackling noise anymore.
So libopenaptx 0.2.0 implementation should be more suitable for bluetooth streaming (both encoder and decoder deals with algorithm delay and decoder supports synchronization) compared to ffmpeg implementation or proprietary qualcomm android implementation.
If you think that there is something missing in libopenaptx or have suggestions for improvement, please let me know.

Has someone already tried libopenaptx 0.2.0 with bluez-alsa or is working on that?

@pali The crackling noise problem was because of my hardware choice. It turned out that the Raspberry Pi Zero W has a very low quality Bluetooth module. I bought a new USB Bluetooth stick and the problem was completely eliminated. Now the sound is perfect. I can’t hear any distortion or noise even after hours of usage.
Currently I’m using @t123yh ’s code on the RPi, but I will try libopenaptx 0.2.0 code too because @t123yh ’s code has about 1.5 second latency.
Sorry for the late reply.

@janro1 for libopenaptx integration into bluez-alsa see PR: https://github.com/Arkq/bluez-alsa/pull/356

It's nice to see all of this:) Closing this for #356.


TypeScript Translation

TypeScript version of your code. Users can transpiler it to javascript via npm build if they want to avoid using typescript.
At the time of this pull request, I haven't tested the code yet so you should definitely do that before merging it. I'll also be testing it with my upcoming project to see how well it goes.

This is awesome! I recently did this for the scalable version but not the main version. Let me know how your testing goes, and once you confirm it works I'll run it through its paces as well. Great PR though. Thank you so much.

Looks like it works as intended after a brief testing. I might make another PR to optimize some of the code (better maintainability) but for now, I'll leave everything as it is to avoid breaking changes.

You're right, it has something to do with Roblox not closing open HTTP connections, but I can't find any good solution to closing requests. Perhaps sending a request to the server to disconnect it, and making it close all active connections with that ID.
This package could use a bit of a refactor, but for now, I'm going to go ahead and merge it.
Thank you very much.


[Bug]: Larger files crash Obsidian when syncing

What happened?
When testing larger files (larger than 200MB) the Obsidian goes white and developer tools disconnect, preventing troubleshooting.
I suspect this is because we use readBinary to read the entire file from disk before encrypting, which works for smaller files. For larger files we'll need to:

set a filesize cutoff
read the file in chunks
encrypt the file in chunks
stitch the file together when syncing

May be worth adding a new field added to the sync manifest listing currently chunked files and their chunk names. Definitely some effort required
What OS are you using?
Windows, Linux, macOS, iOS (iPhone, iPad), Android
What remote cloud services are you using?
S3, OneDrive for personal, Dropbox, webdav
Version of the plugin
No response
Version of Obsidian
No response
Using password or not

[ ] Yes.

Ensure no sensitive information

[X] I ensure that no sensitive information is submitted in the issue.

This situation is most serious on Android phones, when there is a lot of data downloaded, maybe the size of 200MB or less will crash, even if the Parts Concurrency and Concurrency are adjusted to 1

I hope this bug can be resolved.

Definitely speculation at this point as the crash doesn't result in any logs or stack trace (at least that I can see) but if it's what I think it is, reading the file in one pass and attempting to encrypt it without chunking, I think it should be solvable. Will definitely take some effort to refactor the sync algorithm & get this working, if anyone has spare time this is definitely an important one for a PR.

Hmm, notes for implementation:
Looks like none of the file APIs provide a way to read this in a chunked fashion, so this might not be (immediately) solvable. Could be worth requesting the Obsidian team add something like this if possible, but probably won't happen anytime soon.
Per a random Obsidian team PR review I found, fs can't be imported on mobile. I think this might prevent us from importing this on anything but a desktop-only plugin, which is possible if we fork the plugin again but I don't think otherwise...
Might be complex/messy to get this working. Still researching.

Looks like the self-hosted livesync plugin supports chunked files, so we can borrow ideas from there.

Here is an issue where they discuss 400MB file syncing successfully (after some updates). I still don't understand how they use the obsidian API to combine those chunks based on quick code review, but sure seems possible somehow.

Not sure if this is the same problem but:
I have crash problems on iPhone 12 and iPad pro / ios mobile with an asset folder of around 4000 image files (each image around ~1-40mb in size) which are linked in ~30 Markdown files.
If i add new images on the desktop and sync starts, the iPad pro will try to sync around 5-10 images and then crash, on iPhone it doesn't sync anymore, it just crashes when sync is started.
So i think the problem is not only on Android but with bigger Vaults. Filesize of the complete vault is around 10k files with 9,5gb.
Desktop usage and sync was never a problem.
I've read somewhere that the Vault API secretly hides lower level stuff which maybe can read and write in chunks for Capacitor builds - so this will not be officially supported (yet) but regarding the API i think that's a real problem (?).

Per a random Obsidian team PR review I found, fs can't be imported on mobile. I think this might prevent us from importing this on anything but a desktop-only plugin, which is possible if we fork the plugin again but I don't think otherwise...

I think you are referencing these infos regarding the problem:

https://forum.obsidian.md/t/why-does-fs-writefile-not-save-file/31972
https://docs.obsidian.md/Plugins/Getting+started/Mobile+development#Node+and+Electron+APIs

As far as I've read the code they only use chunks on the remote side in the database and on the transfer.
Locally they do just read and write using the standard functions wrapped (https://github.com/vrtmrz/obsidian-livesync/blob/c2491fdfad043d8301c3a20e4f0727150d67376a/src/SerializedFileAccess.ts) but there is some local database stuff involved, I've seen some "PouchDB" and this.plugin.localDatabase references and handleDatabase* stuff. I can just imagine that the plugin maybe syncs Vault file changes in chunks into a local database (backed by the localStorage), using \n or chunksize and then, identifying the chunks via hash (there is some wasm code with hash stuff used?).
The use of change-events may be used to sync the stuff from the database back into the Vault files.
But that's just some 15 minutes interpretation of the first diving into the code.
But, that would be an interesting idea and may work to get smaller file parts - but then the remote needs some server backend.

That makes sense to me, I also couldn't quickly find any magic API they use to write/read in chunks - but it's odd that our app crashes on large files and theirs doesn't seem to, even on desktop. I think my first test will be setting up livesync and seeing if it can even sync these large files on mobile.
Really appreciate your notes/deep dive!


Configure KeyBinding Doesn't Work

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.90.2
OS Version: Windows 23H2

Steps to Reproduce:

Make sure you have multiple repos
Right click on the commit id/branch of one repro, then select "Configure Keybinding"
Couldn't find the command

We are unable to support the Configure Keybinding action for status bar actions. Let me remove it from the context menu

Looks disabled now

@benibenj, I think we should completely remove the action as that will never work as far as I understood.

I think it's fine to align with the hide action and disable the action when it's not supported. Each action in that toolbar has the hide and key binding action, so I think it makes more sense to disable these actions when they are not supported compared to just not showing them for some actions


feat: Implements OpenFile  method

I'm not sure if it works or not, but I implemented OpenFile anyway.

@kunst1080 @safx Compilation can be done!

@kunst1080 @safx  Done is better than perfect ;D


issue when deploying a contract on execution

I just followed the documentation, and tried to do:
SimpleStorage.deploy([100], {gas:800000}).then(...)
but SimpleStorage.deploy([100], {gas:800000}) is null, i don't know if i do something wrong.
I'm tring to create a function in js that deploy a new instance of a contract every time it's called.

@RamiroMoreira is this with web3.js 1.0 or web3.js 0.20 ?

i think it is 1.0.0-beta.22

Hi @RamiroMoreira. Currently, Embark doesn't have a deploy function on Contracts imported like SimpleStorage.
However, you can redeploy a contract as many times as you want with the following steps:
const contractObject = new web3.eth.Contract(CONTRACT_ABI_DEFINITION); // web3 is available globally in window
const deployObject = contractObject.deploy({arguments: CONTRACT_PARAMS, data: CONTRACT_BYTE_CODE});

After that, you can keep contractObject to redeploy using different params.
You can find the Byte code and ABI in SimpleStorage.options.data and SimpleStorage.options.jsonInterface (or any other contract).
Tell me if that helps.


Can't drag and drop components in Fast Report Community, v.2023.2.0

I've created a .frx file and it broke fast report at all
Hi, I'm working for the first time using fast report and today I tried to use C# in order to generate a .frx file with a data source already fixed (using RegisterBusinessObject). I've used the following code:

private  string  SaveReportLocalPath(DailyReportInformations  report)
{
var filePath = Path.Combine(Directory.GetCurrentDirectory(), @"Templates\AccountingDaily.frx");
var freport =  new  FastReport.Report();
freport.Dictionary.RegisterBusinessObject(new List<DailyReportInformations> { report }, "accountingDaily", 10, true);
freport.Report.Save(filePath);
return filePath;
}

You can download the file here:
https://drive.google.com/file/d/1OCEvHDYsfQl5qHC0yGnR1kvQDpuD1pKU/view?usp=share_link
It generates a .frx file with the following Dictionary (opening it with notepad++):

You can follow this image for analysis.

So, what's the problem?
The problem is that after opening this file in Designer.exe the Drag and Drop feature brokes, it doesn't matter what you do after that, you can delete FastReport folder, download it again and the problem still there..
Drag and drop, for example, 'PageN' into the board, it'll place the component into a random position and it become invisible and unusable!
I've tried:

Reboot the PC
Uninstall and install again
Install other versions (with my tests in other machines, the problem only occurs if I start with version 2023.2.0,
in one of my test cases, I first tried the version 2022.2.0 and the problem didn't occured, so I assume the problem is with the latest version of the tool).

How to reproduce?

Using C#, generate a .frx file registering it's RegisterBusinessObject with a class and save it locally (see first lines).
Download the version 2023.2.0 of Fast Report Community (https://github.com/FastReports/FastReport/releases/tag/v2023.2.0)
Unzip the download
Open Designer.exe
At Designer, open the generated file, in my code example, called "AccountingDaily.frx".

Package and Project versions:

Fast Report Community: 2023.2.0 (link above)
FastReport.OpenSource:  2023.2.4 (dotnet add package FastReport.OpenSource --version 2023.2.4)
FastReport.OpenSource.Export.PdfSimple: 2023.2.4 (dotnet add package FastReport.OpenSource.Export.PdfSimple --version 2023.2.4)
FastReport.OpenSource.Web: 2023.2.4 (dotnet add package FastReport.OpenSource.Web --version 2023.2.4)

How can I have my FastReport working normally again? Does I need to format my SSD?
Thank you all in advance. :)

Eu também tenho o mesmo problema

Eu também tenho o mesmo problema

I have the same problem. It didn't work even going back to the previous version.

The only way that worked for me was to format my machine and download a previous version

I solved the problem by changing the snap size property from 25 cm to 0.25 cm in View > Options... > Report Page

I am having the same problem, and the only working solution is deleting the FastReport.Community.config file as mentioned by @vercom , or going to View > Options > User Interface and clicking 'Reset config'. After restarting the designer, the report becomes editable again. However, upon closing and reopening it, the issue reoccurs, and it is necessary to repeat the same steps.

Thank you it works for me!

I solved the problem by changing the snap size property from 25 cm to 0.25 cm in View > Options... > Report Page

work for me.

I am having the same problem, and the only working solution is deleting the FastReport.Community.config file as mentioned by @vercom , or going to View > Options > User Interface and clicking 'Reset config'. After restarting the designer, the report becomes editable again. However, upon closing and reopening it, the issue reoccurs, and it is necessary to repeat the same steps.

Thank you it works for me

I solved the problem by changing the snap size property from 25 cm to 0.25 cm in View > Options... > Report Page

u save my day

Hello!
To solve your problem please upgrade your FastReport.OpenSource to the current version and then follow the steps:
View -> Options -> Reset config
after clicking on Reset config please restart your FastReport.OpenSource completely
Best regards,
Bogdan


OAK-10151 : oak-auth-external tests fail with Guava 20

@reschke , i would appreciate if you could take a close look. the changes:

obvious mistake in one auth-external test
adding more messages to the assertions in auth-external tests
simplify AuthorizableIterator construction in AuthorizbleImpl and GroupImpl
replace usage of guava Iterators.concat in AuthorizableIterator with a custom utility in oak-commons

i hope that this allows us to fully understand why the guava concat fails with guava 20.
once we have that and conclude that the proposed replacement is reasonable, i would replace all usages of guave Iterators.concat in oak security and if used other modules.

I can confirm this passes tests with Guava 20.
That said, I'm a little worried about the approach. We have no evidence that "Iterators.concat()" is indeed broken in Guava 20, so this might be exposing a bug in our implementations that we might be just hiding right now.+
Would it be possible to separate the test changes into a distinct ticket/commit and do that first? I'm willing to help with the analysis once I'm done with my current emergency :-).

Would it be possible to separate the test changes into a distinct ticket/commit and do that first?

should be doable.

@reschke , wdyt?


Iam users

Fixes cloud-native-toolkit/planning#822
Add script to grant permissions to IAM users on ROKS.

@csantanapr I implemented the changes you requested.  The scripts create the userdemo and projectdemo as well as imports the additional users from a file.
These changes correspond with the developer guide  documentation changes I made


Add screenshot image of unit testing in terminal

This links through to https://asciinema.org/a/98078 which is a replay of the unit tests being run.
If we ended up with a docs/ site on GitHub, we could embed the asciinema player :-)

I like the idea though it does make presumptions on how PHPCS is installed (which is ok as long as we make those presumptions clear).

it does make presumptions on how PHPCS is installed

There's little different to the static code snippet which was already there.

@GaryJones True, the remark was more about the section in general.


aip/4114: add a "mtlsEndpoint" parameter to each service defaults

To support aip/4114 we may need to contact the "mtlsEndpoint" of the service instead of the default endpoint. This endpoint can be found in the discovery doc.
https://google.aip.dev/auth/4114

We should do this at some point.

Strike 2, we still want to do this.

We do not have time to work on this, closing.


Error on joining to the server

When the server is opening, it puts an error in the console, and when I try to join the server, it puts another error :(

How I fix this?

Please try again using LP 5.1.90 or higher - it won't fix the problem but should give more informative errors.

I put the luckperms 5.1.107 and this is the new error.

Please check for errors during startup.


Docker freeze after thounsand of Pregel jobs

My Environment

ArangoDB Version:
3.4.6
Storage Engine:
RocksDB
Deployment Mode:
Single Server
Deployment Strategy:
Manual Start in Docker
Configuration:
custom (12 vCPUs, 56 GB memory) Intel Haswell
Infrastructure:
Google Cloud
Operating System:
Debian Jessie
Total RAM in your machine:
56GB
Disks in use:
SSD 100GB
Used Package:
Compiled from sources

Component, Query & Data
Affected feature:

Pregel Queries
AQL query (if applicable):
We use the Pregel Algorithm Shortest path
AQL explain (if applicable):

Dataset:

Size of your Dataset on disk:

Replication Factor & Number of Shards (Cluster only):

Steps to reproduce

Launch thousands of Pregel jobs for shortest path

Problem:
The docker freeze and must be restarted
We are currently retrieving the /var/log/syslog files and will provide them asap
Expected result:
Continue to work

Hi @GaetanLhoest,
are you still facing this issue?
If so, could you please provide the log files?

After some investigations, we could not reproduce this issue on a baremetal server, it only occurred on google cloud compute instances. We tried to retrieve logs on these google cloud compute instances but there were none.

Hi @GaetanLhoest,
Okay, I am going to close this issue now and you can reopen it at any time once you are able to reproduce/collect logs so we can continue our analysis
Best


Adding another resource

I ran across http://sysadvent.blogspot.com/2015/12/day-8-be-better-engineer-dont-do.html and think it'd be pertinent to the resources. Thoughts?

Adding in a forthcoming commit.


NAS interactions slow for Image ingestion and ML processing

NAS mounted over 2.5GBE connection to /mnt/nas
Tested image ingestion of 100 JPGs at around 10MB/image
Images ingest at ~24/minute - 100K images would take around 3 days.
Ingestion seems to use only one core.
NAS mounted over 2.5GB connection.
Annotation of 10 images with model v2.
The 256x256 image chips are created on the NAS but this takes almost two minutes to create the 1,717 chips, and then another ~35s to process them. Processing 10 images took over 20 minutes (so 100K images would take 6 months)
Seems like the image chips should, at least, be processed on the internal drive, NOT the NAS?

This is partially fixed @TanyaStere42 because the 255x chips are now processed in-memory, but the image ingestion is still super slow. Opening a new issue with more description and testing of image ingestion.


CAMEL-10885 A follow-up - masking formatter should be applied in all …

…process()

Thank you for your contribution 👍, this has been merged into master you can close this pull request

Thanks! closing


Local library needs to be from git repo

I've tried to write test for beakerlib libraries following usual structure with dedicated 'data' directory containing inner fmf root.
So I've used main.fmf of the test as
require:
- path: .
  name: /Libary/demo

However it looks that 'url' is required as tmt fails with
discover
    workdir: /var/tmp/tmt/run-317/plans/default/discover
        how: fmf
        Run command 'git rev-parse --show-toplevel'.
        out: /home/lzachar/gits/tmt
        directory: /home/lzachar/gits/tmt/tests/libraries/recursion/data
        Copy '/home/lzachar/gits/tmt/tests/libraries/recursion/data' to '/var/tmp/tmt/run-317/plans/default/discover/default/tests'.
        Run command 'git rev-parse --short HEAD'.
        err: fatal: not a git repository (or any of the parent directories): .git
        Command returned '128'.
        Check metadata tree in '/var/tmp/tmt/run-317/plans/default/discover/default/tests/'.
        Detected library '{'path': '.', 'name': '/Libary/demo'}'.
        Fetch library './Libary/demo'.
        Copy local library '.' to '/var/tmp/tmt/run-317/plans/default/discover/default/libs/.'.
fatal: not a git repository (or any of the parent directories): .git
    finish
    workdir: /var/tmp/tmt/run-317/plans/default/finish
        summary: 0 tasks completed
    status: done
    Write file '/var/tmp/tmt/run-317/plans/default/finish/step.yaml'.
Unable to detect default branch for '/var/tmp/tmt/run-317/plans/default/discover/default/libs/.'. Is the git repository 'None' empty?

Note that /tests/libraries/local clones library from a git repo so it doesn't cover this.

I faced is as well. I think the solution could be to allow an fmf_id compound by just name attibute. E.g. missing url or path would suggest to use the current repo, i.e. equal to the path set to the current fmf root - that could be actually the easiest solution/workaround - internally set the path if only name was provided.

While it is documented as a correct indentifier [1], it still does not work.

https://fmf.readthedocs.io/en/latest/concept.html#identifiers


Additional mouse keys not working on Konva canvas

Describe the Bug
This is a pretty minor thing, but I noticed that extra mouse buttons (further than MB3) do not provide their expected functionality.
Steps to Reproduce the Problem
Open the map editor and use a mouse button other than left-click, right-click and mouse-wheel in the main canvas area.
Expected Result
I use my MB4 and MB5 buttons for quick browser history navigation.
When pressing MB5 I expect to navigate back to the last visited page (in this case the map overview).
Actual Result
Nothing.
The button does not navigate back, but it registers as a beginning drag action.
PermaplanT version
master
Operating System
Windows
Browser
Microsoft Edge
Versions of other relevant software/extensions
No response
Additional info/logs
No response

Thanks for testing! Good to know that also Microsoft Edge is being used.

The button does not navigate back, but it registers as a beginning drag action.

Was this added by accident?

I don't have these buttons on the mouse, so I'll close it for later.


coconutbattery: sha256 mismatch

Upgrading coconutbattery to 3.5.1
==> Downloading https://www.coconut-flavour.com/downloads/coconutBattery_3.5.1.zip
######################################################################## 100.0%
==> Verifying checksum for Cask coconutbattery
==> Note: running "brew update" may fix sha256 checksum errors
Error: sha256 mismatch
Expected: 8cadc6a1c1c1bc4f5ee0ce32a83ac6b74670fbd2ede62a1945988463d4ba6d66
Actual: bd87b41a9a55ce36269af652d7aa1f14039c32fd93830c5dfc22aed87cfd87bf

Next time, please do follow the reporting bugs template.
It teaches you how to fix this (it’s not at all difficult) or how to report it if you’re having trouble.

@vitorgalvao Yes sorry, bad behaviour by me :neutral_face: - skipped the reading of the template.
Thanks for the fix!


Improved code by emphasizing orderId on find orders page(#2894ay5)

Related Issues
#146
Closes #146
Short Description and Why It's Useful
The order ID on the find order page should be easier to identify.
Screenshots of Visual Changes before/after (If There Are Any)
Before:

After:

IMPORTANT NOTICE - Remember to add changelog entry
Contribution and Currently Important Rules Acceptance

[X] I read and followed contribution rules

The issue was for the find order page, not order detail page

The issue was for the find order page, not order detail page

Ok sir, I have removed strong tag from order page's orderId and added it to the find order page's orderId


Replace boost::unique_lock with std::unique_lock

Came up in a discussion from https://github.com/ripple/rippled/pull/2613
Reviewer:
@wilsonianb

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Are they available in MSVC? Also do we really need the timed variants?

I'm not sure what version of VS they came into, but I do know that Microsoft was extremely active in this area in the run-up to C++14.  So it is likely that VS-2015 has these facilities.
We don't need the timed variants, but the untimed variants are not available until C++17.  This was Microsoft's doing.  I proposed shared_mutex and upgrade_mutex for C++14.  Both implicitly had timed waits.  upgrade_mutex got dropped and shared_mutex got renamed to shared_timed_mutex, and then shared_mutex (without timed waits) got added to C++17.

Jenkins Build Summary
Built from this commit
Built at 20180705 - 21:55:34
Test Results

Build Type
Log
Result
Status

msvc.debug
logfile
1032 cases, 0 failed, t: 566s
PASS :white_check_mark:

coverage
logfile
1035 cases, 0 failed, t: 688s
PASS :white_check_mark:

docs
logfile
1 cases, 0 failed, t: 2s
PASS :white_check_mark:

gcc.release.unity -Dassert=true, MANUAL_TESTS=true
logfile
1101 cases, 0 failed, t: 796s
PASS :white_check_mark:

clang.debug.unity
logfile
1035 cases, 0 failed, t: 249s
PASS :white_check_mark:

clang.debug.nounity
logfile
1033 cases, 0 failed, t: 307s
PASS :white_check_mark:

clang.debug.unity, PARALLEL_TESTS=false
logfile
1035 cases, 0 failed, t: 489s
PASS :white_check_mark:

rpm
logfile
1034 cases, 0 failed, t: n/a
PASS :white_check_mark:

gcc.debug.unity
logfile
1035 cases, 0 failed, t: 246s
PASS :white_check_mark:

gcc.debug.nounity
logfile
1033 cases, 0 failed, t: 346s
PASS :white_check_mark:

msvc.debug, PROJECT_NAME=rippled_classic
logfile
1032 cases, 0 failed, t: 1236s
PASS :white_check_mark:

clang.release.unity -Dassert=true
logfile
1034 cases, 0 failed, t: 338s
PASS :white_check_mark:

gcc.release.unity -Dassert=true
logfile
1034 cases, 0 failed, t: 354s
PASS :white_check_mark:

gcc.debug.unity -Dstatic=true
logfile
1035 cases, 0 failed, t: 247s
PASS :white_check_mark:

msvc.release
logfile
1031 cases, 0 failed, t: 516s
PASS :white_check_mark:

Codecov Report

Merging #2617 into develop will decrease coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop    #2617      +/-   ##
===========================================
- Coverage    70.83%   70.82%   -0.02%
===========================================
  Files          698      698
  Lines        54367    54367
===========================================
- Hits         38510    38504       -6
- Misses       15857    15863       +6

Impacted Files
Coverage Δ

src/ripple/app/misc/impl/ValidatorList.cpp
86.49% <100%> (ø)
:arrow_up:

src/ripple/server/impl/BaseHTTPPeer.h
87.65% <0%> (-3.09%)
:arrow_down:

src/ripple/protocol/impl/STVar.cpp
86.07% <0%> (-2.54%)
:arrow_down:

src/ripple/app/misc/SHAMapStoreImp.cpp
75.29% <0%> (+0.23%)
:arrow_up:

Continue to review full report at Codecov.

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

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

@HowardHinnant I didn't see any uses of shared_time_mutex, but I did find some boost::shared_lock instances. So I just replace those with their std-equivalent here in b00b912c52a44c4bf5743a4b773ab87a7a08e4fa

Sorry, I wasn't clear.  I'm recommending we eliminate the dependence on boost completely by replacing boost::shared_mutex with std::shared_timed_mutex.  They are roughly equivalent.  "shared_mutex" was renamed to "shared_timed_mutex" during the standardization process.

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Merged with #2629 as 79d819584f5d92d569e4b32524b968b26200bbf8. Thanks for your contribution!


Authorization Header is supposed to use the "Bearer" value with a capital B

Authorization Header is supposed to use the "Bearer" value with a capital B
RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage", section 2.1

Looks good, thanks :+1:

After running the tests and looking into it again I have reverted the changes because Heimdall actually uses the exact token type that the server returns. So if the server sends a Bearer token it will be used.

I run into the same troubles with Keycloak as the server as it sends back bearer and not Bearer.
Indeed it should not matter according to rfc6749:
token_type
         REQUIRED.  The type of the token issued as described in
         Section 7.1.  Value is case insensitive.

Some libraries don't seem to handle bearer appropriately though possibly because they only look at rfc6750 mentioned by @MarvinNazari . So it might make sense to capitalize whatever type is provided in the name of robustness.
@tibr thoughts?
I'd really like this change to be merged :)


bmi-cal-added

Title and Issue number

Title : Added BMI calculator
Issue No. : #248
Code Stack : https://github.com/NK-Works/FitFlex/blob/bmi/src/components/BMICalculator.jsx
Screenshot:

Video (mandatory)
https://github.com/user-attachments/assets/e1ad68ca-1cff-41fd-ac4d-4e7eb5208985
Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md if its a new page/tech stack
[x] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
Are you contributing under any Open-source programme?

[x] I'm a GSSOC-EXT contributor
[x] I'm a HACKTOBERFEST contributor

@NK-Works I'm sorry for the inconvenience. It is already present in the Chatbox. Even though, this design not seems good.

@jeevan10017 I showed the design during issue creation maybe I could have rejected it then :( wasted my efforts 😞

@NK-Works OK, Do one thing. Link it to a footer named "BMI Calculator." The popup model/ form should appear when the user clicks on this. So, in this form, the user can calculate his BMI.
create another New PR for this

@jeevan10017 I have added the BMI Calculator with a link... Hope this satisfies you :)
Check PR #311

@jeevan10017 I have added the BMI Calculator with a link... Hope this satisfies you :) Check PR #311

create new PR for this


i try run yt-dlp exe but nothing happens

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm asking a question and not reporting a bug or requesting a feature
[X] I've looked through the README
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've searched known issues and the bugtracker for similar questions including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Please make sure the question is worded well enough to be understood
Try run exe. then cmd screen open but nothing really happened. only happens something very quickly about half/1 second? should i get some program or what? i found year ago installation manual, but looks like it not work. Windows 11.
Provide verbose output that clearly demonstrates the problem

[ ] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[ ] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
No response

Would it help OP and similarly challenged users if the program paused with, say, Press [Enter] to continue, when run on Windows, after printing this message that disappeared with OP's transient terminal window:
Usage: yt-dlp [OPTIONS] URL [URL...]

yt-dlp: error: You must provide at least one URL.
Type yt-dlp --help to see a list of all options.

Maybe add a link to https://github.com/yt-dlp/yt-dlp/issues/418#issuecomment-864537035 as a FAQ answer?

yep that is it what it say, problem is i dont know what i should to do fix that. i saw one screenshot and there was i guess own program which open terminal/cmd where you put link.. so I can't put link to anywhere.. i guess i should have some program after i have runned that exe file but looks like its not work.. weird.

edit. found another better instructions on reddit how to do that and now it works. 👍


Dont call multiunzip when no stats

Which issue does this PR close?

Closes #9219
Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

@alamb I have updated the docstring. let me know if anything else

Thanks again @matthewmturner !


ARROW-10876 [Rust] validate row value type in json reader

Codecov Report

Merging #8895 (1620af2) into master (3deae8d) will increase coverage by 0.00%.
The diff coverage is 61.53%.

@@           Coverage Diff           @@
##           master    #8895   +/-   ##
=======================================
  Coverage   52.98%   52.99%
=======================================
  Files         172      172
  Lines       30750    30762   +12
=======================================
+ Hits        16294    16303    +9
- Misses      14456    14459    +3

Impacted Files
Coverage Δ

rust/arrow/src/json/reader.rs
83.17% <61.53%> (-0.09%)
:arrow_down:

Continue to review full report at Codecov.

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


Program can't start because api-ms-win-core-path-|1-1-0.dll is missing

Windows Server 2008 R2 install.

Windows 2008 r2 is unsupported by Microsoft and has been end of life for 3 years now. You need to update tona supported OS to use GYB.


Delete updater package from kubevirt

This PR removes the updater package from our project. Here’s why:

Code Complexity: The package makes the code complicated and hard to understand. It uses reflection and locks, which adds unnecessary complexity.
Error Hiding: The updater hides errors by retrying updates or patches in reverse order if the initial attempt fails. For instance, if updating a subresource fails, it will try to update the main resource, and vice versa. This outdated logic is unnecessary because all objects handled by the updater now include status as a subresource. Additionally, it hides objects without status as subresources.
Improved Testing: Removing this package will make the code easier to test. With less code, we increase tests coverage.
Code Reduction: This change deletes over 700 lines of code, simplifying our codebase.
We are removing this package because we don’t want to support this complex and error-prone code. Simplifying our code will make it clearer and easier to manage.

The status updater was introduced when we had to support Kubernetes versions that did not have subresources for CRs, and we needed to improve security while handling both scenarios during upgrades. It is safe to remove the status updater, even if it was used in a version where a resource didn’t include status as a subresource, because during an upgrade, if a CRD does not have the status subresource defined, the virt-operator will patch it to include it.

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

/sig code-quality

The deleted code surely has an important functionality. In your PR text, please discuss why this functionality is not needed. I suspect that each commit should discuss why the relevant code does not need the low-level retry mechanism.

The deleted code surely has an important functionality. In your PR text, please discuss why this functionality is not needed. I suspect that each commit should discuss why the relevant code does not need the low-level retry mechanism.

Hi @dankenigsberg,
Sorry if I wasn’t clear. The updater doesn’t really use this retry system. What I meant is that it hides errors by trying updates or patches in the opposite order if the first attempt fails. For example, if it fails to update a subresource, it will then try to update the main resource, and vice versa. This method is outdated since all objects now include status as a subresource, so it isn’t needed anymore(same for patch).

I might be missing something here
@xpivarc @fossedihelm @enp0s3  Does this code include important functionality?

https://github.com/kubevirt/kubevirt/pull/12601 needs it in some form.

#12601 needs it in some form. Otherwise resources that were enabled in the original PR no longer need it.

Ia this the only one that added status as subresource recently?

I think that all these objects now include status as a subresource and even if they don't we can use Update instread of UpdateStatus or change the status to be a subresource

@Barakmor1 I'd love to see this pkg gone. It "smells" because it is under util and because it "knows" about the internal behavior of so many resources. However, I think that in each of your commits you should explain why its functionality was needed and why it is no longer needed. In particular consider upgrades from older versions of the resources.

The status updater was coming from a time where we were dealing with k8s versions which did not even subresources on CRs and we had to support both and there was not really a way to figure that out. I don't think we still need it nowadays. Removing it sounds good.

#12601 needs it in some form. Otherwise resources that were enabled in the original PR no longer need it.

Actually, the VMSnapshotController uses it to update the VM object, not the snapshot object, so I don't think this should block us.
The objects handled by this package are: VirtualMachine, VirtualMachineInstanceReplicaSet, VirtualMachineInstanceMigration, KubeVirt, and VirtualMachinePool. Please note that although the VirtualMachineClone updater is mentioned here, it is never used.
Therefore, I don't think we should be blocked by this. All these objects already have status as a subresource.
Please also note that these objects are being handled just in some of these function for instance VirtualMachinePool is not handled in here .

@xpivarc Hi, #12601 changes VM snapshot API calls, while this PR touches the VM API calls. The confusing part is that both are in the same controller, and as @Barakmor1 mentioned the udpate wrapper is limited to specific resources, otherwise it panics.
/approve

#12601 needs it in some form. Otherwise resources that were enabled in the original PR no longer need it.

I think that all these objects now include status as a subresource and even if they don't we can use Update instread of UpdateStatus or change the status to be a subresource

@Barakmor1 I'd love to see this pkg gone. It "smells" because it is under util and because it "knows" about the internal behavior of so many resources. However, I think that in each of your commits you should explain why its functionality was needed and why it is no longer needed. In particular consider upgrades from older versions of the resources.

During an upgrade, if a CRD does not have the status subresource defined,  virt-operator will patch it to include this subresource.

I think that all these objects now include status as a subresource and even if they don't we can use Update instread of UpdateStatus or change the status to be a subresource

@Barakmor1 I'd love to see this pkg gone. It "smells" because it is under util and because it "knows" about the internal behavior of so many resources. However, I think that in each of your commits you should explain why its functionality was needed and why it is no longer needed. In particular consider upgrades from older versions of the resources.

I've added an explanation regarding upgrades and the reason for this library's existence in both PR description and the last commit. Please let me know what you think.

#12601 needs it in some form. Otherwise resources that were enabled in the original PR no longer need it.

Actually, the VMSnapshotController uses it to update the VM object, not the snapshot object, so I don't think this should block us.
The objects handled by this package are: VirtualMachine, VirtualMachineInstanceReplicaSet, VirtualMachineInstanceMigration, KubeVirt, and VirtualMachinePool. Please note that although the VirtualMachineClone updater is mentioned here, it is never used.
Therefore, I don't think we should be blocked by this. All these objects already have status as a subresource.
Please also note that these objects are being handled just in some of these function for instance VirtualMachinePool is not handled in here .

/hold
I admit that I did not review #12601 as whole but I see f538a74 enables status for VirtualMachineSnapshot Crd and VirtualMachineSnapshotContent CRD and finally VirtualMachineRestore CRD in a follow up commit. The PR therefore need status updater for smooth update. Am I missing anything?
@rmohr while what you mentioned is true we still need to account for upgrades when one version doesn't have a /status enabled on some crd and the new one has. Otherwise during long upgrades the controller can be blocked or worse it can be incorrect as status changes will be dropped.
EDIT: We still can remove updater for old CRDs that already have /status enabled but while we still don't support status for all CRD we can't drop the generic code.

@xpivarc I believe the updateStatus API call won’t have any effect during the upgrade itself. After the upgrade is done, the snapshot/restore should work as expected. At least, that’s how I think it should work.
Also, Even if there is a problem not using this package during the upgrade, wouldn’t it be better to handle it like this:
result := client.UpdateStatus(...)
if !AsExpected(result) {
    result = client.Update(...)
}

I think we should avoid making the coupling with this package even deeper and discourages expanding it for other objects. What do you think?
BTW do we even support snapshot and restore during upgrade process?

I admit that I did not review https://github.com/kubevirt/kubevirt/pull/12601 as whole but I see https://github.com/kubevirt/kubevirt/commit/f538a74ab2c35a5cc519bbcbe49c65943baf6de3 enables status for VirtualMachineSnapshot Crd and VirtualMachineSnapshotContent CRD and finally VirtualMachineRestore CRD in a follow up commit. The PR therefore need status updater for smooth update. Am I missing anything?

@xpivarc good catch.

@xpivarc I believe the updateStatus API call won’t have any effect during the upgrade itself. After the upgrade is done, the snapshot/restore should work as expected. At least, that’s how I think it should work.

@xpivarc brought up a good point. If not all CRDs use status already, we still need the package.
The main point with the status update enablement transition is, that it has to be done in a staged fashion:

rollout new CRDs (without status enabled) to allow all old controller to still work without the status subresource
roll over controll plane components as always (they will have to work with and without status enabled)
enable status update

That is at least what we did back then. Allowing seamless update while also minimizing service discruptions if any of the above steps fails.
Also note that since k8s 1.30, CRDs finally have field selectors, therfeore we can start thinking about transitioning VMIs to the same final /status model (but there we will then eventually also need the updater package).

I admit that I did not review #12601 as whole but I see f538a74 enables status for VirtualMachineSnapshot Crd and VirtualMachineSnapshotContent CRD and finally VirtualMachineRestore CRD in a follow up commit. The PR therefore need status updater for smooth update. Am I missing anything?

@xpivarc good catch.

@xpivarc I believe the updateStatus API call won’t have any effect during the upgrade itself. After the upgrade is done, the snapshot/restore should work as expected. At least, that’s how I think it should work.

@xpivarc brought up a good point. If not all CRDs use status already, we still need the package.
The main point with the status update enablement transition is, that it has to be done in a staged fashion:

rollout new CRDs (without status enabled) to allow all old controller to still work without the status subresource
roll over controll plane components as always (they will have to work with and without status enabled)
enable status update

That is at least what we did back then. Allowing seamless update while also minimizing service discruptions if any of the above steps fails.
Also note that since k8s 1.30, CRDs finally have field selectors, therfeore we can start thinking about transitioning VMIs to the same final /status model (but there we will then eventually also need the updater package).

I don’t think this is relevant to the PR or should block it. Let me explain why:
The issue you mentioned would still exist even if we update the PR to use this package or block this PR. The upgrade process from a version where snapshot/restore doesn’t include status as a subresource to a version where it does would look like this:
The old controller images will use the current Update API call for both snapshot and restore.
The upgrade starts.
New snapshot and restore CRDs are rolled out (without status enabled).
During this time, snapshot and restore will use Update to update the status (which won’t work).
Control plane components are rolled over as usual.
So, even if we don’t remove this package, the issue you’re concerned about has already occurred, and keeping it won’t help support snapshots/restores during the upgrade.
@rmohr @xpivarc Please let me know if i missed anything

Hm, I can't see the comment from @Barakmor1 on the PR, but got a github notification for it:

I don’t think this is relevant to the PR or should block it. Let me explain why:

The issue you mentioned would still exist even if we update the PR to use this package or block this PR. The upgrade process from a version where snapshot/restore doesn’t include status as a subresource to a version where it does would look like this:

The old controller images will use the current Update API call for both snapshot and restore.
The upgrade starts.
New snapshot and restore CRDs are rolled out (without status enabled).
During this time, snapshot and restore will use Update to update the status (which won’t work).
Control plane components are rolled over as usual.

So, even if we don’t remove this package, the issue you’re concerned about has already occurred, and keeping it won’t help s> upport snapshots/restores during the upgrade.

The updater package is actually switching back and forth between plain update and /status update. It is only using the "permanent" update way for as long as it leads to the expected update result (maybe the word permanent is a little bit misleading in the package).
However, your comment made me rethink one thing: If we use the udpater for the resources already (I think we do, right?), the old controllers can already handle the switch. As such we should be able to just enable the /status subresource for these CRs and let the new controllers use the /status subresource and we are good.
We would still need to come up with a final transition plan for VMIs, but we have at least no update problem at the moment if we remove the package. One possibility would actually be to switch the VMIs now over to using the updater package, to be prepared for the future transition :D

Hm, I can't see the comment from @Barakmor1 on the PR, but got a github notification for it:

I don’t think this is relevant to the PR or should block it. Let me explain why:

The issue you mentioned would still exist even if we update the PR to use this package or block this PR. The upgrade process from a version where snapshot/restore doesn’t include status as a subresource to a version where it does would look like this:

The old controller images will use the current Update API call for both snapshot and restore.
The upgrade starts.
New snapshot and restore CRDs are rolled out (without status enabled).
During this time, snapshot and restore will use Update to update the status (which won’t work).
Control plane components are rolled over as usual.

So, even if we don’t remove this package, the issue you’re concerned about has already occurred, and keeping it won’t help s> upport snapshots/restores during the upgrade.

The updater package is actually switching back and forth between plain update and /status update. It is only using the "permanent" update way for as long as it leads to the expected update result (maybe the word permanent is a little bit misleading in the package).
However, your comment made me rethink one thing: If we use the udpater for the resources already (I think we do, right?), the old controllers can already handle the switch. As such we should be able to just enable the /status subresource for these CRs and let the new controllers use the /status subresource and we are good.
We would still need to come up with a final transition plan for VMIs, but we have at least no update problem at the moment if we remove the package. One possibility would actually be to switch the VMIs now over to using the updater package, to be prepared for the future transition :D

Hm, I can't see the comment from @Barakmor1 on the PR, but got a github notification for it:

I don’t think this is relevant to the PR or should block it. Let me explain why:

The issue you mentioned would still exist even if we update the PR to use this package or block this PR. The upgrade process from a version where snapshot/restore doesn’t include status as a subresource to a version where it does would look like this:

The old controller images will use the current Update API call for both snapshot and restore.
The upgrade starts.
New snapshot and restore CRDs are rolled out (without status enabled).
During this time, snapshot and restore will use Update to update the status (which won’t work).
Control plane components are rolled over as usual.

So, even if we don’t remove this package, the issue you’re concerned about has already occurred, and keeping it won’t help s> upport snapshots/restores during the upgrade.

The updater package is actually switching back and forth between plain update and /status update. It is only using the "permanent" update way for as long as it leads to the expected update result (maybe the word permanent is a little bit misleading in the package).
However, your comment made me rethink one thing: If we use the udpater for the resources already (I think we do, right?), the old controllers can already handle the switch. As such we should be able to just enable the /status subresource for these CRs and let the new controllers use the /status subresource and we are good.
We would still need to come up with a final transition plan for VMIs, but we have at least no update problem at the moment if we remove the package. One possibility would actually be to switch the VMIs now over to using the updater package, to be prepared for the future transition :D

I deleted the comment after realizing that the controller image is rolled out first, and only then are the CRDs patched.
That said, I still believe this package should be deleted. I find it hard to believe that it's the best way to handle this situation. I'll be out until Thursday, but we can continue this interesting discussion when I'm back :)

My 2c regarding this pr and effect on #12601 and #12605
Although, I think we should get rid of this package eventually, I believe we need it for the above PRs. Once all types use it for a couple releases, then we can get rid of it.

That said, I still believe this package should be deleted. I find it hard to believe that it's the best way to handle this situation.

I would have loved to not introduce it. It was however necessary, and it was the only way, after long thinking, I found to handle this situation transparently with minimal disruption. CRDs are evolving over time. They do and did not have every feature for an easy full project lifecycle (although pretty close now).

@rmohr @mhenriks Why not using something like:
result := client.UpdateStatus(...)
if !AsExpected(result) {
    result = client.Update(...)
}

Instead in both https://github.com/kubevirt/kubevirt/pull/12601 and https://github.com/kubevirt/kubevirt/pull/12605

@rmohr @mhenriks Why not using something like:

That is basically what it does. It just considers that updates (e.g. virt-handler rollout or any other slow operation) can take really long or be even stuck for days, it ensures that we minimize API errors and API hits. I don't think it is acceptable to even just have for a few minutes a default behavior which can easily create hundreds or thousands of errors. It also requires the lock, to ensure that no parallel updates are messing up the detection logic.
Some details of the package could have been nicer (like thy type switches are unnecessary, it could have been unstructed all the way down) but it does the job.

@rmohr @mhenriks Why not using something like:

That is basically what it does. It just considers that updates (e.g. virt-handler rollout or any other slow operation) can take really long or be even stuck for days, it ensures that we minimize API errors and API hits. I don't think it is acceptable to even just have for a few minutes a default behavior which can easily create hundreds or thousands of errors. It also requires the locks due to shared usage on different go routines.
Some details of the package could have been nicer (like thy type switches are unnecessary, it could have been unstructed all the way down) but it does the job.

We publish a public package that abstracts the status as if it were a subresource, using reflection and locks to avoid two update API calls instead of one only during upgrades. Are there examples of other projects that choose this level of complexity just to reduce a few API calls during an upgrade?

We publish a public package that abstracts the status as if it were a subresource, using reflection and locks to avoid two update API calls instead of one only during upgrades.

We just put everything in pkg. I know the convention, but I don't think that this adds much to the conversation bringing in the "public" convention.

Are there examples of other projects that choose this level of complexity just to reduce a few API calls during an upgrade?

Most OSS projects in that space do not invest so much in seamless updates like kubevirt. As someone working on integrating a lot of those projects, these things cause a lot of trouble, leading to escalations, causing confusions for customers and support. That amount of detail across the board is absolutely a must. There are still things missed and they are trouble enough. We should not be sloppy.

@Barakmor1 Consider that the time that takes for the update to complete can be quit long (and even for relatively fast update you want to minimize user disruption and not cause operational overhead as Roman pointed out). In that scenario you could make hundreds/thousands of API calls with simple/straightforward logic of just trying to hit /status sub-resource.
Still I think we can progress here by removing the current usage and leaving just the bare bone for Michael to re-use for those 2 RPs. Eventually we can remove even that as most users should have update after 2 releases. Now for the VMIs we could simple revert the commit that does delete the generic stuff and reuse it. As an alternative you can suggest implementation for Michael but I think using something off the shelf is much better and the urgency for removing the package hopefully doesn't outweigh convenience.
Also anybody interesting improving this package is welcome.

I still don't think that using code like this:
result := client.UpdateStatus(...)
if !asExpected(result) {
result = client.Update(...)
}
would cause issues. During an upgrade, we might need to make two API calls since the first one might do nothing (NO-OP) . But after the upgrade, the first call should be enough.
Let me know if I’m missing something

I still don't think that using code like this:

I think it has been answered above. Happy to reiterate, but maybe offline.

@xpivarc @rmohr How about using a CRD informer in the PRs to explicitly check if the status is a subresource before making the update or updateStatus call instead of using the updater.

@xpivarc @rmohr How about using a CRD informer in the PRs to explicitly check if the status is a subresource before making the update or updateStatus call instead of using the updater.

I think it's better to keep the complexity in one place rather than two different controllers acting on three different custom resource types

My 2c regarding this pr and effect on #12601 and #12605
Although, I think we should get rid of this package eventually, I believe we need it for the above PRs. Once all types use it for a couple releases, then we can get rid of it.

Can this package shed the rest of the resources it is currently handling?

My 2c regarding this pr and effect on #12601 and #12605
Although, I think we should get rid of this package eventually, I believe we need it for the above PRs. Once all types use it for a couple releases, then we can get rid of it.

Can this package shed the rest of the resources it is currently handling?

Sure. If we go this route, I think it would probably make most sense to first get #12601 and #12605 in then rebase here and remove support in updater for VirtualMachine, etc.
@Barakmor1 if you agree, I will remove the holds on above PRs and update here when they get merged

My 2c regarding this pr and effect on #12601 and #12605
Although, I think we should get rid of this package eventually, I believe we need it for the above PRs. Once all types use it for a couple releases, then we can get rid of it.

Can this package shed the rest of the resources it is currently handling?

Sure. If we go this route, I think it would probably make most sense to first get #12601 and #12605 in then rebase here and remove support in updater for VirtualMachine, etc.
@Barakmor1 if you agree, I will remove the holds on above PRs and update here when they get merged

@mhenriks, I believe using informers and adding RBAC rules to virt-controller is a clear and straightforward approach.
The current code is already difficult to understand and maintain, and I’m concerned that it might be confusing for other community members, as it was for us and the other approvers and reviewers involved.
That said, if the decision is to keep the updater package for two more releases, I’m okay with that, though I don’t think it’s the best path forward.

@mhenriks, I believe using CRD informer and adding RBAC rules to virt-controller is a clear and straightforward approach.

@Barakmor1 Unfortunately that is not sufficient. Using informers means that the local copy of the CRD may not be up to date so still have to add the logic that checks that a Update() actually updated the status like here. Resulting code will end up looking a lot like the updater package you want to remove

That said, if the decision is to keep the updater package just for storage for two more releases, I’m okay with that, though I don’t think it’s the best path forward.

My preference would be to keep the package for now but not use it for VirtualMachine, ect. Only for snapshot.kubevirt.io and export.kubevirt.io api groups

@mhenriks, I believe using CRD informer and adding RBAC rules to virt-controller is a clear and straightforward approach.

@Barakmor1 Unfortunately that is not sufficient. Using informers means that the local copy of the CRD may not be up to date so still have to add the logic that checks that a Update() actually updated the status like here. Resulting code will end up looking a lot like the updater package you want to remove

I'm not sure I understand why we would need to check this. Could you elaborate?

@mhenriks, I believe using CRD informer and adding RBAC rules to virt-controller is a clear and straightforward approach.

@Barakmor1 Unfortunately that is not sufficient. Using informers means that the local copy of the CRD may not be up to date so still have to add the logic that checks that a Update() actually updated the status like here. Resulting code will end up looking a lot like the updater package you want to remove

It's a bit unclear to me on why we need to check this. If the informers aren't synced, the update call should succeed once they are. Could you please elaborate?

Say subresource is enabled but local copy is stale and our code calls Update() instead of UpdateStatus(), Update() will succeed but the status is not actually be updated, a "lost" update that the controller will be totally unaware of. I assume this is why @rmohr implemented the status updater in the way he did.

@mhenriks, I believe using CRD informer and adding RBAC rules to virt-controller is a clear and straightforward approach.

@Barakmor1 Unfortunately that is not sufficient. Using informers means that the local copy of the CRD may not be up to date so still have to add the logic that checks that a Update() actually updated the status like here. Resulting code will end up looking a lot like the updater package you want to remove

It's a bit unclear to me on why we need to check this. If the informers aren't synced, the update call should succeed once they are. Could you please elaborate?

Say subresource is enabled but local copy is stale and our code calls Update() instead of UpdateStatus(), Update() will succeed but the status is not actually be updated, a "lost" update that the controller will be totally unaware of. I assume this is why @rmohr implemented the status updater in the way he did.

I really hope this isn’t our standard approach. Even if we use the updater, both update and updateStatus could fail due to connectivity issues or conflicting updates. The reconciliation loop should be able handle these scenarios. As far as I know, if the current status hasn't changed, we should try updating the status again.

@mhenriks, I believe using CRD informer and adding RBAC rules to virt-controller is a clear and straightforward approach.

@Barakmor1 Unfortunately that is not sufficient. Using informers means that the local copy of the CRD may not be up to date so still have to add the logic that checks that a Update() actually updated the status like here. Resulting code will end up looking a lot like the updater package you want to remove

It's a bit unclear to me on why we need to check this. If the informers aren't synced, the update call should succeed once they are. Could you please elaborate?

Say subresource is enabled but local copy is stale and our code calls Update() instead of UpdateStatus(), Update() will succeed but the status is not actually be updated, a "lost" update that the controller will be totally unaware of. I assume this is why @rmohr implemented the status updater in the way he did.

I really hope this isn’t our standard approach. Even if we use the updater, both update and updateStatus could fail due to connectivity issues or conflicting updates. The reconciliation loop should be able handle these scenarios. As far as I know, if the current status hasn't changed, we should try updating the status again.

If there are network connectivity issues or conflicts, an error is returned and reconcile is of course retried. We need to avoid the case where an Update does not return an error but also does not do what we wanted it to do.  This is certainly an edge case but something we should handle.  Otherwise it is possible that a user may never see that a VirtualMachineSnapshot succeeded/failed for example

Oh, I understand now, thanks for explaining. However, I still think the code would be clearer even with an additional DeepEqual check. The main issue, as I see it, is that we don't know if a CRD has status as a subresource. Instead of trying one thing and trying another if it fails, it would be more straightforward to check directly if a CRD has status as a subresource.

I respectfully disagree. You seem to be missing the point that checking the CRD via an informer gives no functional benefits over existing code. It may make more sense to you but that does not justify reimplementing long existing, proven-to-work code.
If you want to continue this discussion, let's take the matter offline.  I am going to unhold #12605 and #12601

Oh, I understand now, thanks for explaining. However, I still think the code would be clearer even with an additional DeepEqual check. The main issue, as I see it, is that we don't know if a CRD has status as a subresource. Instead of trying one thing and trying another if it fails, it would be more straightforward to check directly if a CRD has status as a subresource.

I respectfully disagree. You seem to be missing the point that checking the CRD via an informer gives no functional benefits over existing code. It may make more sense to you but that does not justify reimplementing long existing, proven-to-work code.
If you want to continue this discussion, let's take the matter offline. I am going to unhold #12605 and #12601

I'm okay with removing this code after the next two releases. I understand that it’s proven and works, but I also believe we could achieve the same result without using reflection and locks, making the code clearer and simpler.
I'll update this PR to only remove the current usage for now, rather than removing the updater completely.

@xpivarc PTAL

@Barakmor1 Seems like some commit have infiltrated your PR

@Barakmor1 Seems like some commit have infiltrated your PR

Done, Thanks for letting me know

/hold
I think this is not needed anymore

@Barakmor1 ping me once you push rebase

/hold I think this is not needed anymore

@xpivarc did you mean "unhold" ?

/hold I think this is not needed anymore

@xpivarc did you mean "unhold" ?

/hold cancel
@Barakmor1 yes :facepalm:

@xpivarc @mhenriks
here's the follow-up PR to move the Updater under storage:
https://github.com/kubevirt/kubevirt/pull/12760


DPL-198 - Feedback message JSON Schema (S=S; S=S)

User story
As a PSD developer I want to define a JSON Schema for the feedback messages sent to the 'process_status' queue so we can share this definition with other groups about the status of the process of a message originally published in the 'samples_reception' queue. This message will be sent for both successfully processed messages and for errors so that PAM can understand which samples have been successfully received by PSD and which have not.
Who are the primary contacts for this story
Eduardo M
Andrew S
Stuart M
Jonnie B
Acceptance criteria
To be considered successful the solution must allow:

[x] A JSON schema must be defined to support the process_status message
[x] Every message in the 'process_status' queue is a description of the status of the process from the sample message received in the 'sample_reception' queue
[x] Every message must contain a message_id with the id of the original message that we are describing the status of process (should be defined in the message from the 'sample_reception' queue
[x] Every message should have a status with values: 'OK' or 'ERR' indicating that the message_id referred has been correctly processed or not.
[x] Every message can contain a list of all errors found during the process of the sample
[x] Every error described should have an error_type (as defined in confluence) and a human readable message, along with other information if is needed

Dependencies
This story is blocked by the following dependencies:

#<issue_no.>
sanger/#<issue_no.>

References
This story has a non-blocking relationship with:

#<issue_no.>
sanger/#<issue_no.>

Additional context
Add any other context or screenshots about the feature request here.

Closing, as is in Done column.


fixing k8s config target

If the Makefile command is not on a new tab indented line then it treats the following word as a target name with arguments. This change just ensures the command is executed. Also added the word aws in front as that binary name was missing.

All good!


Matlab 2019b Compatibility

Self Test in 2019b (in 2019a everything is ok)
test_ReadYaml
test_ReadYaml: Passed
test_RY_FloatingPoints: Failed, Crash
test_RY_Import: Failed, Crash
test_RY_ImportDef: Failed, Crash
test_RY_ImportNonex: Failed, Crash
test_RY_Indentation: Failed, Crash
test_RY_Inheritance: Failed, Crash
test_RY_InheritanceLoop: Failed, Crash
test_RY_InheritanceMultiple: Failed, Crash
test_RY_Matrices: Failed, Crash
test_RY_SequenceMapping: Failed, Crash
test_RY_Simple: Failed, Crash
test_RY_Time: Failed, Crash
test_RY_TimeVariants: Failed, Crash
test_RY_Whitespaces: Failed, Crash
test_RY_usecase_01: Failed, Crash
test_WriteYaml
test_WriteYaml: Passed
test_WY_ComplexStructure: Failed, Crash
test_WY_FloatingPoints: Failed, Crash
test_WY_Indentation: Failed, Crash
test_WY_Matrices: Failed, Crash
test_WY_SequenceMapping: Failed, Crash
test_WY_Simple: Failed, Crash
test_WY_Time: Failed, Crash
test_WY_usecase_01: Failed, Crash

Hello Wannacookie,
when I was running the selftest on Matlab R2019a, the result was the same as you show here, but the function WriteYaml and ReadYaml still worked fine. Do the ReadYaml and WriteYaml work for you with Matlab R2019b as well despite the failed tests?
Thank you.


The problem of running the emulator on a Linux system

File names on Linux systems are case sensitive.
When running
python src/main.py video

we receive the error that the file ../../resources /font.bin was not found.
I suggest changing the case of the file name in the resource folder from "Font.bin" to "font.bin".

A similar problem occurs when we try to run the emulator with the cpm64 option. Here the file name in the "tapes" folder is typed in upper case "CPM64.RKU" and the emulator tries to find the file "cpm64.RKU":
python src/main.py cpm64

Thank you. I will try to help with testing, it's just that I also write emulators for old PCs

Fixed.
Thank you for the interest to this project.


Are we getting a sass-rails release with Rails 5.1?

I'm wondering whether we'll see a 6.0.0 release of this gem used in Rails 5.1. At the moment, the Rails-generated Gemfile references Github, rather than rubygems, for sass-rails.
My company uses compass-rails in all of our projects, can compass-rails currently depends on sass-rails < 5.1, so for new Rails 5 projects, we'd either need to downgrade sass-rails, or if there's going to be a new release of sass-rails, maybe look at doing a pull request for compass-rails and hope their test coverage is good. (I know zilch about either sass-rails or compass-rails personally.)

sass-rails 5.0.4 already support Rails 5.2, so no, we are not having a new release of sass-rails with Rails 5.1. But I'll change the rails generator to use the released version instead the github reference. Thank you for the report


[SR-15357] [SwiftPM] support for vcpkg

Previous ID
SR-15357

Radar
None

Original Reporter
@stevapple

Type
New Feature

Additional Detail from JIRA

Votes
1

Component/s
Package Manager

Labels
New Feature, windows

Assignee
None

Priority
Medium

md5: eead7599c3901e26b766af3bf90310ff

Issue Description:
vcpkg is a C++ library management tool developed by Microsoft, which is cross-platform and gains first-class support on Windows.
SwiftPM support for vcpkg will largely ease the effort of linking an external library on Windows.

I'd like to pick this up and implement .vcpkg as a system library provider in SwiftPM. Vcpkg products can be easily consumed by SwiftPM because it provides out-of-the-box support for pkg-config, and the only thing we need is to add it to search path.
As the first step of it, I’d like to start from supporting installed libraries first, which has a mostly identical layout to /usr. To confirm the install root, I would like to make use of some environmental variables, including VCPKG_ROOT, VCPKG_TARGET_TRIPLET, VCPKG_HOST_TRIPLET and VCPKG_INSTALLED_DIR. These were used as customizable settings for CMake integration.
WDYT? @abertelrud @neonichu @tomerd @elsh

Personally, I think system library providers in their current form are a stopgap and inherently not scalable. We should find a way to provide them through plugins before adding any new built-in ones that aren't absolutely necessary. It's not feasible for SwiftPM to have knowledge of every other package manager in existence.

Then we should, at least, enable plugins to provide header & library as a target directly, but it doesn’t seems possible.
I propose to add Vcpkg now because we can make use of the .pc files it produce, just like what we do with HomeBrew. Enabling Vcpkg support, together with apple/swift#60679, could make it possible to easily bootstrap SwiftPM and eliminate the need of building new developer tools with CMake on Windows (also unblocks testing on CI). This also matches the goal of Swift’s path on having more Swift in Swift.

I'm not talking about the existing plugin types, but rather a new one that would allow creating system library providers outside of SwiftPM's main codebase.

I don’t think a the provider entry matters very much (personally I think it should be gone and replaced by document). By supporting Vcpkg, I intended to let SwiftPM automatically find its pkgconfig directory. Extracting such functionality into a plugin sounds interesting, but I would doubt the benefit of moving it out of SwiftPM code base. It’s up to the user which PM to be used, but the target is declared by the library author. Suppose that the user is writing a downstream library, he/she cannot add the plugin to the package manifest either.

Sorry, I wasn't super clear here, it is correct that system library providers don't do much today. What I am thinking of is a similar mechanism that can be provided through plugins and it sounds like you're saying the same thing.
Neither the package author, nor the SwiftPM team, should be deciding what the mechanism is to install system libraries on user's systems that are required by particular packages.

Interesting. I haven't used vcpkg. I'll take a look.
I'm also looking at ways we can call CMake and ninja and extract the libraries so we can wrap them in a module map. Lots of examples where this would be useful.

How about introducing a more generic mechanism for building third-party code, similar to Rust’s build script? This would provide more flexibility, allowing vcpkg support to be implemented as a Swift package (like vcpkg-rs) in userspace, rather than having to build everything into SwiftPM.


Terminal color theming is inconsistent for local and remote sessions

My local computer's terminal is on the left, and an ssh session to another machine is on the right.

Note: The colors in the SSH session are generated based on my Theme. If I change from high-contrast to solarized light... my ssh terminal changes, but my local session doesn't.

It's a different computer and has a different prompt set up, look into customizing your $PS1 env var.


purpose of unsupported_extension class and context extensions

The unsupported_extension exception is currently only thrown by opengl_create_shared_context(). Maybe one could also throw it when the constructor of a general context fails, if there is an unsupported extension specified by const cl_context_properites *properties.
Maybe there also should be a way to construct contexts with extensions without having to create 0-terminated lists by hand (maybe a vector class where the user can add extensions).

After looking at clCreateContext I think in general we can't throw an unsupported_extension_error from boost::compute::context, because there is no special error code for unsupported extension error in OpenCL. CL_INVALID_PROPERTY that is returned by clCreateContext when extension is not supported is also returned for other errors.

CL_INVALID_PROPERTY - if context property name in properties is not a supported property name, if the value specified for a supported property name is not valid, or if the same property name is specified more than once. However if the extension cl_khr_gl_sharing is enabled, then CL_INVALID_PROPERTY is returned if an attribute name other than those listed in the table for properties above or if CL_CONTEXT_INTEROP_USER_SYNC is specified in properties.

CL_INVALID_PROPERTY - if the cl_khr_gl_sharing extension is enabled and an attribute name other than those specified in the table above (table 4.5) or if CL_CONTEXT_INTEROP_USER_SYNC is specified in properties.


add report card badge to readme

Not sure if you want this, but I'd like to submit your library to https://github.com/avelino/awesome-go and they request that you add the report card badge.

Nice, thanks


Batch delete for S in statement list

Is this a question to me? Can you describe more, @Ptrhnk ?

@davidzbiral Would it be helpful to add batch action for deleting statements in statement list? As there are actions for move and duplicate statements..

@Ptrhnk Yes, it would be helpful - thanks if you implement. Of course in such a way that it isn't done by mistake, because there is (so far) no undo!!!


Release tmt-1.20.0

Follow the steps below to create a new major or minor release:

[ ]  Run the full test coverage using tmt -c how=full run
[ ]  Use git log --oneline --no-decorate x.y-1.. to generate the changelog
[ ]  Update README with new contributors since the last release
[ ]  Add a Release tmt-x.y.0 commit with the specfile update
[ ]  Create a pull request with the commit, ensure tests pass

Release a new package to Fedora and EPEL repositories:

[ ]  Move the fedora branch to point to the new release
[ ]  Create a source rpm using the make srpm command
[ ]  Enable Fedora kerberos kinit<EMAIL_ADDRESS>[ ]  Change to the fedora rpms git or fedpkg clone tmt
[ ]  Check out the rawhide branch git checkout rawhide
[ ]  Import the srpm using fedpkg import /path/to/the/srpm
[ ]  Restore any files removed by fedpkg if necessary
[ ]  Ensure the proposed changes are ok and commit them
[ ]  Create a pull request against rawhide from your fork
[ ]  After tests pass, merge the pull request to rawhide
[ ]  Build the package for rawhide fedpkg build --nowait
[ ]  Build package for all active releases__
[ ]  Create a bodhi update for each release

Finally, if everything went well:

[ ]  Tag the commit with x.y.0, push tags git push --tags
[ ]  Manually merge the original release pull request on github (to avoid rebase)
[ ]  Create a new github release__ based on the tag above
[ ]  If the automation triggered by publishing the new github release
was not successful, publish the fresh code to the pypi__
repository manually using make wheel && make upload
[ ]  Once the copr build__ is completed, move the quay branch to
point to the release commit as well to build fresh container
images.
[ ]  Close the corresponding release milestone

Blockers:

[ ] https://github.com/teemtee/tmt/pull/1745
[ ] prune in finish deletes report files (html, junit)

All blockers should be resolved --> rebased.

Thank you for merging last fixes & the rebase. The full testsuite is still running.

Failure in /tests/provision/virtual/dependencies caused by timeout (VM in VM)
All other tests are green.


feat: add sources citation in response

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Adding Hunter Token Logo/info to MetaMask

On which chain it is deployed?

Chain ID: 97
BSC Smart Net
On Wed, Oct 26, 2022, 12:10 PM MRabenda @.***> wrote:

On which chain it is deployed?
—
Reply to this email directly, view it on GitHub
https://github.com/MetaMask/contract-metadata/pull/1106#issuecomment-1291570460,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXJFHG7BZRY3CUTBDBXWIEDWFDG5HANCNFSM6AAAAAARH4MWHU
.
You are receiving this because you authored the thread.Message ID:
@.***>


Add refresh policy setting when creating DeleteByQueryRequest

Description
Add refresh policy setting when creating DeleteByQueryRequest
(Is the wait_for option among the refresh options of Delete by query supported? An error occurs when making an actual request. see please opensearch-project/OpenSearch#12687)
Issues Resolved
See please #244
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Looks pretty straightforward. Needs tests, please?

Test code has been added. Should integration test code also be added?

Test code has been added. Should integration test code also be added?

Thank you @bcc829 , I think this is fine


Documentation: Rename names of systemd services

Hello,
When reading the latest documentation describing the systemd service install (and wondering why I could not find the gige-daemon service anymore), I noticed that it has been renamed and the documentation must be updated accordingly.
link
The documentation below has been updated already:
link
It also looks like the systemd service will not be installed, unless the flag TCAM_ENABLE_DATA_INSTALL is set, correct?

Hello there,
Thank you for the bug report! Fixed in 765b1ad3e265e0d8a2d70ead2b1c90d03b982ce7 on the development branch.

It also looks like the systemd service will not be installed, unless the flag TCAM_ENABLE_DATA_INSTALL is set, correct?

That is correct.


Add Python 3.10 to CI tests

Description
Add Python 3.10 to our test suite.
Motivation and Context
Good to keep testing against the latest Python version.
How Has This Been Tested?
Letting CI run against it.
Checklist

[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.

@tdilauro Please do not merge into main yet as the webpub library points to a repo branch at the moment

@tdilauro Please do not merge into main yet as the webpub library points to a repo branch at the moment

Okay. And you have it in draft status, which is a good way to ensure that it is NOT merged. 👍🏽

@RishiDiwanTT new version of webpub-manifest parser is release on PyPi now, so you should be able to pull that in here.
https://pypi.org/project/palace-webpub-manifest-parser/


Meta-Issue: EDTF dates

This is a meta issue to track developments and issues with regard to EDTF date form widget, validation, display, and indexing.
Please refer to this issue in any subsequent issues to link them.
Spreadsheet documenting EDTF-related behavior here: https://docs.google.com/spreadsheets/d/1cx2KTkELqCDxczIVQw6La_PTSgmqMj_KEr6dIKvszYg/edit#gid=0

Thanks for documenting all of these @kspurgin. We really need to write a set of tests to cover all these cases. I'm not sure when I'll be able to work through any of these, but I'm happy to review PRs if they come up.

I was thinking some of the simpler display things might be easy enough for meet to try fixing.
But at least the behavior is captured/documented now!

@nigelgbanks recently pointed out some EDTF PHP libraries in Slack:

https://github.com/ProfessionalWiki/EDTF
https://github.com/computerminds/php-edtf

The former looks to be currently maintained while the latter hasn't been touched in several years.
That said, we should probably do a head-to-head comparison and see if we can 🔥 much of our code in favor of one of these libraries.

So, ProfessionalWiki/EDTF looks nice. We could burn most of our code and it gives us a bit more functionality than we already have. I'm especially interested in the min and max functions it provides.
However, it requires PHP 7.4. I think this is fine for new installs of the next release. Existing sites that want to upgrade their islandora should be fine, but they wouldn't be able to upgrade their islandora_defaults (which I think we are also saying is okay) if they want to keep PHP 7.3. Thoughts, @Islandora/8-x-committers?

@seth-shaw-unlv we are using it in Archipelago and its a great choice.

I mentioned to @kspurgin above that we needed tests for identified issues. Turns out that we already do have tests, we just need to add these to the list. We've had this initial test set since last September. 🤦♂


Payload encryptions

Dear Eagan
Is there any option of soap service payload encryption using spring boot

Hi @sirussje - is it related directly to any of our articles? If not, I'd suggest contacting<EMAIL_ADDRESS>with that question and closing this one :)


Idle flow at ventilator startup.

Describe the bug
When the ventilator is started we get around 2-3 l/min of idle flow until the frontend has been completely booted up. This starts when the RaspberryPi OS has booted up till the frontend is loaded.
To Reproduce

Open the Air and O2 inputs.
Turn on the ventilator.

Expected behavior
There should not be any flow until instructed through the frontend.

My current hypothesis is that the PWM peripherals for driving the valves are not initialized before setup, and that initializing them to 0 may fix this problem. We'll need some testing to check this.


Update channels

Depends on
https://github.com/kubic-project/salt/pull/654

please review https://github.com/kubic-project/velum/pull/654 first

This PR currently has conflicts with our schema patch


FEATURE: encrypted 3d comp

@ring630 Is this data used for another public repo ? If yes, could you link to the associated PR / issue if any ?

@SMoraisAnsys password is added in the file name.

If the filename length is not a problem then you can keep things as they are. Otherwise you can add a new file with the password.


Docker Hub says the "latest" tagged image is built for linux/amd64 instead of linux/arm/v7

https://hub.docker.com/r/psychlist/docker-sonos-web-arm/tags

You're right, even though the image is definitely an ARM one.
This image was built by DockerHub, back in the days when builds were part of the free offering. The build uses the Balena cross-build feature, to create an ARM image on an amd64 host.
As Sonos-Web appears to be a dead project, I'm not planning to update the image, and I'll retire this repo.


Receiving a notification "outside app" while in it?

Is it possible to implement a function that always handles the notification "outside" the app even if the user is currently using it? Clicking on the notification could re-open the app and then call on event "notification".
As far as I know this needs to be handled with native code and cannot be implemented "backend".

Yes i have similar problem. please help.....

@marcus-chr Are you talking about what is described in Issue #93? If so please close this issue and add you comments to that issue.

@macdonst No, I don't think it's the same. This issue is about having the same "process" of receiving push notifications whether or not it is in background or foreground mode. Today it works like this:
Background:

Push shown in a banner/alert etc
User taps on notification
App starts
Event 'notification' is run

Foreground (user has the app opened):

Event 'notification' is run

I would like the foreground mode to work as the background. Maybe it doesn't necessarily need to re-open the app but at least do step 1,2 and 4 (instead of only 4). Let me know if this was clear or not :-)

@marcus-chr so this https://github.com/phonegap/phonegap-plugin-push/pull/178 which has been merged and will be in the next release.

Oh, I'm sorry. Should I close this issue now then?

Yup


Feature/charging station sequences

Moving from randomly generate requestIds to using a sequence table
Requests touched are updated to match latest format for custom actions.
requires changes in https://github.com/citrineos/citrineos-core/pull/283

Please note: Build is failing because currently using CORE v1.4.3 and need changes for ChargingStationSequences to be merged into CORE rc-1.5.0 for it to be available. We may want to consider adjusting the build job to clone core locally to ensure that latest rc branch is used to ensure that it is able to build properly


p2p: Move on-demand retrieval methods from LESPeer to LightPeerChain

This is in preparation for another PR that will redesign the handling
of peers in PeerSubscriber instances

I'm sneaking a fix to the lightchain integration test here as well. It's a trivial change, but if you want to have a look and have any suggestions I'd be happy to deal with them post merge