Add address relay/processed/rate-limited fields to peer details

This pull adds the following address fields in rpc getpeerinfo and cli -netinfo to the gui peers details:

Address Relay (Yes/No)
Addresses Processed (integer)
Addresses Rate-Limited (integer)

and uses the additional horizontal space to display "Last Transaction" (instead of "Last Tx").

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts
Reviewers, this pull request conflicts with the following ones:

#505 (RPCConsole: add hidePeersDetail() button and functionality by RandyMcMillan)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Thanks @w0xlt and @hebasto, updated.
git diff a00bc71 9fbd1bb
diff --git a/src/qt/forms/debugwindow.ui b/src/qt/forms/debugwindow.ui
index 174954087..219680102 100644
--- a/src/qt/forms/debugwindow.ui
+++ b/src/qt/forms/debugwindow.ui
@@ -1355,7 +1355,7 @@
                <item row="13" column="0">
                 <widget class="QLabel" name="peerLastTxLabel">
                  <property name="toolTip">
-                  <string>Elapsed time since a novel transaction accepted into our mempool was received from this peer.</string>
+                  <string extracomment="Tooltip text for the Last Transaction field in the peer details area.">Elapsed time since a novel transaction accepted into our mempool was received from this peer.</string>
                  </property>
                  <property name="text">
                   <string>Last Transaction</string>
@@ -1594,7 +1594,7 @@
                <item row="23" column="0">
                 <widget class="QLabel" name="peerAddrRelayEnabledLabel">
                  <property name="toolTip">
-                  <string>Whether we relay addresses to this peer.</string>
+                  <string extracomment="Tooltip text for the Address Relay field in the peer details area.">Whether we relay addresses to this peer.</string>
                  </property>
                  <property name="text">
                   <string>Address Relay</string>
@@ -1620,7 +1620,7 @@
                <item row="24" column="0">
                 <widget class="QLabel" name="peerAddrProcessedLabel">
                  <property name="toolTip">
-                  <string>Total number of addresses processed, excluding those dropped due to rate limiting.</string>
+                  <string extracomment="Tooltip text for the Addresses Processed field in the peer details area.">Total number of addresses processed, excluding those dropped due to rate-limiting.</string>
                  </property>
                  <property name="text">
                   <string>Addresses Processed</string>
@@ -1646,7 +1646,7 @@
                <item row="25" column="0">
                 <widget class="QLabel" name="peerAddrRateLimitedLabel">
                  <property name="toolTip">
-                  <string>Total number of addresses dropped due to rate limiting.</string>
+                  <string extracomment="Tooltip text for the Addresses Rate-Limited field in the peer details area.">Total number of addresses dropped due to rate-limiting.</string>
                  </property>
                  <property name="text">
                   <string>Addresses Rate-Limited</string>


claude is rate limiting

and the plugin is failing with error:
Unknown Claude protocol output: "{"type":"error","error":{"type":"rate_limit_error","message":"Number of request tokens has exceeded your per-minute rate limit (https://docs.anthropic.com/en/api/rate-limits); see the response headers for current usage. Please reduce the prompt length or the maximum tokens requested, or try again later. You may also contact sales at https://www.anthropic.com/contact-sales to discuss your options for a rate limit increase."}}"
Context: I was doing chat and it was browsing files, just 3 files was enough.

But you can simply delte the error and retry (perhaps with smaller open files and after bumping yourself to tier 1), as the error is non-fatal, right?
We could certainly make the message slightly prettier, is there anything else you'd expect? (Besides Anthropic being saner about rate limits, having a 200k context window model and all.)


Vscode buttons when navigated with keyboard dont show tooltips

Environment Details:
Application Name: Visual Studio Code
Application Version: 1.38.1 (user setup)
Commit: b37e54
Electron: 4.2.10
Node.js: 10.11.0
OS: Windows_NT x64 10.0.18362
Steps to Reproduce:

Open VSCode
Tab to left nav buttons or toast notification buttons
when tabbed through keyboard the tooltips don't show but when we reach these with mouse they show tooltip.

This affects the pattern that anything accessible by mouse should be accessible by keyboard as told by accessibility team. I do see some issues around this already around this but they are closed with dup and no activities- couldn't find the right one to use hence opening new. Please feel free to close if there is already one tracking this, apologies for the noise.
Please

Thanks for filling a human readable issue. We already have an issue tracking this  https://github.com/microsoft/vscode/issues/52016


Create a Construct to supply Deadline installers

We would like a construct which determines the S3 URI's for the Deadline installers and Deadline Docker recipes. The version of Deadline for these can be either specified by the user or defaulted to the latest version.
For now, this will be integrated with the Repository construct to get the repository installer for it to use. In the future we can extend it out to be used by other constructs that require Deadline installers or the Docker recipes as well.
Use Case

Currently to get the repository installer, we use hard-coded values that make assumptions about where the installer should be found in S3:
https://github.com/aws/aws-rfdk/blob/75d0f9fedce52de9dcfe73482965de923fa8941d/packages/aws-rfdk/lib/deadline/lib/version.ts#L293-L310
This would provide a more robust way of determining the installer locations
Proposed Solution

A VersionQuery Construct that contains a CustomResource that downloads the version index file and parses it, then returns the required information about the installers for a specific Deadline version.
The Repository construct will then take the versioned installers supplied by the VersionQuery construct, and use the repo installer.

[x] :wave: I may be able to implement this feature request
[x] :warning: This feature might incur a breaking change

This is a :rocket: Feature Request

Any plan to mirror the deadline installer to other aws partitions?

@zxkane - Thanks for reaching out! I've taken your feature request and made a separate issue (#207).


./bitconnect-qt: cannot execute binary file: Exec format error

pi@raspberrypi:~/Downloads $ unzip bitconnect-linux-qt.zip -d bitconnect
Archive:  bitconnect-linux-qt.zip
inflating: bitconnect/bitconnect-qt
pi@raspberrypi:~/Downloads $ ./bitconnect-linux-qt
bash: ./bitconnect-linux-qt: No such file or directory
pi@raspberrypi:~/Downloads $ ./bitconnect-qt
bash: ./bitconnect-qt: No such file or directory
pi@raspberrypi:~/Downloads $ cd bitconnect
pi@raspberrypi:~/Downloads/bitconnect $ ls
bitconnect-qt
pi@raspberrypi:~/Downloads/bitconnect $ ./bitconnect-linux-qt
bash: ./bitconnect-linux-qt: No such file or directory
pi@raspberrypi:~/Downloads/bitconnect $ ./bitconnect-qt
bash: ./bitconnect-qt: Permission denied
pi@raspberrypi:~/Downloads/bitconnect $ sudo ./bitconnect-qt
sudo: ./bitconnect-qt: command not found
pi@raspberrypi:~/Downloads/bitconnect $ chmod +x bitconnect-qt
pi@raspberrypi:~/Downloads/bitconnect $ ./bitconnect-qt
bash: ./bitconnect-qt: cannot execute binary file: Exec format error
pi@raspberrypi:~/Downloads/bitconnect $

This will not work because the Wallet is built for a for arm_64 and raspberry pis do not use that architecture

@d3orn I thought the Raspberry Pi 3 is an arm64 architecture. I can't seem to get it to work as well. Which OS is recommended? Ubuntu MATE?

Noobs is 64 bit, Ubuntu is also
Joel L Huebner
Lansing, IA 52151-0471
Short Message from Samsung S8+
JLH
On Nov 10, 2017 09:27, "nHzhpuV"<EMAIL_ADDRESS>wrote:

@d3orn https://github.com/d3orn I thought the Raspberry Pi 3 is an
arm64 architecture. I can't seem to get it to work as well. Which OS is
recommended? Ubuntu MATE?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bitconnectcoin/bitconnectcoin/issues/12#issuecomment-343502947,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMDDGEvzo6KS1CyNGeX3VS16g7fRdugsks5s1GtbgaJpZM4PTGi0
.

If that's the case, is there another reason why I'm also getting the "cannot execute binary file: Exec format error"?
And which version of the bitconnect wallet do I download? Ubuntu v16 64bit or linux-qt?

This might help.  From Unbuntu Wiki
https://wiki.ubuntu.com/ARM/RaspberryPi
Note that the information on this page currently only applies to the Raspberry Pi 2 and 3, not the original Raspberry Pi. The Raspberry Pi 3 does not (yet) work with official Ubuntu images out of the box, but unofficial images are available.


Gracefully degrade to private undefined copy constructor for C++03.

This PR degrades to using a private declared-but-not-defined copy constructor for compilers pre-C++11. I'm not necessarily of the opinion this should be merged, but it is worth consideration.
rviz for example is compiling with a warning because it is not enabling C++11 support while it is including retriever.h. The fact that this is a warning and not an error is actually a bit surprising to me, but basically resource_retriever has two choices: either require everything depending on it to compile with C++11 support (or later), or be pragmatic and avoid C++11 features in the public header.
Another question is: if resource_retriever requires C++11 support to use, should this be communicated somehow? Forcing compiler flags using catkin/cmake seems like a bad idea. The warning currently generated by gcc might already be sufficient I suppose, in which case no action is required at all and this can be closed :)

I asked about exporting the flag in https://github.com/ros/resource_retriever/pull/4#issuecomment-221044351 but didn't push on it at all.
I agree, if c++11 is used in the header file, then the flag should be exported in its cmake and pkg-config files.

What exactly does exporting the flag entail? I don't think forcing the flag on users would be a good idea. That would make it impossible (or difficult) for users to choose between -std=c++11 or -std=gnu++11, or even -std=c++14 (etc.).

In Kinetic we have started requiring a compiler with C++11 support: https://github.com/ros-infrastructure/rep/blob/master/rep-0003.rst#kinetic-kame-may-2016---may-2021
The default gcc and clang available on the Linux platforms supported in Kinetic have C++11 support, which is why we considered this a safe decision to make
We do not require packages to use std=c++11 but since we require a compiler with C++11 support we consider it acceptable to expose C++11-only features in the headers of packages.
When Steve refers to exporting the flag, I believe he means something like using set_target_properties in CMake, e.g.:  set_target_properties(${target}     PROPERTIES COMPILE_FLAGS "-std=c++11 -Wall -Wextra")
Because of the requirement for C++11 support in Kinetic I'm inclined not to accept this PR in its current implementation. If you find that using `set_target_properties in resource_retriever eliminates the warnings in Rviz without changing the compiler flags in Rviz, I would be happy to accept that change.
A bit of local experimentation with both g++ and clang++ indicates that setting both -std=c++11 and -std=c++14 to compile C++ code does not result in an error. It looks like the compiler simply uses the flag that was set later in the compiler invocation.

A bit of local experimentation with both g++ and clang++ indicates that setting both -std=c++11 and -std=c++14 to compile C++ code does not result in an error. It looks like the compiler simply uses the flag that was set later in the compiler invocation.

Setting the target properties will not help with warnings from public headers, since the warning is coming from a different target in a different package. I'm perfectly fine with that though. The warning is the indication that the package depending on resource_retriever should also switch to C++11. It's a shame (and somewhat weird) that it is not an error, then it would be more clear.
target_compile_options(${target} PUBLIC ...) would be able to force the compiler flag on other packages (I think), but I really wouldn't do that. They might suddenly be compiling with C++11 support without even knowing it, possibly for a subset of translation units. That is a recipe for disaster. A warning/error is good, but automatically forcing the flag on other packages is not.
If you want to make it more explicit we can add a static_assert(__cplusplus >= 201103L, "This header requires at least C++11 support."); to turn the current warning into an error.
I agree that adding workarounds like this PR to support older compilers is not necessarily the way to go. I thought it would be good to make a conscious decision whether or not to require users of resource_retriever to compile with C++11 support though. Especially because in this case the workaround is rather trivial.
But like I said, I don't have a strong opinion either way (except against automatically setting compile flags for users of resource_retriever). So feel free to close this PR if that is what you think is best. I can also make a new PR with a static_assert, but I have a feeling not all packages would be very pleased with that :]

After some discussion with the ROS team and advice from @wjwwood, I'm going to close this and look into using a pragma directive for suppressing the warning for gcc versions less than 6 in this header (C++11 is the default in gcc 6). We think this is the least intrusive change for downstream packages that will also suppress the warning.

Err, I think that is a strange approach. I'm fine with closing this PR, but either use C++11 in your public header or don't. Don't use C++11 and "support" compiling without C++11 by suppressing the warning. If you want to support packages without C++11, do it properly and don't depend on C++11 features in the header (or in other words, merge this).

@de-vri-es I think you're missing the point that this is a warning. It will work if the warning is suppressed. In my opinion GCC is not doing the right thing here. It supports a feature and warns you that it does... In GCC 6 it will no longer be a warning. I don't see any problem with suppressing the warning.

I can expand on our thought process here a bit. We can use C++11 features in Kinetic, so we don't want to gate C++11 features on #ifdef's as proposed here. So we're left with two options, set the flag -std=c++11 or disable the warning. We can do either by exporting from the package that uses the C++11 feature or by enabling C++11 (or the warning suppression) in every consuming package.
We decided it was better that the solution was exported by the user of C++11 features rather than by the consumer, because the set was smaller and because it makes sense that people using C++11 would know best when to set it up.
We decided on the warning suppression because it won't break any code, we know we're doing it and it's what we mean to do (we're not trying to adhere to C++03 but accidentally using a C++11 feature) and it doesn't produce the problems you described with overlapping flags like -std=gnu++11 or -std=c++14.
So in that light, I think suppressing the warning is the easiest, least intrusive approach and it can be dropped altogether in the next Ubuntu which uses GCC6 (which defaults to C++11).

To be pedantic, 14 is the default in GCC 6.1: https://gcc.gnu.org/projects/cxx-status.html#cxx14

@jacquelinekay that's true 😄

The fact that GCC is giving a warning and not an error is unfortunate. However, it is doing the right thing by not silently compiling C++11 code when using the C++03 standard. Suppressing the warning (which I really feel should be an error) makes no sense when there is a sane alternative, presented in this PR.
The issue is that resource_retriever is using a C++11 feature in a public header while the other package is compiling without C++11 support. To fix that there are two options, either not use C++11 in the public header here, or compile with C++11 support elsewhere. I really feel that removing the visible symptom while leaving the problem in place is plain wrong.
Especially when a solution has already been presented that solves the real underlying issue.

Wrapping all public headers that use C++11 is also not a scalable solution. This PR is less intrusive than that. Alternatively, adding #pragma GCC system_header directly in the header itself might be less intrusive but also a bad idea as it will prevent the compiler from generating any useful diagnostics on any code in the header, including future additions.
As for forcing a specific C++ standard on users is asking for trouble. It complicates matters for the user if he wants to use a different compatible standard, and worse, it may result in only certain targets being built with C++11 support leading to subtle, hard to detect and worse to debug problems.
If this PR is not merged, the best solution is to do nothing at all. Don't suppress the warning, at least packages using the header will be aware of the issue if they're looking at the compiler output. That is what the warning is for. Forcing a C++ standard on the other packages is similarly bad.

Wrapping all public headers that use C++11 is also not a scalable solution. This PR is less intrusive than that.

For this one instance, that is true. But what if a header uses std::shared_ptr. Conditionally wrapping that up as you have done the deleted constructor in this header would be a lot of conditional code and makes no sense to me given that this version of the software (kinetic-devel) requires C++11. There's no reason to conditionally use some non-c++11 option in the header. The fixed cost of my solution is 3-5 lines (depending on the behavior of the pragma which I haven't tested yet) and the variable cost is zero. And only for headers that produce the warning.

Alternatively, adding #pragma GCC system_header directly in the header itself might be less intrusive but also a bad idea as it will prevent the compiler from generating any useful diagnostics on any code in the header, including future additions.

No one is suggesting we use the system_header pragma. I agree that's not a good idea.

As for forcing a specific C++ standard on users is asking for trouble. It complicates matters for the user if he wants to use a different compatible standard, and worse, it may result in only certain targets being built with C++11 support leading to subtle, hard to detect and worse to debug problems.

I agree, that's why I am in favor of suppressing the warning. On compilers that don't actually support the feature, it will produce an error and then the downstream users really will have to get a newer compiler or explicitly turn on C++11. So long as it's a warning, and the feature actually works, and we know that we're doing this explicitly, it's the least intrusive option and the option that causes the least new work for all users of ROS.

If this PR is not merged, the best solution is to do nothing at all. Don't suppress the warning, at least packages using the header will be aware of the issue if they're looking at the compiler output. That is what the warning is for. Forcing a C++ standard on the other packages is similarly bad.

I agree that it would be more correct to do nothing in this package and for every package to explicitly turn on C++11, but it's also an extremely intrusive and costly change as it touches every single package at some point. This is especially wasteful since in the next version of ROS and Ubuntu (and therefore GCC) it will not be required.
So we're making a trade-off in correctness for convenience. It's not perfect, but I think it's a better solution for the vast majority of users who simply do not care about the std to the compiler is compiling.

For this one instance, that is true. But what if a header uses std::shared_ptr. Conditionally wrapping that up as you have done the deleted constructor in this header would be a lot of conditional code and makes no sense to me given that this version of the software (kinetic-devel) requires C++11.

Using std::shared_ptr will simply fail to compile in GCC without C++11 support (also true in 6+ with -std=c++03), so it would simply force other packages to manually enable C++11 support if they want to use that public header. If that is acceptable I don't see why it is not acceptable here.
But, how about sidestepping the issue? There is another option in this case: inherit from boost::noncopyable [1]. I know it adds a dependency on boost, but using ROS without boost isn't possible anyway. That way a correct method of making the object non-copyable is chosen for every compiler under the sun (and more) while the details are completely hidden from us.
[1] http://www.boost.org/doc/libs/master/libs/core/doc/html/core/noncopyable.html

Using std::shared_ptr will simply fail to compile in GCC without C++11 support (also true in 6+ with -std=c++03), so it would simply force other packages to manually enable C++11 support if they want to use that public header. If that is acceptable I don't see why it is not acceptable here.

You're right, in that scenario you'd have to turn c++11 on in the consuming packages. And that is an acceptable solution here too. In fact I will probably turn c++11 on in rviz for this very reason. But again, I'm not concerned about rviz so much, but rather all the hundreds of user packages out there that might consume a header which uses something like the deleted constructor or auto or range for loops, which will work with just a warning. I want to minimize the number of packages which need to be touched in order to avoid this warning (especially since that touch will no longer be necessary in the near future).
Perhaps those users will not care if there is a warning. So with that assumption, I'm also ok to do nothing and packages which care can turn on C++11 so long as we collectively agree that's a acceptable. But conditionally using C++11 as was proposed here is in my opinion counter-productive to having c++11 as a requirement in REP-3.

But, how about sidestepping the issue? There is another option in this case: inherit from boost::noncopyable [1].

That would work for this instance. What we're talking about, at least what I'm concerned with, is what the common recommendation is, especially where there is no simple work around using boost or where avoiding boost is the whole point.

Perhaps those users will not care if there is a warning. So with that assumption, I'm also ok to do nothing and packages which care can turn on C++11 so long as we collectively agree that's a acceptable. But conditionally using C++11 as was proposed here is in my opinion counter-productive to having c++11 as a requirement in REP-3.

I agree in general, but there is a certain amount of pragmatism that can be applied to reduce practical problems, especially in the case of core packages that are frequently used by other packages. But as I said before, on this point I don't have a very strong opinion.

But, how about sidestepping the issue? There is another option in this case: inherit from boost::noncopyable [1].

That would work for this instance. What we're talking about, at least what I'm concerned with, is what the common recommendation is, especially where there is no simple work around using boost or where avoiding boost is the whole point.

I understand. As a common recommendation I really feel suppressing this warning is not the way to go. I would go with "enable C++11 support in your project". Like you say, this specific header will even compile with reasonably old GCC. If anything the warning is at least an indication that something is wrong.
As a common recommendation, suppressing these types of warnings isn't even feasible as there is only a limited set of features where this is only a warning (I don't have a complete list, but afaik any standard library additions are unavailable, as is nullptr, probably most features).
I also think that, in general, it is best to analyse the specific problem and use a solution that fits the circumstances best. In this case, it is pretty easy to remove the hard dependency on C++11 (either with #ifdefs or offloading to boost) so I do see it as a viable alternative (to doing nothing).

As a common recommendation I really feel suppressing this warning is not the way to go.

I understand your position, I was hoping for a pragmatic approach that's not perfectly correct, but maximally convenient for users, but I think the number of situations in which suppressing the warning will help is pretty small, as you pointed out.

it is pretty easy to remove the hard dependency on C++11 (either with #ifdefs or offloading to boost)

Then why even use C++11 at all? Presumably you'd switch to it to gain some benefit. Conditionally not using it doesn't seem to add any value to me.
I think that we'll just go with "do nothing here" and recommend people who run into the issue turn c++11 on for their packages, as I did with rviz. That is unless anyone disagrees.

Then why even use C++11 at all? Presumably you'd switch to it to gain some benefit. Conditionally not using it doesn't seem to add any value to me.

True enough. There would be a slight improvement in the error message generated by the compiler with the C++11 version, but that is hardly worth the effort.
Anyway, thank you for your patience and taking the time to think about all this.


Contributing testing docs

@alexcrichton can you take a quick look at the headless test configuration docs here?
Once we publish wasm-bindgen-test, this should all probably move into the guide.

👍


migrate docker compose templates to V3.

Leverage the new elements such as "healthcheck", "secret",etc.

https://github.com/vmware/harbor/pull/3123

Ah, thanks @wdhif

This has implications on the VCH. @sflxn

Removing the target as confirmed with Pietro this is a low priority.


Performance Issues w/ Mekanism Machines

According to Opis, Mekanism machines have a pretty high tick rate on the server, perhaps look at TE's code to reduce lag?

What version of mekanism?

<IP_ADDRESS>

Mekanism Lag Test, All Setup, Opis

Mekanism Lag Test, All Setup, TPS

Mekanism Lag Test, Mekanism Setup, Opis

Mekanism Lag Test, Mekanism Setup, TPS

Mekanism Lag Test, XU Setup, Opis

Mekanism Lag Test, XU Setup, TPS

Mekanism Setup- Means Mekanism machines were placed
XU Setup- Means Extra Utilities pipes/nodes were placed
All Setup- Means Mekanism & XU items were placed
TPS was obtained from /cofh tps
MobiusCore & Opis are version 1.2.5
The reason that the XU nodes seemed to cause a bit more lag is that it was 7-10 transfer nodes with 4 stacks of world interaction upgrades making cobble, and 1 stack of speed upgrades.
The Mekanism machines had no speed upgrades, and were processing gold ore.
This was in a creative test flat world, so performance on a real world would be much more drastic.

@catzs you do relise those numbers are actually micro seconds, even smaller then milliseconds - hence the symbol of μs
1 millisecond = 1000 μs
There is 20 ticks to a second so 1 tick = 5 seconds.
5 seconds = 5,000,000μs - 5 million μs per tick.

@spannerman79 Something's gone wrong with either your maths or your typing there. By that maths 1 second = 20 ticks = 20 * (5 seconds) = 100 seconds :p
A tick is 50ms, which is 50,000μs. Still a lot of μs, but not quite 5 million.
Anyway, I note that the worst Mekanism machine for tick time is an Elite Factory - To be expected, as it's effectively 7 machines working concurrently. Speed upgrades should have no effect on tick time. Looking at that profile, I see no real reason to believe Mekanism is significantly less server-friendly than ExtraUtilities, which I'm pretty happy with as I know server-friendliness is a priority for XU.

Err re read as I did update my comment @unpairedbracket

Oh sorry, seems I didn't refresh quickly enough.

its ok @unpairedbracket,  the moment i hit Comment i had a Homer moment - duh! lol
@catzs 23.514μs for a single tile that in essence 7 factories working at once is very good.  Much better then having 7 furnaces with hoppers and chests setup via vanilla method

Chiming in on this as well, I have a large server with several in-game users with about 360 elite factories going.. they are VERY tick friendly.

I can also confirm that this is nothing. Try having <IP_ADDRESS> with one mekanism fanatic consuming across his base area chunks over 200k microseconds... that's 4 ticks in update time. That was an absolute bitch... Especially as it was mainly coming from dynamic tanks that we couldn't afford to get rid of.

Those tick times look very okay.  I wouldn't call this an issue.


No download from MediaKlikk

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 reporting that yt-dlp is broken on a supported site
[X] I've verified that I'm running yt-dlp version 2023.07.06 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
Hungary
Provide a description that is worded well enough to be understood
It looks like they changed something around  the video access urls on  mediaklikk.hu. The download no longer works.
Provide verbose output that clearly demonstrates the problem

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

Complete Verbose Output
[debug] Command-line config: ['-vU', 'https://mediaklikk.hu/video/2023/09/14/ez-itt-a-kerdes-2023-szeptember-14']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b532a3481] (pip)
[debug] Python 3.11.5 (CPython x86_64 64bit) - macOS-11.7.2-x86_64-i386-64bit (OpenSSL 3.1.2 1 Aug 2023)
[debug] exe versions: ffmpeg 6.0-tessus (setts), ffprobe 6.0-tessus
[debug] Optional libraries: Cryptodome-3.18.0, brotli-1.0.9, certifi-2023.07.22, mutagen-1.47.0, sqlite3-2.6.0, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1855 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>yt-dlp is up to date<EMAIL_ADDRESS>[MediaKlikk] Extracting URL: https://mediaklikk.hu/video/2023/09/14/ez-itt-a-kerdes-2023-szeptember-14
[MediaKlikk] ez-itt-a-kerdes-2023-szeptember-14: Downloading webpage
[MediaKlikk] 6724915: Downloading webpage
ERROR: [MediaKlikk] ez-itt-a-kerdes-2023-szeptember-14: Unable to extract playlist_url; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/usr/local/Cellar/yt-dlp/2023.7.6_1/libexec/lib/python3.11/site-packages/yt_dlp/extractor/common.py", line 710, in extract
    ie_result = self._real_extract(url)
                ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/Cellar/yt-dlp/2023.7.6_1/libexec/lib/python3.11/site-packages/yt_dlp/extractor/mediaklikk.py", line 88, in _real_extract
    self._html_search_regex(r'\"file\":\s*\"(\\?/\\?/.*playlist\.m3u8)\"', player_page, 'playlist_url')).replace('\\/', '/'))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/Cellar/yt-dlp/2023.7.6_1/libexec/lib/python3.11/site-packages/yt_dlp/extractor/common.py", line 1294, in _html_search_regex
    res = self._search_regex(pattern, string, name, default, fatal, flags, group)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/Cellar/yt-dlp/2023.7.6_1/libexec/lib/python3.11/site-packages/yt_dlp/extractor/common.py", line 1258, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)

Duplicate of #8053
Fixed in master, you can install it with pip

oh I somehow missed that, thanks for the quick reply


Implement ECDSA signature verification

we should be able to use gnark-crypto for this

Done in #1333


make neariso generation a default part of propagate

Per our conversation earlier -- the people like the neariso interface. We should generate those tables during propagate. (paraphrased from @randalburns)
The issue we're having right now is if the neariso table doesn't exist, the call to get data with the neariso interface in ndviz/neuroglancer fails. As a quick fix, we could exclude neariso from projinfo unless those tables exist, explicitly.

See #415


Add hexdocs documentation

At the moment we have very poor documentation.
It is required to add detailed documentation of all modules and publish it on https://hexdocs.pm
This will help other developers use and contribute to this library

OK, I'll start write it very soon


Add texture arrays

Problem
Array textures are not currently supported, but will be necessary for example in #44.
Feature
Add support of texture arrays.
Dependencies

#114

As there is no concrete use case that requires this feature, it will not be implemented for the moment.


sudo rclone does not gracefully handle SIGINT when entering configuration password

What is your rclone version (eg output from rclone -V)
rclone v1.36
Which OS you are using and how many bits (eg Windows 7, 64 bit)
Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
Debian 8.7
Which cloud storage system are you using? (eg Google Drive)
Multiple
The command you were trying to run (eg rclone copy /tmp remote:tmp)
Any when configuration password is used
A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)
Not applicable

To reproduce:

Have a configuration password for rclone
Launch rclone with sudo rclone
press ctrl+c when entering password
No character input is shown, enter works as expected

To temporarily fix:

Make sure your input is clear
Enter "reset"
Your terminal will now reset itself and return to full operating condition

OR

Launch a new terminal

I can't replicate this on Ubuntu 16.10.
When I CTRL-C the terminal is reset properly.
Which terminal are you using?
Do you have to use sudo to see the problem?

Ah, you have to also be inside a screen.


Update Dart.gitignore

Modify patterns to explicitly match directories
Modified patterns to match files created by tool in Dart SDK 1.12:

Added patterns matching files listed in https://www.dartlang.org/tools/private-files.html
Added *.js, removed *.js_, *.dart.js to match files created by dart2js

@ArgentiApparatus thanks for the first link, really explain it well.
Do you have a link summarizing the recommended changes for dealing with dart2js's output? I can only see these rules mentioned from the first link.
*.dart.js
*.js_
*.js.deps
*.js.map

https://www.dartlang.org/tools/private-files.html should be authoritative, but experiments with SDK 1.12 dart2js showed that .js, .js.deps and .js.map only are created. Presumably an earlier version of dart2js created that .js_.
I believe the contents of the Dart tools webpages are on Github, if so I'll look for or create a issue for that page.
pub build creates a .dart.js file, but it is in the ./build/ directory, and hence excluded by the pub patterns.
Note I pushed a commit to my branch adding *.info.json which I noticed when reading through https://www.dartlang.org/tools/dart2js/

A little more research turned up https://stackoverflow.com/questions/20314796/which-files-are-generated-when-executing-dart2js-and-why
I pushed another commit adding *.precompiled.js

@ArgentiApparatus thanks for the extra details. I'm happy to take this in.

Thanks!


Flint failed to find Readme.md

Would you be open to making flint case insensitive? https://github.com/pengwynn/flint/blame/master/flint/flint.go#L18-L22

This still has not been merged.  It's also failing to find "license" as I can only assume it's searching for "LICENSE".

:cry:

Patches are welcome. :grinning:

Looks like NathanielChanning forked and patched, just never submitted a pull request.


MINOR: add unit test for KGroupedTable.count

Checkstyle failure: streams:checkstyleTest[ant:checkstyle] /x1/jenkins/jenkins-slave/workspace/kafka-trunk-git-pr-jdk7/streams/src/test/java/org/apache/kafka/streams/kstream/internals/KGroupedTableImplCountTest.java:34:1: Disallowed import - org.hamcrest.core.Is.is.
Do we have to introduce this dependency? In general we want to have as less external dependencies as possible.

It is a test dependency - so api users don't see it.
it doesn't include any new jars.
This has been a standard way of writing junit tests for a number of years

@dguy: Some background information regarding your earlier comment:  The Kafka project has been pretty sensitive to introducing new dependencies, including test-scope dependencies.  That said, I'm on your side. :-)  This question is perhaps something we should discuss with other Kafka folks, because -- intentionally over-simplified -- I'd prefer us not to be stuck with assertEquals until eternity...

@guozhangwang : Can you take a look again?  It'd be great to include this test improvement before the 0.10 release.

Jenkins failure is tracked in #1258. LGTM and merged to trunk. Thanks @dguy !


Dynomite Log File Grows Indefinitely

I am seeing an issue in our production setup where Dynomite Log file grows indefinitely while printing the logs and system eventually reaches disk full condition and services are impacted.
[2019-06-19 09:51:01.905] dnode_accept:157 Accepting client connection from <IP_ADDRESS>:40460 on sd 1023
[2019-06-19 09:51:01.905] dnode_accept:145 accept on <CONN_PEER_PROXY 0xd54260 9 listening on '<IP_ADDRESS>:5002'> failed: Too many open files
[2019-06-19 09:51:01.905] dnode_recv:214 <CONN_PEER_PROXY 0xd54260 9 listening on '<IP_ADDRESS>:5002'> Failed to accept a connection. Continuing
This happened once in the past on 19th June and same issue was seen again yesterday.
I have seen an earlier post 424. However, this issue seems to have been fixed and i am using a build  v0.6.9.
Dynomite Config:
dyn_o_mite:
datacenter: dc-cak
rack: rack2
dyn_listen: <IP_ADDRESS>:5002
dyn_seeds:
#Distribution to dynomite instances on CAK-Redis1 server

<IP_ADDRESS>:5001:rack1:dc-cak:0
<IP_ADDRESS>:5002:rack1:dc-cak:1073741824
<IP_ADDRESS>:5003:rack1:dc-cak:2147483648
<IP_ADDRESS>:5004:rack1:dc-cak:3221225472
#Distribution to dynomite instances on cak-Redis2 server (other than self)
<IP_ADDRESS>:5001:rack2:dc-cak:1073741824
<IP_ADDRESS>:5003:rack2:dc-cak:2147483648
<IP_ADDRESS>:5004:rack2:dc-cak:3221225472
#Distribution to dynomite instances on rch-Redis1 server
<IP_ADDRESS>:5001:rack1:dc-rch:0
<IP_ADDRESS>:5002:rack1:dc-rch:1073741824
<IP_ADDRESS>:5003:rack1:dc-rch:2147483648
<IP_ADDRESS>:5004:rack1:dc-rch:3221225472
#Distribution to dynomite instances on rch-Redis2 server
<IP_ADDRESS>:5001:rack2:dc-rch:0
<IP_ADDRESS>:5002:rack2:dc-rch:1073741824
<IP_ADDRESS>:5003:rack2:dc-rch:2147483648
<IP_ADDRESS>:5004:rack2:dc-rch:3221225472
listen: <IP_ADDRESS>:6312
servers:
<IP_ADDRESS>:6302:1
tokens: '0'
data_store: 0
stats_listen: <IP_ADDRESS>:6322
read_consistency : DC_ONE
write_consistency : DC_ONE

Any clues on what could have gone wrong?

Below logs are seen continuously.
[2019-08-05 16:48:53.637] client_unref_internal_try_put:94 <CONN_CLIENT 0x2299b20 -1 from '<IP_ADDRESS>:40284'> unref owner <POOL 0x222b0e0 'dyn_o_mite'>
[2019-08-05 16:48:53.637] client_unref_internal_try_put:94 <CONN_CLIENT 0x229a330 -1 from '<IP_ADDRESS>:40286'> unref owner <POOL 0x222b0e0 'dyn_o_mite'>

@guruprasadb80 We use internal tooling at Netflix to do log rotation, and that's why it's not implemented as part of Dynomite. It's fairly easy to set up yourself however.
Eg: https://linux.die.net/man/8/logrotate

Below logs are seen continuously.
[2019-08-05 16:48:53.637] client_unref_internal_try_put:94 <CONN_CLIENT 0x2299b20 -1 from '<IP_ADDRESS>:40284'> unref owner <POOL 0x222b0e0 'dyn_o_mite'>
[2019-08-05 16:48:53.637] client_unref_internal_try_put:94 <CONN_CLIENT 0x229a330 -1 from '<IP_ADDRESS>:40286'> unref owner <POOL 0x222b0e0 'dyn_o_mite'>

Does your problem solve? I've been in this situation, too. What does this log entry mean?
client_unref_internal_try_put:94 <CONN_CLIENT 0x2299b20 -1 from '<IP_ADDRESS>:40284'> unref owner <POOL 0x222b0e0 'dyn_o_mite'>


Missing onnxruntime-genai-jni library

Describe the bug
Building Java API and use the generated artifacts in another application however I got the below error while using the sample SimpleGenAI class.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no onnxruntime-genai-jni in java.library.path: .../onnxruntime-genai/build/macOS/Release
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2434)
	at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818)
	at java.base/java.lang.System.loadLibrary(System.java:1993)
	at ai.onnxruntime.genai.GenAI.load(GenAI.java:214)
	at ai.onnxruntime.genai.GenAI.init(GenAI.java:61)
	at ai.onnxruntime.genai.Model.<clinit>(Model.java:81)
	at SimpleGenAI.<init>(SimpleGenAI.java:34)
	at Main.main(Main.java:7)

To Reproduce
Steps to reproduce the behavior:

Build Java API from source
Add onnxruntime-genai/src/java/build/libs/onnxruntime-genai-0.4.0-dev as a dependency to your project
Add onnxruntime-genai/build/macOS/Release as native library location to your project
Run below script

import ai.onnxruntime.genai.GenAIException;
import ai.onnxruntime.genai.GeneratorParams;

public class Main {

    public static void main(String[] args) throws GenAIException {
        SimpleGenAI generator = new SimpleGenAI(".../gemma_2_2b_it");
        GeneratorParams params = generator.createGeneratorParams("What's 6 times 7?");
        String result = generator.generate(params, null);
        System.out.println(result);
    }
}

Expected behavior
I expect no missing JNI library errors
Screenshots

Desktop (please complete the following information):

OS: MacOS (m2)

Additional context

Python build is successful ✅
Java build results like below ⬇

...
BUILD SUCCESSFUL in 1s
5 actionable tasks: 5 executed
[ 96%] Built target onnxruntime-genai4j
[ 96%] Building CXX object src/java/CMakeFiles/onnxruntime-genai-jni.dir/src/main/native/ai_onnxruntime_genai_Tensor.cpp.o
/onnxruntime-genai/src/java/src/main/native/ai_onnxruntime_genai_Tensor.cpp:24:18: error: cannot initialize a variable of type 'const int64_t *' (aka 'const long long *') with an rvalue of type 'jlong *' (aka 'long *')
  const int64_t* shape_dims = env->GetLongArrayElements(shape_dims_in, /*isCopy*/ 0);
                 ^            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [src/java/CMakeFiles/onnxruntime-genai-jni.dir/src/main/native/ai_onnxruntime_genai_Tensor.cpp.o] Error 1
make[1]: *** [src/java/CMakeFiles/onnxruntime-genai-jni.dir/all] Error 2
make: *** [all] Error 2
…
'Release']' returned non-zero exit status 2.

Hi @pekzeki thanks for the report. I'll see what I can do after I get back my mac device.

It seems that AppleClang has more strict type requirement, @pekzeki , could you please try the following change:
-  const int64_t* shape_dims = env->GetLongArrayElements(shape_dims_in, /*isCopy*/ 0);
+  const int64_t* shape_dims = reinterpret_cast<int64_t *>(env->GetLongArrayElements(shape_dims_in, /*isCopy*/ 0));

Error has gone. Thanks for the help! @skyline75489

@pekzeki Could you please share you experience with GenAI? Did you get the expected output? We have limited resource to fully test GenAI across different devices, especially Apple devices. Any feedback would be helpful. Thanks.

Sure!
Currently, I am exploring the capabilities of onnxruntime-genai. Previously, my team built an ML toolkit on onnxruntime, and now I am searching for a component that can help run SLMs (e.g., gemma-2b, phi-4b, etc.) on a CPU. I am specifically interested in running those models on the JVM.
I had to spend some time building the library and following related GitHub issues to get it running. It would have been easier if I could directly download artifacts from somewhere. The library works as expected on my macOS (M3) device. Although I haven't run extensive tests, it seems that running these SLMs on the JVM generates content approximately 20% faster.
One thing I haven't been able to do is compile the library for Windows, as I don't have a native Windows machine. I tried doing it on a virtual Windows 11 machine, and while I was able to build the library successfully with the related ARM64 packages, I kept getting the following error when loading:
Can't load ARM 64-bit .dll on an AMD 64-bit platform

Hope this helps 🙏

I managed to resolve the ARM <-> AMD compatibility issue after switching to Microsoft ARM64 JDK however I cannot produce the onnxruntime-genai-jni library due to below error.
  BUILD SUCCESSFUL in 15s
  5 actionable tasks: 5 executed
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): warning MSB8065: Custom build for item "C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\CMakeFiles\4d3ff2e7ea1390088edab65ca44f29c6\onnxruntime-genai.jar.rule" succeeded, but specified output "c:\users\u1\x64-jdk\onnxruntime-genai\src\java\build\libs\onnxruntime-genai.jar" has not been created. This may cause incremental build to work incorrectly. [C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\src\java\onnxruntime-genai4j.vcxproj]
  Building Custom Rule C:/Users/u1/x64-jdk/onnxruntime-genai/src/java/CMakeLists.txt
  ai_onnxruntime_genai_Generator.cpp
  ai_onnxruntime_genai_GeneratorParams.cpp
C:\Users\u1\x64-jdk\onnxruntime-genai\src\java\src\main\native\ai_onnxruntime_genai_Generator.cpp(60,47): error C2220: the following warning is treated as an error [C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\src\java\onnxruntime-genai-jni.vcxproj]
C:\Users\u1\x64-jdk\onnxruntime-genai\src\java\src\main\native\ai_onnxruntime_genai_Generator.cpp(60,47): warning C4267: 'argument': conversion from 'size_t' to 'jsize', possible loss of data [C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\src\java\onnxruntime-genai-jni.vcxproj]
C:\Users\u1\x64-jdk\onnxruntime-genai\src\java\src\main\native\ai_onnxruntime_genai_Generator.cpp(62,45): warning C4267: 'argument': conversion from 'size_t' to 'jsize', possible loss of data [C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\src\java\onnxruntime-genai-jni.vcxproj]
  ai_onnxruntime_genai_Images.cpp
  ai_onnxruntime_genai_Model.cpp
  ai_onnxruntime_genai_MultiModalProcessor.cpp
  ai_onnxruntime_genai_NamedTensors.cpp
  ai_onnxruntime_genai_Sequences.cpp
C:\Users\u1\x64-jdk\onnxruntime-genai\src\java\src\main\native\ai_onnxruntime_genai_Sequences.cpp(37,47): error C2220: the following warning is treated as an error [C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\src\java\onnxruntime-genai-jni.vcxproj]
C:\Users\u1\x64-jdk\onnxruntime-genai\src\java\src\main\native\ai_onnxruntime_genai_Sequences.cpp(37,47): warning C4267: 'argument': conversion from 'size_t' to 'jsize', possible loss of data [C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\src\java\onnxruntime-genai-jni.vcxproj]
C:\Users\u1\x64-jdk\onnxruntime-genai\src\java\src\main\native\ai_onnxruntime_genai_Sequences.cpp(38,45): warning C4267: 'argument': conversion from 'size_t' to 'jsize', possible loss of data [C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\src\java\onnxruntime-genai-jni.vcxproj]
  ai_onnxruntime_genai_Tensor.cpp
  ai_onnxruntime_genai_Tokenizer.cpp
  ai_onnxruntime_genai_TokenizerStream.cpp
  utils.cpp
  Generating Code...
  Building Custom Rule C:/Users/u1/x64-jdk/onnxruntime-genai/build/Windows/Release/_deps/googletest-src/googletest/CMakeLists.txt
  gtest-all.cc
  gtest.vcxproj -> C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\lib\Release\gtest.lib
  Building Custom Rule C:/Users/u1/x64-jdk/onnxruntime-genai/build/Windows/Release/_deps/googletest-src/googletest/CMakeLists.txt
  gtest_main.cc
  gtest_main.vcxproj -> C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\lib\Release\gtest_main.lib
  Building Custom Rule C:/Users/u1/x64-jdk/onnxruntime-genai/test/CMakeLists.txt
  main.cpp
  c_api_tests.cpp
  model_tests.cpp
  sampling_tests.cpp
  sampling_benchmark.cpp
  Generating Code...
     Creating library C:/Users/u1/x64-jdk/onnxruntime-genai/build/Windows/Release/test/Release/unit_tests.lib and object C:/Users/u1/x64-jdk/onnxruntime-genai/build/Windows/Release/test/Release/unit_tests.exp
  unit_tests.vcxproj -> C:\Users\u1\x64-jdk\onnxruntime-genai\build\Windows\Release\test\Release\unit_tests.exe
Traceback (most recent call last):
  File "C:\Users\u1\x64-jdk\onnxruntime-genai\build.py", line 571, in <module>
    build(arguments, environment)
  File "C:\Users\u1\x64-jdk\onnxruntime-genai\build.py", line 520, in build
    util.run(make_command, env=env)
  File "C:\Users\u1\x64-jdk\onnxruntime-genai\tools\python\util\run.py", line 56, in run
    completed_process = subprocess.run(
                        ^^^^^^^^^^^^^^^
  File "C:\Users\u1\AppData\Local\Programs\Python\Python312-arm64\Lib\subprocess.py", line 571, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['C:\\Program Files\\CMake\\bin\\cmake.EXE', '--build', 'C:\\Users\\u1\\x64-jdk\\onnxruntime-genai\\build\\Windows\\Release', '--config', 'Release']' returned non-zero exit status 1.

Do you have any suggestions?

We're treating all warnings as errors on Windows. I think a cast would work. Could you please try:
- jintArray java_int_array = env->NewIntArray(num_tokens);
+ jintArray java_int_array = env->NewIntArray((jsize)num_tokens);

@pekzeki Did you manage to try the above suggestion?

This issue has no activity in the last month. Most Java related issue should be fixed in #1030 . Feel free to reopen if you have another problem with the library..


Odata with Entity Framework and navigation properties

Hi
I'm using Simple.Odata together with Entity framework code-first. I use EF on server to communicate with SQL database and odata on client side which is written in c#. I use exactly the same model classes on both sides. Example model classes below:
public class Parent
{
	public Parent()
	{
		Children = new HashSet<Child>();
	}

	[Key]
	Guid GUID { get; set; }

        public string Name { get; set; }

	public virtual ICollection<Child> Children { get; set; }
}

public class Child
{
	[Key]
	Guid GUID { get; set; }

        public string Name { get; set; }

	public Guid ParentGUID { get; set; }

	public Parent Parent { get; set; }
}

Everything works (querying, adding, updating etc) but I have a very annoying problem that occurs with updates. I does not matter if I use PUT or PATCH.
When I try to update a child record using this line of code from client side:
						Child child = await client.For("Child").Key(myGUID).Set(myChild).UpdateEntryAsync();
This line of code is run on server side in ODataController:
return Updated(child);
The update works but the following output is printed in debug console on server:
Exception thrown: 'System.Web.Http.HttpResponseException' in System.Web.OData.dll
Also on client side:
Exception thrown: 'Simple.OData.Client.WebRequestException' in mscorlib.dll
Only way to make it dissaper is to mark Parent in Child as [NotMapped]
[NotMapped]
public Parent Parent { get; set; }
This however removed navigation property Parent from Child in metadata which I don't want.
 What is the correct way of creating POCO classes with one-to-many relations?

Hi,
Your entity classes look good and from your description I don't know what's causing the problem. Are you sure the error isn't server side? Judging from the exception type ( 'System.Web.Http.HttpResponseException' in System.Web.OData.dll) it looks like it's the server and I'd investigate it first.


Design system

Expectations

Have a design language for ECC, but also match user expectations on a per-platform basis
Push design to be a bit more rational instead of emotional (e.g. semantic styles shared across each screen rather than different font sizes everywhere based on “how they look”)
Go screen by screen and file issues to approximate our current screens UI to the designs (texts, paddings, sizes, shades, etc.)

Strings

Google Play translation service
Probably make keys consistent with iOS and use Google Play translation service
We’d write a small script to probably convert the XML to the iOS strings format (it will get us 99% of the way there and we might manually resolve any weird corner cases)

Colors

Already designed by Geffen. We got a file with colors

Paddings

Prepare a separate Dimens class, which will hold needed spacing values, and also enables us to switch between these predefined group of spacing for small/normal/large screens as well as for portrait/landscape, etc.

Additional notes

Check all screens on a very small device to ensure we are all set up everywhere (scrolling, sizing, etc.)
Adaptive layouts: https://developer.android.com/jetpack/compose/layouts/adaptive

Closing as all the subtasks were implemented.


[NT-1854] Remove Braze feature flag

📲 What
Removing the feature flag for Braze and all of its references.
🤔 Why
We are live with our Braze implementation and therefore no longer need to worry about toggling its state.
✅ Acceptance criteria

[ ] Give the app a spin and verify we are building, passing tests and nothing was left behind.

Ran tests locally, ran app, didn't see Braze feature flag under config, I did however see the red banner "We're doing things" on prod, not sure what that refers to.

Ah that is because @paulomcg has a test campaign set on staging!


Fix flaky SSE test

There is technically a bug here, however it requires https://github.com/dotnet/corefxlab/issues/1824 to fix and in practice will never happen because the SSE stream is getting data from the network so it will be async and not hit the issue.

Also, is this meant as a temporary thing? If so, please make sure there's a new bug logged to revert this.

?

Sorry didn't realize this is a month old. But it still wasn't clear to me what was said about "this is technically a bug" and it depends on a CoreFXLab change that hasn't been made.

Since they weren't shipping that code yet, we copied it into our project and modified it, we can file a bug to use them again when they ship


Allow cargo new . to create a cargo package in the current folder

Cargo should support cargo new . to create a cargo package in the current folder, using the existing name of the folder. It should probably abort if any files/folders it wants to create already exists, but otherwise it should just work. It should also default to --vcs none in this case.

dup of https://github.com/rust-lang/cargo/issues/21

@anonymoustafa yes, at the time that this issue was filed, cargo init did not exist.


Topic 282 broader scope for custom rules

This (preliminary) addresses https://github.com/StyraInc/regal/issues/282
I'd recommend reviewing it commit by commit.

First commit: introduced the change in the simplest possible way. Unit and e2e tests still green.
Second change: the added function (collectAggregates) duplicates the file iteration logic happening goroutines in lintWithRegoRules. The common logic is extracted into a new third function, evalAndCollect. This makes the diff a little messy, being the reason why it's in another comment.

Next actions: if this implementation is OK, I'll be happy to add more commits with unit tests and documentation updates (some expectations/guidance welcome)

This (preliminary) addresses https://github.com/StyraInc/regal/issues/282
I'd recommend reviewing it commit by commit.

First commit: introduced the change in the simplest possible way. Unit and e2e tests still green.
Second change: the added function (collectAggregates) duplicates the file iteration logic happening goroutines in lintWithRegoRules. The common logic is extracted into a new third function, evalAndCollect. This makes the diff a little messy, being the reason why it's in another comment.

Next actions: if this implementation is OK, I'll be happy to add more commits with unit tests and documentation updates (some expectations/guidance welcome)

Disregard/delete - superseded by https://github.com/StyraInc/regal/pull/306


Improved error logging in some places

Shows actual request status when request fails and logs error when calling non-implemented ServiceApi function.
I added this, because I was stuck in these places for a while before noticing, that something went wrong.

Thanks


⚠ API - Lens has degraded performance

In 04f9ae0, API - Lens ($LENS_API_URL) experienced degraded performance:

HTTP code: 502
Response time: 346 ms

Resolved: API - Lens performance has improved in 9073cdb after 14 minutes.


Removed FakeRootPathProvider and the single use of it

Removed the FakeRootPathProvider from Nancy.Tests. It was really only used by Nancy.Demo.Authentication.Forms.TestingDemo and even then it wasn't using the actual implementation since it was explicitly setting it's own rootpath.

Added Breaking Change to this since I've removed a public type. Super simple to replace if anyone needs it


Time-picker with min-time and max-time props is not working correctly

Describe the bug
Time-picker with min-time and max-time props together with a default time set. When the time-picker is opened is showing the browser time, not the time that was set by default. This is true also when the time was set pragmatically.
To Reproduce
The min-time / max-time props are set and also a default time.
Now when I click on the time-picker, the value displayed is current time of the browser and not that that was set by default.
Please check here: https://codesandbox.io/s/vue3-date-time-picker-demo-forked-j3qee?file=/src/components/Demo.vue
Expected behavior
I want that the time should start from the time configured not jumping to the browser time.
This is happening in version 2.3.3

Please check this video, I don't see any jumping in time when clicking. It is opening on 10:15

Sorry, it seams ok now.
It was strange because I have set @update:modelValue="setTime" and the event was triggered automatically when the timer was opened with the values browser hour and minutes. Now when I check it seams ok.
Maybe it was something from my cache or something...

Ok, I will leave it for today if something is still wrong, otherwise will close the issue.


Optional support for JPEGmini

Hi!
I really love your tool and it works really well, but if possible, I'd also like optional support for JPEGmini as that's the one feature I feel missing.
Are there any plans on integrating that?

Hi Paleite,
I didn't have any plans to support JPEGmini.  However, since you've brought it up I'll consider it.

Perfect, thanks! :+1:

+1 for JPEG Mini. It's the best for .jpg optimization. Great tool, by the way!

+1 for JPEG Mini. Would be awesome.


Integration via breakpoint

Hi, i just noticed that integration guide doesn't mention anymore the integration via Xcode breakpoint.
Is this method still valid? If yes, why is no more mentioned?
Googling i found this unlinked page https://lookin.work/faq/integration-breakpoint/
Thank you.

"Integration via breakpoint" was only valid with Lookin 1.0.0 and mac with Intel chip, so I removed page.
To enable this feature again, I need to spend time to learn how to make LookinServer.xcframework instead of LookinServer.framework. But unfortunately I don't have such time nowadays.


Local network only IPFS

The data I'm handling is kind of private and should not leave the local network where the IPFS is running. Is there an option to make the IPFS private and never replicating data to the public internet?

I believe you can create a private IPFS network. However, your question might be better directed at the IPFS community as they would be better positioned to help.

Thanks. I have created a question. I will leave the issue open here and if I get an answer I will add also the answer here and close it.

I have not received an answer from the IPFS community so far but I found this very good tutorial in IPFS. Key findings are:

Set LIBP2P_FORCE_PNET=1 to enforce a local only network
Set the CLUSTER_KEY so that no other can join. This seems to be the "cluster secret" in the IPFS implementation.
Remove all bootstrap nodes

Is it possible to pass the CLUSTER_KEY to orbitdb somehow or utilize some already running cluster on the system?

Is it possible to pass the CLUSTER_KEY to orbitdb somehow or utilize some already running cluster on the system?

I'm guessing you would pass it to the IPFS instance that you have used to configure OrbitDB.

I could not find a configuration options for this. I have asked it again in the IPFS forum: https://discuss.ipfs.tech/t/setting-cluster-secret-in-ipfs-js/17459. Let's see if someone is able to give an answer.

We do this by providing a set of preshared trusted peer ids to each node and leveraging the ConnectionGater and manually managing the dialing. Also, if you want a totally private network, just remove the Bootstrap Peer Discovery.

@justin0mcateer if you remove the default bootstrap nodes, it is tillpossible to join the libp2p network by anyone and subscribe and publish to any topic if a public IP of such node is known.  ipfs cids could be gathered like this imho.

@justin0mcateer if you remove the default bootstrap nodes, it is still possible to join the libp2p network by anyone and subscribe and publish to any topic if a public IP of such node is known. ipfs cids could be gathered like this imho.

I would guess the remote peer could dial the other peer manually once it has its address. I believe I've seen discussions around using pubsub as a method of peer discovery.

@haydenyoung Yes, sure that would be possible. Pub-sub-peer-discovery is a nice way to let other nodes know about each other. I am using it myself inside a WebRTC-Rust-Node successfully for the browsers to connect to each other.
However, if we want to prevent other nodes except a certain list, we need to use the connection gater as it seems as @justin0mcateer stated: https://github.com/libp2p/js-libp2p/blob/main/doc/CONFIGURATION.md#configuring-connection-gater.
I'd guess this could be also dynamically configured in open networks, e.g. when certain peers start misbehaving or spamming. But here I am still unclear if that could work without a blockchain.

However, if we want to prevent other nodes except a certain list, we need to use the connection gater as it seems as @justin0mcateer stated: https://github.com/libp2p/js-libp2p/blob/main/doc/CONFIGURATION.md#configuring-connection-gater.

The simplest solution seems to involve a list of deny peers.

I'd guess this could be also dynamically configured in open networks, e.g. when certain peers start misbehaving or spamming. But here I am still unclear if that could work without a blockchain.

What is the definition of a misbehaving peer? is this in the context of OrbitDB? Or IPFS?

@haydenyoung in context of OrbitDB e.g. some peer starts spamming a by all writable db. E.g. a AccessController could find out about such peers and add it to a deny peers list at some point.

@haydenyoung in context of OrbitDB e.g. some peer starts spamming a by all writable db. E.g. a AccessController could find out about such peers and add it to a deny peers list at some point.

Yes I was thinking that care should be taken opening up dbs to too much write access. If it is necessary to, say, have everyone write to a database, a rethink on why the database needs to be so open might be necessary.

So far I have not received any answer from the IPFS forum. Maybe setting the swarm key is not supported in Helia. I have found this issue: https://github.com/ipfs/js-ipfs/issues/4005
As an alternative I was thinking about a way to manually check if the other peer is trusted, Can I check e.g in the join event or any other event maybe lower level in libp2p the other peers key?

You may get better traction asking the libp2p devs about peer verification.


Fixed return outside from function

Coverage remained the same at 88.541% when pulling c136b77d5ada1c597a1c0ed26b0317478a85f529 on nowox:unstable into 8c3327ebbd6d76cd07a48f5ae9c62cee58694090 on Grokzen:unstable.

@nowox Thanks :)


Check static_values from dex_classes

The parsing from static_values of dex_classes.cpp is commented, check and fix.

This problem in the refactoring version of Kunai is not present anymore, static_values are properly parsed as EncodedArray objects: https://github.com/Fare9/KUNAI-static-analyzer/blob/refactoring/kunai-lib/lib/DEX/parser/classes.cpp#L247-L263


Support blake algorithms for file hashing

Fixes issue #: N/A
Description of the changes being introduced by the pull request:

Don't use securesystemslib.settings.HASH_ALGORITHMS for file hashing – doing so is poor cohesion and overloading a setting meant for key hashing
Add a new tuf.settings.FILE_HASHING_ALGORITHM for file hashing
Use tuf.settings.FILE_HASHING_ALGORITHM for hashes in timestamp and targets metadata

Please verify and check that the pull request fulfills the following
requirements:

[ ] The code follows the Code Style Guidelines
[ ] Tests have been added for the bug fix or new feature
[ ] Docs have been added for the bug fix or new feature

(I closed PR #991 because I didn't want that branch name to live forever in the git history, sorry for the noise)
cc @mnm678 who was assigned to review #991 by @JustinCappos
Note: this change has been tested with the simple script in this GitHub gist: test_blake.py which requires the corresponding change in secure-systems-lab/securesystemslib#218
@lukpueh shared a list of places to check for use of hashing algorithms:

targets (for targets metadata) – addressed in this PR with
1f0cb9c
targets (for consistent snapshot prefixes) – uses the already computed hashes in the fileinfo dict
targets (for hashed bins) – assigns the value of tuf.settings.DEFAULT_HASH_ALGORITHM to the module level constant HASH_FUNCTION and uses that for hashing
targets metadata (for snapshot metadata) – I think this uses the already computed hashes in the fileinfo dict
snapshot metadata (for timestamp metadata) – addressed in this PR with 930d832
keys (for keyid_hash_algorithms) – uses securesystemslib.settings.HASH_ALGORITHMS and often includes an awkward dance where that setting is changed before calling securesystemslib.keys.format_metadata_to_key() and then reverted. This is a prime candidate for a refactoring, but doesn't preclude this PR being merged
client updater  – needs work, for example _get_target_hash() hard-codes the use of 'sha256' hashing algorithm

In order to unblock @woodruffw's PEP 458 implementation could we land this and create an issue to address client updater in a follow-on PR?

In order to unblock @woodruffw's PEP 458 implementation could we land this and create an issue to address client updater in a follow-on PR?

@joshuagl: Have you already identified any issues in the client updater resulting from this PR?

In order to unblock @woodruffw's PEP 458 implementation could we land this and create an issue to address client updater in a follow-on PR?

@joshuagl: Have you already identified any issues in the client updater resulting from this PR?

I have not. The only thing I've spotted so far is the related issue that _get_target_hash() hard-codes the hash algorithm to 'sha256', whereas I think it should be using tuf.settings.DEFAULT_HASH_ALGORITHM.
I have been able to make a simple modification to tuf/scripts/repo.py to create a repository which uses blake algorithms for filesystem hashes and successfully use tuf/scripts/client.py to fetch a target file from that repo.

This looks good as a short term fix, but in the long term I would prefer changing the requirements for keyid calculation as discussed here: https://github.com/theupdateframework/tuf/issues/848. As currently implemented, the client has to hard code the same hash algorithm for keyids as the metadata which does not leave much room for flexibility, especially because the keyid does not need to be globally unique.

This looks good as a short term fix

Thanks @mnm678. This is very much intended as a short-term fix to unblock PEP 458 implementation. @lukpueh mentioned #848 and some other issues around cohesion between securesystemslib and tuf when we discussed this quick fix. I'm absolutely interested in contributing to discussions and solutions towards long-term fixes too.

I agree with both of you. I think a good long-term fix might be specifying the targets hashing and keyid calculation (not necessarily hashing) algorithms in the root metadata?

I think an even simpler long term solution would be to keep the keyid calculation independent of the client. The client only needs to know that keyids are unique within a metadata file, not how they are determined. But we can have a meeting/discussion about this elsewhere.

Quick question, @joshuagl, regarding:

targets (for consistent snapshot prefixes) – uses the already computed hashes in the fileinfo dict

Are you referring to the updater ... ?
https://github.com/theupdateframework/tuf/blob/4fe29d138df02035eed9716657cfe0a76e17e178/tuf/client/updater.py#L1375-L1377
(btw. the pop seems hazardous, but that's a different story)
I couldn't find any repo tooling that helps prefixing target files with their hash digests. 🤷♂

I couldn't find any repo tooling that helps prefixing target files with their hash digests. 🤷♂

Never mind, just found it:
https://github.com/theupdateframework/tuf/blob/4fe29d138df02035eed9716657cfe0a76e17e178/tuf/repository_lib.py#L1319-L1324

Regarding

targets metadata (for snapshot metadata) – I think this uses the already computed hashes in the fileinfo dict

Rather looks like python-tuf does not include hashes (only version) in snapshot metadata. See repository_lib.generate_snapshot_metadata.

Regarding

targets metadata (for snapshot metadata) – I think this uses the already computed hashes in the fileinfo dict

Rather looks like python-tuf does not include hashes (only version) in snapshot metadata. See repository_lib.generate_snapshot_metadata.

Seems like this could be worthy of an issue so that we can remember to add to python-tuf?

Seems like this could be worthy of an issue so that we can remember to add to python-tuf?

Good suggestion! Here we go https://github.com/theupdateframework/tuf/issues/996
For the interested reader: The fields were removed in #469 to fix #468 because of the spec changes in #466 motivated by #465. (I just love git and GitHub! :D)


FUSETOOLS2-774 - provide completion for connector.class

which is a specific Camel Kafka Connector property.
This is the first completion relying on the Camel Kafka Connector
Catalog.
Currently using a snapshot version as it is not part of a released
version

--> ~need to wait for Camel kafka Connector artifact to be published on Apache Snapshot repository (nightly build)~ done
--> Are we fine to use a snapshot version? or we wait fo ra release? if using snapshots, it will allow to go further more easily on other tasks related to Camel Kafka Connector. Other possibilities are to have a myriad of other PR or to create a feature branch (but needs to check how to setup the CI  for that). Or we can also wait for an official release for goign further (no date planned as far as I know)

In general I agree that going with a snapshot version will be helpful to drive development.


hubble-relay is CrashLoopBackOff through Hubble: Warning Server not initialized

Is there an existing issue for this?

[x] I have searched the existing issues

Version
equal or higher than v1.16.0 and lower than v1.17.0
What happened?
hubble-relay can't connect, log example
time="2024-11-07T16:41:50Z" level=info msg="Starting gRPC health server..." addr=":4222" subsys=hubble-relay
time="2024-11-07T16:41:50Z" level=info msg="Starting gRPC server..." options="{peerTarget:hubble-peer.kube-system.svc.cluster.local:443 dialTimeout:30000000000 retryTimeout:30000000000 listenAddress::4245 healthListenAddress::4222 metricsListenAddress: log:0xc0005015e0 serverTLSConfig:<nil> insecureServer:true clientTLSConfig:0xc000994dc8 clusterName:default insecureClient:false observerOptions:[0x2218120 0x2218200] grpcMetrics:<nil> grpcUnaryInterceptors:[] grpcStreamInterceptors:[]}" subsys=hubble-relay
time="2024-11-07T16:42:20Z" level=warning msg="Failed to create peer client for peers synchronization; will try again after the timeout has expired" error="context deadline exceeded" subsys=hubble-relay target="hubble-peer.kube-system.svc.cluster.local:443"
time="2024-11-07T16:42:57Z" level=info msg="Stopping server..." subsys=hubble-relay

but main problem that hubbe isn't start
# cilium status
KVStore:                 Ok   Disabled
Kubernetes:              Ok   1.30 (v1.30.3) [linux/amd64]
Kubernetes APIs:         ["EndpointSliceOrEndpoint", "cilium/v2::CiliumClusterwideNetworkPolicy", "cilium/v2::CiliumEndpoint", "cilium/v2::CiliumNetworkPolicy", "cilium/v2::CiliumNode", "cilium/v2alpha1::CiliumCIDRGroup", "core/v1::Namespace", "core/v1::Pods", "core/v1::Service", "networking.k8s.io/v1::NetworkPolicy"]
KubeProxyReplacement:    True      [eth0   <IP_ADDRESS> fe80::4001:aff:fe00:31d (Direct Routing)]
Host firewall:           Enabled   [eth0]
SRv6:                    Disabled
CNI Chaining:            none
CNI Config file:         successfully wrote CNI configuration file to /host/etc/cni/net.d/05-cilium.conflist
Cilium:                  Ok   1.16.3 (v1.16.3-f2217191)
NodeMonitor:             Disabled
Cilium health daemon:    Ok
IPAM:                    IPv4: 2/254 allocated from <IP_ADDRESS>/24,
IPv4 BIG TCP:            Disabled
IPv6 BIG TCP:            Disabled
BandwidthManager:        Disabled
Routing:                 Network: Tunnel [vxlan]   Host: BPF
Attach Mode:             TCX
Device Mode:             veth
Masquerading:            BPF   [eth0]   <IP_ADDRESS>/24 [IPv4: Enabled, IPv6: Disabled]
Controller Status:       20/20 healthy
Proxy Status:            OK, ip <IP_ADDRESS>, 0 redirects active on ports 10000-20000, Envoy: external
Global Identity Range:   min 256, max 65535
Hubble:                  Warning Server not initialized
Encryption:              Disabled
Cluster health:          5/5 reachable   (2024-11-07T16:24:34Z)
Modules Health:          Stopped(0) Degraded(0) OK(42)

through that, exists problem with
How can we reproduce the issue?
yalm configuration
metadata:
  name: bm-rpc-eu-01-cilium
  namespace: argocd
  labels:
    kind: apps
  annotations:
    argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true
spec:
  source:
    repoURL: https://helm.cilium.io/
    targetRevision: 1.16.3
    chart: cilium
    helm:
      releaseName: cilium
      version: v3
      valuesObject:
        debug:
          enabled: true
        ipam:
          mode: kubernetes
        kubeProxyReplacement: true
        securityContext:
          capabilities:
            ciliumAgent:
              - CHOWN
              - KILL
              - NET_ADMIN
              - NET_RAW
              - IPC_LOCK
              - SYS_ADMIN
              - SYS_RESOURCE
              - DAC_OVERRIDE
              - FOWNER
              - SETGID
              - SETUID
            cleanCiliumState:
              - NET_ADMIN
              - SYS_ADMIN
              - SYS_RESOURCE
        cgroup:
          autoMount:
            enabled: false
          hostRoot: /sys/fs/cgroup
        devices:
          - eth0
          - bond0
        k8sServiceHost: bm-rpc-eu-01.eth.p2p.world
        k8sServicePort: 443
        hostFirewall:
          enabled: true
        loadBalancer:
          acceleration: disabled
        prometheus:
          enabled: true
        bpf:
          hostLegacyRouting: false
          masquerade: true
        hubble:
          enabled: true
          debug: true
          ui:
            enabled: true
          relay:
            enabled: true
          metrics:
            enabled:
              - dns
              - drop
              - tcp
              - flow
              - port-distribution
              - icmp
              - httpV2:exemplars=true;labelsContext=source_ip
              - source_namespace
              - source_workload
              - destination_ip
              - destination_namespace
              - destination_workload
              - traffic_direction
              - dns:labelsContext=source_namespace,destination_namespace
              - drop:labelsContext=source_namespace,destination_namespace
        MTU: 1330
        policyEnforcementMode: default
        policyAuditMode: true
  destination:
    name: bm-rpc-eu-01
    namespace: kube-system
  project: bm-rpc-eu-01
  syncPolicy:
    automated: {}
    syncOptions:
      - CreateNamespace=false
      - PruneLast=true
      - ApplyOutOfSyncOnly=true
      - SkipDryRunOnMissingResource=true
      - ServerSideApply=true
kind: Application
apiVersion: argoproj.io/v1alpha1

Cilium Version
1.16.3 (v1.16.3-f2217191)
Kernel Version
Talos (v1.7.6)  6.6.43-talos
Kubernetes Version
Server Version: v1.30.3
Regression
No response
Sysdump
No response
Relevant log output
No response
Anything else?
No response
Cilium Users Document

[ ] Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

[x] I agree to follow this project's Code of Conduct

hubble-peer.kube-system.svc.cluster.local:443 is a service IP with internalTrafficPolicy: Local. It redirects to port 4244 on the same node, which is opened by the agent.
Can you verify that the agents are listening on that port, and that it is not blocked by NetworkPolicy, iptables, or anything else?

cilium policy
    "ingress": [
      {
        "fromEndpoints": [
          {
            "matchLabels": {
              "any:app.kubernetes.io/name": "hubble-relay",
              "any:app.kubernetes.io/part-of": "cilium",
              "any:k8s-app": "hubble-relay"
            },
            "matchExpressions": [
              {
                "key": "k8s:io.kubernetes.pod.namespace",
                "operator": "Exists"
              }
            ]
          }
        ],
        "toPorts": [
          {
            "ports": [
              {
                "port": "4244",
                "protocol": "TCP"
              }
            ]
          }
        ]
      }
    ],

cluster NetworkPolicy off

I have seen that hubble status in cilium is ok when I install cilium without hubble-relay, unix:///var/run/cilium/hubble.sock exists and runs, but when I enable hubble-relay then the hubble status is failed, because /var/run/cilium/hubble.sock is not found. So when run the command cilium-dbg status with hubble-relay enabled response on Hubble: "Warning: The hubble server is not initialized". So hubble-relay cannot reach the hubble-server.

It is likely that the traffic is being blocked; the Cilium pods are host-network and thus the usual NetworkPolicy rules do not apply. Can you check in Hubble to see if there are any drops.
You will probably have to write a policy that allows the remote-node and host entities.

It is likely that the traffic is being blocked; the Cilium pods are host-network and thus the usual NetworkPolicy rules do not apply. Can you check in Hubble to see if there are any drops.
You will probably have to write a policy that allows the remote-node and host entities.

Can you check in Hubble to see if there are any drops.
this is not possible, because the hubble server is not initialized, so hubble status and all other hubble commands are not running.
I have the same problem, after upgrading the host system from Ubuntu 22.04 to 24.04. But I am not sure. I know, that I was able to run hubble-relay and hubble-ui once before some weeks. But I don't know all the environment changes.
I use Kubernetes 1.31.x,
these are the values for installing Cilium (I actually disabled hubble-relay and hubble-ui because of the disfunctional, but this are the only changes):
enableIPv4Masquerade: true
enableHostReachableServices: true
enableNodePort: true
nodePort:
mode: snat
debug:
enabled: true
verbose: "datapath"
Prometheus monitoring settings for Cilium and Hubble
monitoring:
enabled: true
prometheus:
enabled: true
# Use Prometheus integration with Cilium
scrapeInterval: 15s  # Scrape metrics every 15 seconds
port: 9090          # Default Prometheus port
Add Prometheus support and configuration for monitoring Cilium and Hubble
prometheus:
enabled: true
serviceMonitor:
trustCRDsExist: true  # Enables Prometheus Operator's ServiceMonitor resource to scrape Cilium metrics
Optional settings for the Prometheus service if you're exposing it externally
service:
type: NodePort  # Expose Prometheus via NodePort (adjust if you need another type)
nodePort:
port: 30900    # Set a specific NodePort for Prometheus metrics
Enable eBPF metrics in Prometheus
ciliumMetrics:
enabled: true  # Enable Cilium-specific metrics for Prometheus
Enable OpenTelemetry integration (optional)
openTelemetry:
enabled: false # Disable OpenTelemetry if not required
Enable Cilium's built-in network policy enforcement
enablePolicy: true
Add specific Cilium configuration for network observability
enableFlowLogs: true  # Enable flow logs for more detailed observability
Optional: Enable more verbose debugging if needed
enableDebugLogging: true
kubeProxyReplacement: true
k8sServiceHost: my host ip
k8sServicePort: 6443
operator:
replicas: 1
bpf:
masquerade: true
policyAuditMode: true
hubble:
enabled: true
metrics:
enableOpenMetrics: true
enabled:
- dns:query;ignoreAAAA
- drop
- tcp
- flow
- port-distribution
- icmp
- http
- httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction
relay:
enabled: false
dialTimeout: 20s
retryTimeout: 10s
tls:
enabled: true
ui:
enabled: false
service:
type: NodePort
frontend:
server:
ipv6:
enabled: true
tls:
enabled: true

this is not possible, because the hubble server is not initialized

You can execute hubble in the Cilium container. kubectl -n kube-system exec -ti <<CILIUM POD>> -- bash will get you an interactive terminal. There you can execute hubble directly, which will show all flows on that node.

Thanks to all of you for your help :) Main problem was in
        hubble:
          metrics:
            enabled:
              - dns
              - drop
              - tcp
              - flow
              - port-distribution
              - icmp
              - httpV2:exemplars=true;labelsContext=source_ip
              - source_namespace
              - source_workload
              - destination_ip
              - destination_namespace
              - destination_workload
              - traffic_direction
              - dns:labelsContext=source_namespace,destination_namespace
              - drop:labelsContext=source_namespace,destination_namespace

I changed to
        hubble:
          metrics:
            enabled:
              - dns
              - drop
              - tcp
              - flow
              - port-distribution
              - icmp
              - dns:labelsContext=source_namespace,destination_namespace
              - drop:labelsContext=source_namespace,destination_namespace
              - httpV2:sourceContext=workload-name|pod-name|reserved-identity;destinationContext=workload-name|pod-name|reserved-identity;labelsContext=source_namespace,destination_namespace,traffic_direction

First of all it was my mistake with list of metrics and it's similar with issue https://github.com/cilium/cilium/issues/27506.
But anywhere the hubble wasn't started by that and there was a problem with the hubble-peers.
Issue resolved :)

Thanks for the resolution info, @herbic1d3!


[BUG]

Execute the command and paste the result below.
Command: uname -a && php -v && composer info | grep hyperf && php --ri swoole
Darwin lizuoqiangdeMacBook-Pro.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64
PHP 7.4.10 (cli) (built: Sep  3 2020 18:21:42) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.10, Copyright (c), by Zend Technologies
Composer could not find a composer.json file in /Users/lly
To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section
[lly@lizuoqiangdeMacBook-Pro:~]$ path
[lly@lizuoqiangdeMacBook-Pro:/Users/work-new]$ cd micro_advertise/
[lly@lizuoqiangdeMacBook-Pro:/Users/work-new/micro_advertise → develop-debug]$ uname -a && php -v && composer info | grep hyperf && php --ri swoole
Darwin lizuoqiangdeMacBook-Pro.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64
PHP 7.4.10 (cli) (built: Sep  3 2020 18:21:42) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.10, Copyright (c), by Zend Technologies
fangx/resource                       v2.1               A api resource component for hyperf.
hyperf/async-queue                   v2.0.11            A async queue component for hyperf.
hyperf/cache                         v2.0.9             A cache component for hyperf.
hyperf/command                       v2.0.10            Command for hyperf
hyperf/config                        v2.0.9             An independent component that provides configuration container.
hyperf/config-apollo                 v2.0.10            An apollo adapter for Hyperf config component.
hyperf/constants                     v2.0.9             A constants component for hyperf.
hyperf/consul                        v2.0.9             A Consul Client for Hyperf.
hyperf/contract                      v2.0.13            The contracts of Hyperf.
hyperf/crontab                       v2.0.14            A crontab component for Hyperf.
hyperf/database                      v2.0.16            A flexible database library.
hyperf/db-connection                 v2.0.12            A hyperf db connection handler for hyperf/database.
hyperf/devtool                       v2.0.14            A Devtool for Hyperf.
hyperf/di                            v2.0.16            A DI for Hyperf.
hyperf/dispatcher                    v2.0.10            A HTTP Server for Hyperf.
hyperf/event                         v2.0.10            an event manager that implements PSR-14.
hyperf/exception-handler             v2.0.13            Exception handler for hyperf
hyperf/filesystem                    v2.0.11            flysystem integration for hyperf
hyperf/framework                     v2.0.11            A coroutine framework that focuses on hyperspeed and flexible, specifically use for build microservices and middlewares.
hyperf/guzzle                        v2.0.11            Swoole coroutine handler for guzzle
hyperf/http-message                  v2.0.14            microservice framework base on swoole
hyperf/http-server                   v2.0.13            A HTTP Server for Hyperf.
hyperf/json-rpc                      v2.0.15            A JSON RPC component for Hyperf RPC Server or Client.
hyperf/load-balancer                 v2.0.11            A load balancer library for Hyperf.
hyperf/logger                        v2.0.11            A logger component for hyperf.
hyperf/memory                        v2.0.12            An independent component that use to operate and manage memory.
hyperf/metric                        v2.0.12            hyperf metric component
hyperf/model-cache                   v2.0.16            A model cache component for hyperf.
hyperf/model-listener                v2.0.12            A model listener for Hyperf.
hyperf/paginator                     v2.0.12            A paginator component for hyperf.
hyperf/pool                          v2.0.12            An independent universal connection pool component.
hyperf/process                       v2.0.13            A process component for hyperf.
hyperf/redis                         v2.0.14            A redis component for hyperf.
hyperf/rpc                           v2.0.12            A rpc basic library for Hyperf.
hyperf/rpc-client                    v2.0.12            An abstract rpc server component for Hyperf.
hyperf/rpc-server                    v2.0.12            An abstract rpc server component for Hyperf.
hyperf/server                        v2.0.13            A base server library for Hyperf.
hyperf/service-governance            v2.0.13            A service governance component for Hyperf.
hyperf/task                          v2.0.13            A task library for Hyperf.
hyperf/testing                       v2.0.14            Testing for hyperf
hyperf/tracer                        v2.0.20            A open tracing system implemented for Hyperf or other coroutine framework
hyperf/translation                   v2.0.13            An independent translation component, forked by illuminate/translation.
hyperf/utils                         v2.0.0             A tools package that could help developer solved the problem quickly.
hyperf/validation                    v2.0.13            hyperf validation
hyperf/watcher                       v2.0.16

swoole

Swoole => enabled
Author => Swoole Team<EMAIL_ADDRESS>Version => 4.5.4
Built => Sep 26 2020 14:10:41
coroutine => enabled
kqueue => enabled
rwlock => enabled
pcre => enabled
zlib => 1.2.11
brotli => E16777225/D16777225
async_redis => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => Off => Off
swoole.unixsock_buffer_size => 262144 => 262144

Description:
config/autoload/dependencies.php
return [
    Hyperf\DbConnection\Frequency::class => Hyperf\Pool\ConstantFrequency::class,
];

Steps To Reproduce:
app/Command/DemoCommand.php
    protected $name = 'demo';
    public function configure()
    {
        parent::configure();
        $this->setDescription('demo');
    }
    public function handle(): void
    {
        $a = ProjectModel::query()->find(6)->toArray();
        $this->info(json_encode($a));
        $this->info('this is demo');
    }

php bin/hyperf.php demo
脚本都输出了  this is demo，脚本还一直挂起不退出
把Hyperf\DbConnection\Frequency::class => Hyperf\Pool\ConstantFrequency::class, 注释掉再次运行脚本就可以正常退出
在不正常退出的时候我用 strace 看了下该进程 一直有东西在输出

左边是通过rpc调用另一个服务，右边是：strace -p 左侧脚本的pid

左边是通过rpc调用另一个服务，右边是：strace -p 左侧脚本的pid

都执行完了 为什么还一直在请求consul

都执行完了 为什么还一直在请求consul

\Swoole\Timer::clearAll();

\Swoole\Timer::clearAll();


docs: Add doc for disks and volumes

Codecov Report

Merging #24 (5557749) into main (d70a968) will increase coverage by 0.21%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   31.66%   31.87%   +0.21%
==========================================
  Files           3        3
  Lines         938      938
==========================================
+ Hits          297      299       +2
+ Misses        594      593       -1
+ Partials       47       46       -1

Impacted Files
Coverage Δ

pkg/controller/vm_controller.go
22.78% <0.00%> (+0.47%)
:arrow_up:

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