Flash API: support for no_explicit_erase flag (stage 0)

This is Stage 0 for https://github.com/zephyrproject-rtos/zephyr/issues/71270
The PR itself adds:

no_explicit_erase flag, to flash_parameters, to add by drivers that do not require erase by device type (MRAM,FRAM,RRAM, etc)
Kconfigs: FLASH_HAS_EXPLICIT_ERASE and FLASH_HAS_NO_EXPLICIT_ERASE to mark drivers that offer support for device with specific capability; these Kconfig options should allow to identify combination of devices within system and allow subsystems to adapt; drivers are marked with one of these to indicate what they offer;
flash_flatten - substitute for flash_erase for code that has been "cleaning" devices with erase and still wants to do that; this is common syscall that will either fill device with pre-defined value or user erase if available from device;
Adds two macros: FLASH_CAPS_EXPLICIT_ERASE and FLASH_CAPS_NO_EXPLICIT_ERASE that should be used on Flash Parameters to obtain capability of device (this is attempt to slowly black boxing the Flash Parameters)
adds new mode to Flash Simulator that allows to simulate device that do not support erase
modifies common subsystems to support devices that do not require erase
modifies tests and samples to work for new devices, for example nrf54l15, and Flash Simulator with the new feature.

@Laczen I have given answers to all your concerns in the https://github.com/zephyrproject-rtos/zephyr/issues/71270 and through the discussion (in #67687 and on discord), and explained the caveats of using DTS property, and why I follow with the two Kconfig option.
If you still stand in opposition to approach taken by RFC https://github.com/zephyrproject-rtos/zephyr/issues/71270 and this PR  NACK it and/or escalate (https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-technical-escalation).
The PR has been marked DNM to give you time for response.

@aaronyegx @RichardSWheatley Review the PRs that mark your devices as FLASH_HAS_NO_EXPLICIT_ERASE and state whether you want to have them marked as such or the opposite, i.e. FLASH_HAS_EXPLICIT_ERASE.

@aaronyegx @RichardSWheatley Review the PRs that mark your devices as FLASH_HAS_NO_EXPLICIT_ERASE and state whether you want to have them marked as such or the opposite, i.e. FLASH_HAS_EXPLICIT_ERASE.

The code is Aaron's so I will let him comment.

@Laczen I have given answers to all your concerns in the #71270 and through the discussion (in #67687 and on discord), and explained the caveats of using DTS property, and why I follow with the two Kconfig option. If you still stand in opposition to approach taken by RFC #71270 and this PR NACK it and/or escalate (https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-technical-escalation). The PR has been marked DNM to give you time for response.

Thank you for adding the DNM to allow me to response.
All answers that were supplied have not convinced me that the proposed PR is the best way to solve the problem. It does not utilize any devicetree properties that would allow solving the present problem in a simpler and easier to maintain method that is extendable to other "capabilities".
I will not NACK or escalate, but I'm not supporting this proposal. You can always contact me if you would like to collaborate on a different solution.

@aaronyegx @RichardSWheatley Review the PRs that mark your devices as FLASH_HAS_NO_EXPLICIT_ERASE and state whether you want to have them marked as such or the opposite, i.e. FLASH_HAS_EXPLICIT_ERASE.

Let's keep your implementation at this moment. It is likely that we need to change something in the Ambiq flash driver when we add more device supporting further. Thank you.

@aaronyegx @RichardSWheatley Review the PRs that mark your devices as FLASH_HAS_NO_EXPLICIT_ERASE and state whether you want to have them marked as such or the opposite, i.e. FLASH_HAS_EXPLICIT_ERASE.

Let's keep your implementation at this moment. It is likely that we need to change something in the Ambiq flash driver when we add more device supporting further. Thank you.

Thank you.

All answers that were supplied have not convinced me that the proposed PR is the best way to solve the problem. It does not utilize any devicetree properties that would allow solving the present problem in a simpler and easier to maintain method that is extendable to other "capabilities".
I will not NACK or escalate, but I'm not supporting this proposal. You can always contact me if you would like to collaborate on a different solution.

Thank you, but I will follow with this approach.

Good work!

@RichardSWheatley @aaronyegx @henrikbrixandersen @erwango @nvlsianpu @danieldegrasse would appreciate reviews on this PR

@RichardSWheatley @aaronyegx @henrikbrixandersen @erwango @nvlsianpu @danieldegrasse would appreciate reviews on this PR

We are good with this PR. We do not need to explicitly erase before programming MRAM.
I remember @aaronyegx commented previously that we are good with this implementation and the changes to Ambiq code.

@RichardSWheatley @aaronyegx @henrikbrixandersen @erwango @nvlsianpu @danieldegrasse would appreciate reviews on this PR

@de-nordic We are good with this PR. We do however have an update to flash_ambiq.c file for another Ambiq variant and we are updating the flash_ambiq.c here: https://github.com/zephyrproject-rtos/zephyr/pull/72456/files#diff-e74a7a48d74bbf7555a5064e1aec21b6c8128161439b7c8d152bb5fc73a6742e
So for Apollo4, MRAM does not need explicit erase but the Apollo3 has flash so it does. I am not sure if you need to do this here or we can do it after in an update.
 .caps = { #if (CONFIG_SOC_SERIES_APOLLO4X)  .no_explicit_erase = true, #elif (CONFIG_SOC_SERIES_APOLLO3X)  .no_explicit_erase = false, #endif /* CONFIG_SOC_SERIES_APOLLO4X */  },
There will need to be a similar change to the Kconfig.ambiq file. Something similar to: select FLASH_HAS_NO_EXPLICIT_ERASE if SOC_SERIES_APOLLO4X  select FLASH_HAS_EXPLICIT_ERASE if SOC_SERIES_APOLLO3X

Yes. But your PR is still not there. That is why I am not providing the change, because I can only address what is already in the tree.
If your PR gets in before my PR then I will adapt, otherwise you will adapt.
Also, it is good that you mention your PR, because this is perspective of something that is not yet in a tree, even though we agree on execution. Thanks for paying attention.

In response to @jfischer-no proposal regarding introduction of flash_erase_if_required (mentioned in previous PR and dev review https://zoom.us/rec/share/LOIUjQCnYpzXh3DGXBcDD0CPpBlqBy_gfS0dyuQesZA_ZbEKIeyy61M-vbJ0d5l1.EzEeo8VSeWiWlRAc ~ 28:20, if you have not been present).
I do not think this is proper approach. I think that user should be exposed with device properties and simplest possible way to address them, yes I know that flash_flatten breaks that but I will explain why below.
The flash_erase_if_needed (required) if I understand it correctly, unless it is local function for Disk Access, for me has a notion of:
Erase if such requirement is imposed by a device prior to write, otherwise do nothing
which I do not think is correct and decision whether to erase or not should be given to subsystem/user code, basing on properties of device as taken from the device itself.
Note also that there are three uses of erase in our code:

Mandated by device type: for example any write of random value requires erase in location written prior.
Mandated by software design around devices that require erase: for example NVS, FCB,
Usage of erase as a way to remove something from memory.

The 1) can be considered direct impact on 2), but is separate issue, for example stream flash does not care about what was on device prior to write, but will not be able to write it if it is not erase (in case of flash).
The 2) are case where logic expects device to have certain values where it is not written (erase-value) and if area has different then expected value consider it being used.
The 3) is where software wants to remove information, for example MCUmgr removes image from slot, but it can not just write data on flash devices, it has to erase it first, so on these device it will only do erase and that is enough to already remove information. On device that do not require erase (or not provide it) you have to write something to scramble data.
And here comes the flash_flatten function. It has been provided because one of comments in previous PR has basically stated that it is "ugly" that subsystems have to check whether erase is required and do erase or fill area with some value, and that repeats across different subsystems. The flash_flatten funciton has been provided to basically void the comment and make it easier for users to deal with 3) without adding additional logic to check for devices. The semantic of the flash_flatten is basically:
If device is erase type device, then erase, otherwise fill the range with erase-value
This is also visible in usage in this PR, where case 1) will directly call flash_erase, case 2) and 3) will invoke flash_flatten.
The name is kind bad, but I have selected "flatten" due to the fact that it is verb and indicates action, I did not use "clear" because the function actually does not clear anything, it just makes every byte of region look the same.
I could use "flash_erase_or_fill", maybe less bad.
But if I misunderstood the semantic of flash_erase_if_needed and it is the same as flash_flatten or flash_erase_or_fill I still prefer either of the two later names.

@aaronyegx @RichardSWheatley and others from Ambiq, could you please review?

The Ambiq driver changes look good to me. @de-nordic may need your help to adapt Apollo3 flash then the PR will provide a demo how the same driver supports both FLASH_HAS_EXPLICIT_ERASE and FLASH_HAS_NO_EXPLICIT_ERASE. Thank you.

I have corrected the commit that has been altering your driver to support both SoC variants.

LittleFS CI fix here: https://github.com/zephyrproject-rtos/zephyr/pull/72594

Please remove any changes to the nvs system. This was designed to work on flash with erase and should not need to question any possibilities to give a warning. Nvs will work on devices that support erase, on others it should not work.

But there is already an effort in progress to enhance NVS to support non-eraseable devices:
https://github.com/zephyrproject-rtos/zephyr/pull/69384
Why would we not want NVS to run on these type of devices?

Please remove any changes to the nvs system. This was designed to work on flash with erase and should not need to question any possibilities to give a warning. Nvs will work on devices that support erase, on others it should not work.

But there is already an effort in progress to enhance NVS to support non-eraseable devices: #69384
Why would we not want NVS to run on these type of devices?

NVS is already supported on these devices (this was the reason to add a flash interface for the ambiq processors). When these devices would be defined with a erase == NULL or a disappearing erase the support would not be there.
The effort to enhance NVS to support non-eraseable devices should not discriminate between the two "types" but instead try to eliminate the need to erase and accept that when the erase is not implemented (returning -ENOSYS) it can continue writing to the next sector.

But IIUC, https://github.com/zephyrproject-rtos/zephyr/pull/69384 is actually trying to do that. It checks if the erase operation is available or not and then acts accordingly.

But IIUC, #69384 is actually trying to do that. It checks if the erase operation is available or not and then acts accordingly.

No, it doesn't do that. It finds out that the erase is not available and doesn't call erase. The enhancement to NVS should just call erase and don't mind the -ENOSYS. But this is for #69384.

But IIUC, #69384 is actually trying to do that. It checks if the erase operation is available or not and then acts accordingly.

No, it doesn't do that. It finds out that the erase is not available and doesn't call erase. The enhancement to NVS should just call erase and don't mind the -ENOSYS. But this is for #69384.

I don't get it I think. Could you please explain which changes would you make both in this PR and also in #69384? I think you mean:

In this PR, no changes to NVS?
In #69384, can you please describe there the changes you would like to see?

Nevertheless, @Laczen, I find your request baffling, because you perfectly know that NVS will work on any device as long as there is a way to level the device before usage, and it does not have to happen by erase; it may be less efficient and hit endurance harder on devices that do not require it, but it will work; this is proven by Flash Simulator. Ambiq Apollo 4 implements erase as write.
Does not matter how the function is named, it matters what it does in the end and whether it works for the subsystem that calls it.

Please remove any changes to the nvs system. This was designed to work on flash with erase and should not need to question any possibilities to give a warning. NVS will work on devices that support erase, on others it should not work.

You perfectly know that any subsystem instance has to gather some basic information on subsystems it will work with, into own context (yes NVS does that), before it starts to work on that other subsystem; so they can decide to later choose path of execution basic on the pre-gathered information (e.g need to erase for specific device). The warning is because the #69384 should be the alternative chosen I may move it to Kconfig option description for NVS, if that fixes anything.
You also perfectly know what CONFIG_USERSPACE=y does and how it impacts CPU cycles and what the cost of z_impl_flash_erase will be when the Kconfig is set (https://docs.zephyrproject.org/latest/samples/userspace/syscall_perf/README.html), yet:

The effort to enhance NVS to support non-eraseable devices should not discriminate between the two "types" but instead try to eliminate the need to erase and accept that when the erase is not implemented (returning -ENOSYS) it can continue writing to the next sector.

your opinion is that every time, whether it is needed or not, the flash_erase should be called, a lot of CPU cycles will get wasted, so that next code could check if the flash_erase returns -ENOSYS and then code in response to -ENOSYS should be executed, same code that could be executed instead of flash_erase? Every time when CPU passes that code? on embedded device where the device underneath the subsystem will never change?
You also know that it is not possible just to "not-erase" and write: NVS will fail to init if it find all of its sectors written with non-"erase-value" https://github.com/zephyrproject-rtos/zephyr/blob/71b71015a9a4860f4a8d8d9f9fcb985d443cdfc0/subsys/fs/nvs/nvs.c#L746.
The #69384 makes NVS variant that works on devices that do not have erase without needless overwrites.

Nevertheless, @Laczen, I find your request baffling, because you perfectly know that NVS will work on any device as long as there is a way to level the device before usage, and it does not have to happen by erase; it may be less efficient and hit endurance harder on devices that do not require it, but it will work; this is proven by Flash Simulator. Ambiq Apollo 4 implements erase as write.
Does not matter how the function is named, it matters what it does in the end and whether it works for the subsystem that calls it.

Please remove any changes to the nvs system. This was designed to work on flash with erase and should not need to question any possibilities to give a warning. NVS will work on devices that support erase, on others it should not work.

You perfectly know that any subsystem instance has to gather some basic information on subsystems it will work with, into own context (yes NVS does that), before it starts to work on that other subsystem; so they can decide to later choose path of execution basic on the pre-gathered information (e.g need to erase for specific device). The warning is because the #69384 should be the alternative chosen I may move it to Kconfig option description for NVS, if that fixes anything.
You also perfectly know what CONFIG_USERSPACE=y does and how it impacts CPU cycles and what the cost of z_impl_flash_erase will be when the Kconfig is set (https://docs.zephyrproject.org/latest/samples/userspace/syscall_perf/README.html), yet:

The effort to enhance NVS to support non-eraseable devices should not discriminate between the two "types" but instead try to eliminate the need to erase and accept that when the erase is not implemented (returning -ENOSYS) it can continue writing to the next sector.

your opinion is that every time, whether it is needed or not, the flash_erase should be called, a lot of CPU cycles will get wasted, so that next code could check if the flash_erase returns -ENOSYS and then code in response to -ENOSYS should be executed, same code that could be executed instead of flash_erase? Every time when CPU passes that code? on embedded device where the device underneath the subsystem will never change?
You also know that it is not possible just to "not-erase" and write: NVS will fail to init if it find all of its sectors written with non-"erase-value" https://github.com/zephyrproject-rtos/zephyr/blob/71b71015a9a4860f4a8d8d9f9fcb985d443cdfc0/subsys/fs/nvs/nvs.c#L746.
The #69384 makes NVS variant that works on devices that do not have erase without needless overwrites.

"Ambiq Apollo 4 implements erase as write."
We implemented the erase as a fill, which is silly IMO.
If a user wishes to fill, that should not be used by erase when an erase is not needed.
I would rather have the user/test/sample check for no-explicit-erase required prior to sending a needless command and writing something needlessly.
There could be an addition to the driver to implement a specific fill function or add a parameter to FORCE a fill even though erase isn't needed.

Please remove any changes to the nvs system. This was designed to work on flash with erase and should not need to question any possibilities to give a warning. NVS will work on devices that support erase, on others it should not work.

You perfectly know that any subsystem instance has to gather some basic information on subsystems it will work with, into own context (yes NVS does that), before it starts to work on that other subsystem; so they can decide to later choose path of execution basic on the pre-gathered information (e.g need to erase for specific device). The warning is because the #69384 should be the alternative chosen I may move it to Kconfig option description for NVS, if that fixes anything.

NVS does not need any basic information from a subsystem. There are 3 things that it needs:

the erase-value, that could be retrieved from DTS,
the write-block-size, that could be retrieved from DTS,
the validation of the block size, that should only be done when a "run-time" evaluation is requested (similar to the flash_disk solution).

This would remove the need for flash_get_parameters(), flash_get_write_block_size() and flash_get_page_info_by_offs() at least for NVS.

You also perfectly know what CONFIG_USERSPACE=y does and how it impacts CPU cycles and what the cost of z_impl_flash_erase will be when the Kconfig is set (https://docs.zephyrproject.org/latest/samples/userspace/syscall_perf/README.html), yet:

The effort to enhance NVS to support non-eraseable devices should not discriminate between the two "types" but instead try to eliminate the need to erase and accept that when the erase is not implemented (returning -ENOSYS) it can continue writing to the next sector.

your opinion is that every time, whether it is needed or not, the flash_erase should be called, a lot of CPU cycles will get wasted, so that next code could check if the flash_erase returns -ENOSYS and then code in response to -ENOSYS should be executed, same code that could be executed instead of flash_erase? Every time when CPU passes that code? on embedded device where the device underneath the subsystem will never change?

One call to flash_erase() should be sufficient for nvs (and other systems like flash_disk and littlefs) to find out that it does not need any future calls to flash_erase(). There is no need to do call it every time.

You also know that it is not possible just to "not-erase" and write: NVS will fail to init if it find all of its sectors written with non-"erase-value"
https://github.com/zephyrproject-rtos/zephyr/blob/71b71015a9a4860f4a8d8d9f9fcb985d443cdfc0/subsys/fs/nvs/nvs.c#L746
.
The #69384 makes NVS variant that works on devices that do not have erase without needless overwrites.

When finding out the end of nvs the "cycle counter" should be used and this would even allow the erase to be postponed until a write to a new sector is needed (also for devices with erase).

NVS does not need any basic information from a subsystem. There are 3 things that it needs:
1. the erase-value, that could be retrieved from DTS,

2. the write-block-size, that could be retrieved from DTS,

3. the validation of the block size, that should only be done when a "run-time" evaluation is requested (similar to the flash_disk solution).

The entire response is contradicting itself: does it need info or not?
I have already explained how write-block-size is not device parameter, because it does not change how device behaves - it changes how subsystems behaves.
This drops need for passing these parameters to NVS instance by user that invokes it, while now nvs_mout does the job for the user https://github.com/zephyrproject-rtos/zephyr/blob/f2e3d3f951112ffec7f3a1a40bcf0c187dcae40e/subsys/fs/nvs/nvs.c#L963).
to fill in, for each instance, instead user would have to do that for each parameter.

One call to flash_erase() should be sufficient for nvs (and other systems like flash_disk and littlefs) to find out that it does not need any future calls to flash_erase(). There is no need to do call it every time.

So basically cache output of call. You can do the same on init gathering needed information from flash_parameters. I guess that figuring what you work with prior to calling functions is more reasonable.

When finding out the end of nvs the "cycle counter" should be used and this would even allow the erase to be postponed until a write to a new sector is needed (also for devices with erase).

I guess then you can help with the https://github.com/zephyrproject-rtos/zephyr/pull/69384, since you have ideas.

The PR here contains reduced changes from the PR https://github.com/zephyrproject-rtos/zephyr/pull/67687 originally implementing issue https://github.com/zephyrproject-rtos/zephyr/issues/62228.
After lengthy discussion spawned after request for help from community, https://github.com/zephyrproject-rtos/zephyr/issues/62228#issuecomment-1906860972, the issue describing Flash roadmap has been added here https://github.com/zephyrproject-rtos/zephyr/issues/71270, and this PR has been spawned as reduced original PR with reduced set of changes, following comments from community, representing the stage 0.
It was agreed (and disagreed) several times that we should follow with using the flag representing device capabilities. The approach with capability flag, at this point, has gathered interest and acceptance from at least one another vendor.
Because there was strong opposition regarding the implementation, the party not agreeing on implementation has been given a chance to escalate (https://github.com/zephyrproject-rtos/zephyr/pull/71271#issuecomment-2061894208), which has not been taken, and it has been stated that the PR will not be further blocked.
Unfortunately it has been blocked now https://github.com/zephyrproject-rtos/zephyr/pull/71271#pullrequestreview-2050589726, with, what I consider unreasonable request.
The original approach has been brought to AWG on Jan 23th (https://zoom.us/rec/share/_QMupOvBdZGiRQe8pohG_o2I65Lpi9SoEd7mZ7I3z75QGLfiEXM9T6QkMY57uDr4.utcL0UR1eDTacPxK, ~54 minutes in)
on Feb 6 (https://zoom.us/rec/share/juvddRuEve1gy-g-RI9x9GOKR0oFxiEsUstKRb1gF8oc5k4adlo6cna95O1ihPdk.Kff43miyafPcuoHS , around 10 minutes in)
The issue has spawned lengthy discussion https://discord.com/channels/720317445772017664/883445484923011172/threads/1220424912829681846 and at least two alternative PRs.
The PR here has also been mentioned in PR Help channel https://discord.com/channels/720317445772017664/997527108844798012/1233072235120562206
and set for dev-review on May 2nd.
At this point I think I have addressed every possible question or doubt and I am in a loop explaining things again.
The issue that is now blocking the PR (https://github.com/zephyrproject-rtos/zephyr/pull/71271#pullrequestreview-2050589726) is basically citing unwanted changes to other subsystem, rather than the approach taken, which I do not find reasonable.
The changes to the NVS, under dispute, have been present during previous proposal of escalation (https://github.com/zephyrproject-rtos/zephyr/pull/71271#issuecomment-2061894208),  but where not pointed out as a problem, and escalation has not been triggered.
I have already stated that I will stick to my approach to the issue (https://github.com/zephyrproject-rtos/zephyr/pull/71271#issuecomment-2066996531) and I find the blocking comment, and following it comments, by opposing party, as an attempt to reset the discussion.
I find no option at this point rather then escalate the issue to TSC.

I have removed my request for changes because it would cause an unneeded escalation. As the author of nvs I disagree with the addition of changes to nvs.

please follow the process here: https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-technical-escalation and describe what has been done before reaching out to the TSC.

I have removed my request for changes because it would cause an unneeded escalation. As the author of nvs I disagree with the addition flash_flatten() to nvs.

Replacement of flash_erase with flash_flatten, replacement:

and both functions work exactly the same, even for Apollo4, except that the later one removes need for implementation of erase callback by devices, that do not have it, and moves the action into common, single function.
Therefore, there is no logical explanation for denying the change, the whole denial is semantically "I refuse to call function with different name".

The issues with code in flash_ifx_cat1.c are not caused by this PR and also exist on main. This PR only has bought the cyw920829m2evk_02 into attention causing the failures.
Issue reported here: https://github.com/zephyrproject-rtos/zephyr/issues/73525

The mbedTLS failures are not related to this PR and are covered by issue https://github.com/zephyrproject-rtos/zephyr/issues/73603

The mimxrt1060_evk Littlefs errors are not related to changes in this PR and are caused by commit 03d1eabc32c7; fix provided here: https://github.com/zephyrproject-rtos/zephyr/pull/73630

@carlescufi sure, feel free to resolve the comments after merge.

@carlescufi the need to rebase this PR so frequently might also be an indication that the PR touches to much at the same time.

While this may be true in some cases, sometimes it is necessary to change a high number files to move forward.

While looking at other OS's I have seen that all take the approach proposed in #72924. Provide an erase by filling with the erase value for devices that do not have erase (e.g. eeprom as mtd in RIOT-OS, eeprom as mtd in nuttx, mtdram and block2mtd in linux, ...).

That is interesting, but when looking at the actual changes in the flash API in this PR and #72924 they are very similar:

Both introduce a flag that signifies "this device does not require an erase operation before writing new data". Both introduce it in the same struct
Both modify pretty much the same drivers (nRF, numaker, Ambiq)
Both provide similar ways for the flash API user to retrieve the flag (convenience functions)

The rest, in my personal opinion, are implementation details of the same basic concept.

The solution proposed in #72924 is cleaner as it only requires touching the drivers that can write without prior erase.

This is true in this PR too. I only see changes in the .c files of flash drivers that can write without prior erase.
All in all, I do not see actual significant differences in conceptual architectural design in this PR and #72924.

@carlescufi the need to rebase this PR so frequently might also be an indication that the PR touches to much at the same time.

While this may be true in some cases, sometimes it is necessary to change a high number files to move forward. 90+ files in a PR is not uncommon in Zephyr.

While looking at other OS's I have seen that all take the approach proposed in #72924. Provide an erase by filling with the erase value for devices that do not have erase (e.g. eeprom as mtd in RIOT-OS, eeprom as mtd in nuttx, mtdram and block2mtd in linux, ...).

That is interesting, but when looking at the actual changes in the flash API in this PR and #72924 they are very similar:

Both introduce a flag that signifies "this device does not require an erase operation before writing new data". Both introduce it in the same struct
Both modify pretty much the same drivers (nRF, numaker, Ambiq)
Both provide similar ways for the flash API user to retrieve the flag (convenience functions)

The rest, in my personal opinion, are implementation details of the same basic concept.

The solution proposed in #72924 is cleaner as it only requires touching the drivers that can write without prior erase.

This is true in this PR too. I only see changes in the .c files of flash drivers that can write without prior erase.
All in all, I do not see actual significant differences in conceptual architectural design in this PR and #72924.

I agree on this view that the basic concept and implementations of both PR are similar (sorry if I don't have a deeper understanding for these proposals). I would like to thank @Laczen 's positive discussion and another proposal for this whole thread.


dart compile exe support static linking of C code

dart compile exe enables compiling Dart source code to a standalone executable.
It would be nice if we could link in static libraries in this process so that we can use DynamicLibrary.executable() to look up the symbols.
Current workaround: Use shared libraries, use DynamicLibrary.open() with a relative path, and ship a folder with the dart compile exe executable and the shared libraries (*.so / *.dll / *.dylib).
Technical work that needs to happen for this:

[ ] Make dart compile exe use a proper format instead of appending the precompiled programing as a blob to the dart precompiled runtime by using a a proper linker on each target platform.
[ ] Add options to pass in linker arguments.

(cc @mkustermann, @cskau-g I don't think we had an issue tracking this yet.)

was just trying to figure out how to do this, this would be great, yes.

Yes. That's what we need. Compile C/C++ libs together into a standalone executable.
I come up with an idea that. In the future we can have a function called StaticLibrary.open().
And after that, everytime when we try to compile it, dart compiler can add the C/C++ libs to the end of the main binary. When the binary is executed, it would look for the place of the C/C++ lib where was attached to itself. It would have some affect on loading time, and RAM consumption. But it's easier to deliver apps. Just make it optional.
This feature can be only for dart compile exe, not for aot-snapshot, jit-snapshot, kernel.

Make dart compile exe use a proper format instead of appending the precompiled program as a blob to the dart precompiled runtime by using a a proper linker on each target platform.

Work underway for MacOS: https://dart-review.googlesource.com/c/sdk/+/228080
cc @sstrickl

Also please make the linker configurable, cross linking with lld works on all platforms these days and would be nice to support in addition/instead of the system linker.

We would like to address this using the static bindings with @FfiNatives:

https://github.com/dart-lang/sdk/issues/49418

@laoshaw dart compile already produces a single, executable without any dependencies except the usual C runtime ones:
$ dart compile exe main.dart
$ ldd main.exe
        linux-vdso.so.1 (0x00007fff4a3fc000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f63d4122000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f63d411d000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f63d4036000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f63d3e0e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f63d47ea000)

This issue is specifically about being able to do so when also link in static libraries into that executable when using Dart FFI.

This issue tracks statically linking in C libraries that package developers provide.
Statically linking in the C runtime dependencies of the dart aot runtime would be a different project. @laoshaw do you have any issues with deployment depending on the C runtime libraries that are available? These libraries are always pre-installed on Linux. And bundling them would significantly increase the binary size of your final program.

Yes, I would like ldd main.exe outputs not a dynamic executable instead of listing all those C libraries, that makes depolyments as simple as golang, is this possible?

Doing this may already be a showstopper as it may break a number of things, see e.g. discussion here. I also recall that such statically linked binaries will have trouble opening dynamic libraries, which is something dart:ffi provides and we cannot break.

https://dart.dev/tools/dart-compile:

The exe subcommand produces a standalone executable for Windows, macOS, or Linux. A standalone executable is native machine code that's compiled from the specified Dart file and its dependencies, plus a small Dart runtime that handles type checking and garbage collection.
[…]
Known limitations
The exe subcommand has some known limitations:

No cross-compilation support
No support for dart:mirrors and dart:developer

A standalone executable that depended on a glibc with correct version being present at runtime is not what I expect when I hear "standalone executable".
Given that this will not be "fixed" any time soon (no activity for 1.5 years) this should be clarified / added to known limitations.

@rusty-snake Much to my chagrin, there are tons of "standalone" applications in the wild that depend on a specific C library being installed to function. Regardless, this issue is specific to user-supplied C libraries at compile-time.
@dcharkes Consider renaming this issue to reduce confusion.


Trying to access pointer value from the Struct closes the application

I have a struct
class MODULEINFO extends Struct {
  external Pointer lpBaseOfDll;
  @Uint32()
  external int sizeOfImage;
  external Pointer entryPoint;
}

And a function
static getModuleInformation(int hProcess, int hModule) {
    final _getModuleInformation = _psapi.lookupFunction<
        Int32 Function(IntPtr hProcess, IntPtr hModule, Pointer<MODULEINFO> lpmodinfo, Int32 cb),
        int Function(int hProcess, int hModule, Pointer<MODULEINFO> lpmodinfo, int cb)>('GetModuleInformation');

    final mi = calloc<MODULEINFO>();
    final int dwSize = sizeOf<MODULEINFO>();

    int f = _getModuleInformation(hProcess, hModule, mi, dwSize);
    print(f); // Function succeeded with result 1

    print(mi.ref.lpBaseOfDll.cast<Int32>().elementAt(0).value); // Application just closes
  }

When i try to print a value from the struct - application crashes without any errors. Am i doing something wrong or it's a bug?

Hi!
What does print(mi.ref.lpBaseOfDll) print? If that is an address that is not allocated or it is 0x0 (nullptr) and you're trying to access that, the application crashes with a segmentation fault because you're trying to access memory that your application has not allocated.

Hi!
What does print(mi.ref.lpBaseOfDll) print? If that is an address that is not allocated or it is 0x0 (nullptr) and you're trying to access that, the application crashes with a segmentation fault because you're trying to access memory that your application has not allocated.

... address at 0x75190000 ...

Is hProcess pointing to your current process or to some other process?

Is hProcess pointing to your current process or to some other process?

To some other process

Then you need to use ReadProcessMemory. You can't directly dereference the pointer because it originates from virtual address space of an another process.

Then you need to use ReadProcessMemory. You can't directly dereference the pointer because it originates from virtual address space of an another process.

I have an issue with RPM - it does not work for some reason: https://github.com/timsneath/win32/discussions/215. And i cannot find out the problem because GetLastError does not retrieve latest winapi error

@kirill-21 we're tracking that in https://github.com/dart-lang/sdk/issues/38832.


Bump to 1.3.8

Python 2.7 only
No cythonize code
CI optimizations

Pull Request Test Coverage Report for Build 218

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.894%

Totals

Change from base Build 205:
0.0%

Covered Lines:
946

Relevant Lines:
947

💛  - Coveralls


In dag_resnik, assign NA for pairs with no common ancestor

We've been running Resnik similarities on fairly large graphs, so pairs without common ancestor are good to know about but also throw an error. Could we add an option to skip the error and assign NA (or even zero) to these pairs instead?

@justaddcoffee


src: fix object null prototypes being ignored

Objects with null prototypes are ignored, causing the static resolve() method to return undefined if the object has no constructor; it should fallback to the Object constructor to return a Record instead of undefined when coerced to a string, e.g.
const { Type } = require('@sapphire/type');

const value = Object.create(null);

value.test = 1;

const type = new Type(value).toString();

console.log(type); // undefined

Nice catch! This might have been an unintended product of a refactor.
As a side note, can you add an unit test here to cover this specific case?


Sphinx Sitemap Generator Extension

https://github.com/jdillard/sphinx-sitemap
Sphinx Sitemap Generator Extension
A Sphinx extension to generate multiversion and multilanguage sitemaps.org compliant sitemaps for the HTML version of your Sphinx documentation.
https://pypi.org/project/sphinx-sitemap/

https://github.com/readthedocs/readthedocs.org/issues/6841


Extension development: vscode.workspace.applyEdit() runs only once. Other instances are ignored (?)

VSCode Version: 1.22.2
OS Version: Ubuntu 16.04

I am creating an extension for VSCode that requires multiple ranges of texts to be deleted by one command (function). For this, I am using vscode.workspace.applyEdit() function, calling it multiple times using a loop.
The problem: The applyEdit() applies the edit only for the first time its called and the next multiple times its called using the loop, it does nothing.
Here's the code:
let text = activeEditor.document.getText();
let regEx = new RegExp(this.expression, "ig");
let match: any;
let edits: Array<any> = [];

//Pushing all edits to the `edits` array
while (match = regEx.exec(text)) {

    let edit = new vscode.WorkspaceEdit();
    let startPos = activeEditor.document.positionAt(match.index);
    let endPos = activeEditor.document.positionAt(match.index + match[0].length);
    let range = new vscode.Range(startPos, endPos);
    edit.delete(activeEditor.document.uri, range);
    edits.push(edit);

}

//Applying all edits
for (let i: number = 0; i < edits.length; i++) {
    vscode.workspace.applyEdit(edits[i]);
}

The applyEdit-function returns a Thenable which must be awaited

Hey @jrieken , could you please elaborate as to how to implement that? This is my first extension so I might need that extra help :D. Thanks!


Android release build not get detected though it is already build

Detox version : 12.5.0
RN : 0.59
I build my app using detox and it is successfully build up . Now when i am trying to test the app it gives me an error that release build is not found . But the same works fine when the debug mode is been considered for testing.
Can someone look into this ?

You are here for quite a lot of time now, you should know better on how to report an issue.
Please do not ignore the issue template, we can't understand your issues without the required data.

okay sorry for the inconvenience , closing this one will fill new with proper template


diff features

Vim (doc) and Neovim (doc) can make horizontal/vertical diff of arbitrary files, independently of a Source Control Manager (Git...).
They have a command line interface (vimdiff or nvim -d), and commands (:diffthis, :diffput, :diffget, ...).
I'm sure Code extension will be available to see the diff of files in Git, but having these command (:diffthis, :diffput, :diffget, ...) working on arbitrary files would be great! (I use them every day since years...). Having the command line interface would be cool too.

vim-fugitive is an amazing way to see and interact with git diffs in vim, by adding the :GDiff command. Don't know what I would do without it. Maybe once viml functionality is stable, we can just use fugitive in oni.


jdk-21 Windows builds not always reproducible

Following issues sometimes causes non-reproducible output:

jrt-fs.jar classes differ if bootjdk-21 used compared to jdk-20, see: https://bugs.openjdk.org/browse/JDK-8316648
jvm.dll not reproducible if built on a Windows machine which has MS Visual Studio installed in a different directory, see: TBD

jrt-fs issue:

Backporting fix to jdk-21.0.2 : https://github.com/openjdk/jdk/commit/0f0c5b2d71e6dec442a5105ba305043cb59b99fc

Various backports in-progress to resolve this:

https://github.com/openjdk/jdk21u/pull/300
https://github.com/openjdk/jdk21u/pull/312
https://github.com/openjdk/jdk21u/pull/313
https://github.com/openjdk/jdk21u/pull/315

Various backports in-progress to resolve this:
* [8316648: jrt-fs.jar classes not reproducible between standard and bootcycle builds openjdk/jdk21u#300](https://github.com/openjdk/jdk21u/pull/300)

* [8286757: adlc tries to build with /pathmap but without /experimental:deterministic openjdk/jdk21u#312](https://github.com/openjdk/jdk21u/pull/312)

* [8317340: Windows builds are not reproducible if MS VS compiler install path differs openjdk/jdk21u#313](https://github.com/openjdk/jdk21u/pull/313)

* [8317601: Windows build on WSL broken after JDK-8317340 openjdk/jdk21u#315](https://github.com/openjdk/jdk21u/pull/315)

All backports now in jdk21u


Encrypted keyring

Hi there;
I was using the original release and have upgraded just now.
I've noticed that the script now asks "Please enter password for encrypted keyring:" with every push.
Is this the normal behaviour? as I do not want to be asked for the password every time.
Thanks

Hello,
You're probably using a Linux without a desktop environment. In this scenario, the keyring module looks for the pycrypto module. If that module is installed, the keyring module creates an encrypted keyring using that pycrypto, which requires you to enter your password every time you wish to access it.  The solution is to put a configuration file for the keyring module that instruct it to use the unencrypted key ring.
On Windows, OS X and Linux with a desktop environment, Pushbullet CLI should use the system keyring.
I'll add this to the README file soon.

You're right I am using a headless Ubuntu server, CLI only.
Thanks very much for your temporary solution. Much appreciated.

Should be fixed in the next version even without a configuration file


wrong commandlet

"NewRgsTimeRange" should be "New-CSRgsTimeRange". Last example

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

ID: 3c2cb3f4-ea7e-a592-a28c-aada77bf9c4f
Version Independent ID: a464fc09-36f4-c382-f5ee-228e8aac5268
Content: (Optional) Define Response Group business hours in Skype for Business
Content Source: Skype/SfbServer/deploy/deploy-enterprise-voice/optional-define-response-group-business-hours.md
Product: skype-for-business-itpro
GitHub Login: @kenwith
Microsoft Alias: kenwith

@reisi1 Thank you for this feedback
I have submitted a pull request with the cmdlet changes you suggested. I am waiting approval then we can merge the update to the live document.  Thank you for helping make the docs better.

Confirmed this is fixed in the PR. @AndreaBarr - just a note on Pull Requests that I learned.. you can paste the URL of this Issue in the comments of the Pull Request and it will automatically add a reference link. Just wanted to pass that along.
Thanks for fixes on these!


Allow running arbitrary Kotlin code

See PoC at https://github.com/krzema12/github-actions-kotlin-dsl/blob/runKotlin-PoC/.github/workflows/script-with-server.main.kts

See discussion at https://kotlinlang.slack.com/archives/C02UUATR7RC/p1648387696252109?thread_ts=1648387696.252109&cid=C02UUATR7RC

How about
uses(
    action = CustomAction(
        actionOwner = "fwilhe2",
        actionName = "setup-kotlin",
        actionVersion = "main",
        inputs = mapOf(
            "version" to "1.7.0"
        )
    )
)
run(
    // language=kotlin
    command = """
        println("Hello from action logic! (works already)")
    """.trimIndent(),
    _customArguments = mapOf(
        "shell" to StringCustomValue("kotlin -howtorun .main.kts {0}")
    )
)

?

@Vampire it's not ideal - no compile time verification of the Kotlin code, no syntax highlighting outside of IntelliJ. But yeah, what you showed is already something, even better if #286 is done. We could also have
runKotlin(
    // language=kotlin
    "println("Hello from action logic! (works already)")"
)

where runKotlin would have shell = "kotlin -howtorun .main.kts {0}" built-in + try to validate Kotlin code in workflow compile time. I'd go this way as first iteration and see how it works in practice.

Maybe runMainKts to make it clear it runs as *.main.kts and you can for example use @Depends and so on.

Why not just running a normal kotlin script?
Le ven. 17 juin 2022 à 20:09, Piotr Krzemiński @.***> a
écrit :

@Vampire https://github.com/Vampire it's not ideal - no compile time
verification of the Kotlin code, no syntax highlighting outside of
IntelliJ. But yeah, what you showed is already something, even better if
#286 https://github.com/krzema12/github-actions-kotlin-dsl/issues/286
is done. We could also have
runKotlin(
// language=kotlin
"println("Hello from action logic! (works already)")"
)
where runKotlin would have shell = "kotlin -howtorun .main.kts {0}"
built-in + try to validate Kotlin code in workflow compile time. I'd go
this way as first iteration and see how it works in practice.
—
Reply to this email directly, view it on GitHub
https://github.com/krzema12/github-actions-kotlin-dsl/issues/136#issuecomment-1159120301,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADQFSGFCDSVFMCWPAFPKI3VPS5NXANCNFSM5Q672EUA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Experimenting with a much simpler approach, WIP on https://github.com/typesafegithub/github-workflows-kt/tree/136-allow-putting-Kotlin-logic-in-lambda

The experimental implementation is on its way, let's gather feedback.


[FEAT]: Embeded Chat Widget: Multimodal & Agents

What would you like to see?
We hope Embedded Chat Widget can add support to attach files (images, documents), and Voice Trigger (Mic Input), Agents Features into stream-chat messages just like the feature in the Workspace Chat.

As part of this request:
Mic input and also audio output (STT and TTS) would be really amazing long-term, in order to enhance accessibility on a website with the chatbot. Especially as these already exist in the main application, so maybe the embed widget could the same mechanism. Thank you, the software is amazing! My company would love to use it for the education/welfare sector, so accessibility is always important.


DOC: order of operation in TFR functions needs to be clarified

issue came up here: https://gitter.im/mne-tools/mne-python?at=5f05de658342f4627400eee5
the tfr_morlet for time frequency decomposition has a parameter average which says:

If True average across Epochs.

The docs need to be updated to make it clear what the order of operations is. First averaging then decomposition? Or the other way around? What are the steps?

I'm relatively confident that the order is

decomposition
averaging

if you do the following
freqs = np.arange(8, 31)
n_cycles = 7
a = mne.time_frequency.tfr_morlet(epochs, freqs, n_cycles, average=True)
b = mne.time_frequency.tfr_morlet(epochs, freqs, n_cycles, average=False)

I'm pretty sure that a == b.average()

That makes me wonder why there is an average parameter at all --> mne.Epochs doesn't have one either? :thinking:

the average avoids storing all the TFRs in memory as the averaging is done
online.

I think there might be a problem in the test
The following line in the test should fail
https://github.com/mne-tools/mne-python/blob/2965cc3644538c97b297f131bbb46ce9f954ea6f/mne/time_frequency/tests/test_tfr.py#L109
but it passes because assert_array_almost_equal only checks 6 decimal places and (Pdb) power.data.max() 2.1955190395488294e-21
and in fact assert_array_almost_equal(power.data, power_evoked.data, 22) fails with a Max relative difference:<PHONE_NUMBER>5224

Yeah that test looks broken. We should move to assert_allclose and probably just use rtol there (unless we expect some near-zero values, in which case a suitable atol should be chosen based on what "zero-like" means for the data)

this test makes no sense. You should not expect the TFR of the epochs to be
the same as the evoked.

I'm relatively confident that the order is
1.decomposition
2. averaging

The critical part is where is the magnitude taken. decomp/mag/ave will be different from decomp/ave/mag (with the latter being equivalent to ave/decomp/mag).

this test makes no sense. You should not expect the TFR of the epochs to be the same as the evoked.

You should expect the TFR averaged across epochs to be the same as the TFR of the evoked if the magnitude is taken at the end (or not at all) for both. Maybe that's what the test was trying to check? And maybe it was wrong about when the average is taken (i.e., before or after the magnitude is taken)? Someone will need to dig into the code to check...

for me code is correct but test is broken.

I agree with @agramfort and think the test was in error. the procedure to compute total power is to decomp/mag/ave. otherwise you are computing evoked total power which isn't (generally) what you want.

I should note that the surrounding assert_array_almost_equal are testing meaningful things and currently are trivially passing because of the lack of a decimal parameter

Sounds reasonable to me, @bloyl would you be up for fixing the code to use assert_allclose with rtol only and document the order of transformations in some TFR computing function (and maybe refer other ones to look at the Notes for that one)?

Sure although Docs aren't exactly my strong suit.
@sappelhoff what do you think of
    average : bool, default True
        If False return an EpochsTFR containing separate tfrs for each epoch.
        If True return an AverageTFR containing the average of all tfrs across epochs.

@sappelhoff what do you think of

I think that's good but I would add some more detail:
    average : bool, default True
        If False return an EpochsTFR containing separate tfrs for each epoch.
        If True return an AverageTFR containing the average of all tfrs across epochs.
        AverageTFR is equivalent to EpochsTFR.average(), but setting average=True will
        be more memory efficient than setting average=False and later calling
        EpochsTFR.average().


Report the number of correctly guessed differences in ceca.py.

See this comment in #28.

For all 120 differences.
(We can also report the number of correct key bytes as well but based on my observation it doesn't provide a lot of information.)
@vogelpi, fyi.

This got resolved with #53 .


small-gui-adjustments

Pushed. please take a look

What is the meaning of Delayed? It's the same as 'Queued' - what is the state which a job get immediately after submission to the kue (before it starts to be processed)

What is the meaning of 'Inactive' jobs?

What is the meaning of 'Active' jobs?

Complete and Failed are obviously self-explanatory (from user's perspective)

Inactive - job is created, but never/not yet processed.
Active - job is currently processing, and not yet done i.e. done() is not yet called.
Delayed - I guess this is just delay from when it's supposed to be processed. When creating a job, you can specify it to be delayed:

var email = queue.create('email', {
    title: 'Account renewal required'
  , to<EMAIL_ADDRESS>  , template: 'renewal-email'
}).delay(milliseconds)
  .priority('high')
  .save();

To sum it up:
Create job: inactive / delayed (depends on delay flag)
Process job: active
Job complete: complete / failed (depends if there's error or not)
I'll add some delay jobs in the seed data.

Added some delayed jobs. These jobs are not processed so its delayed status will remain.

Thank you for the clarification with the meaning of states and for adding the delayed jobs.


[Build] Consider enabling Gradle Enterprise

Consider enabling GE support. I am not sure what all it provides but most of our CIs are using it.
Look into spring-security CI to see examples as our CI is very much based on that.

We should also make sure the following versions are up-to-date:
plugins {
	id "com.gradle.enterprise" version "3.5"
	id "io.spring.ge.conventions" version "0.0.7"
}

This is complete via several commits.


⚠ Mobitopup has degraded performance

In ce5ea31, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4334 ms

Resolved: Mobitopup performance has improved in b2253c7 after 420 days, 18 hours, 11 minutes.


Remove duplicate calls to mgmt settings on fresh load

Summary
Fixes #9304

Occurred changes and/or fixed issues

Concurrent calls to findAll would always result in two requests

when findAll runs we cache running results with key JSON.stringify(headers) + method + opt.url
if a request is made with a matching key we return the promise associated with the first request (thus negating a second request)
when mgmt settings were fetched with a hardcoded url ... url contains singular setting
when mgmt settings are fetched without hardcoded url ... url contains plural settings
therefore the second call to findAll was not using the cached promise from the first call.... resulting in a second request

After the above is fixed, noticed two other issues

When making a request we checked the response headers for a specific auth header which we pushed to the auth store.... however the getter for this was broken and always returned undefined

This meant even with fix number 1 from above an additional requests was still made
i.e first request fetches a partial response which is set in store via loadMulti... second request fetches full response however it was treated as partial so stored via loadMulti, so next findAll didn't know it had all and made a new request which did eventually store with loadAll)

The fix for number 1 above handled the case when two concurrent calls to findAll occurred. If the api returns quickly the findAll requests become sequential. Sequential findAlls with _ALL_IF_AUTHED always resulted in individual requests.

findAll when _ALL_IF_AUTHED and not logged in results in loadMutli mutation. next call to findAll doesn't find a running request... and makes another one.

The above is addressed by removing _ALL_IF_AUTHED (it's only used for settings) and using a new fetchInitialSettings helper function which

if auth'd uses usual mechanism of findAll with no flags. if any previous call existing with partial results this means a new call for all results will be made. if a call is currently happening it'll use the same promise.
if not auth'd and haven't previously fetched results... fetch them and ensure we persist to store via loadMulti (so future findAll calls, once authed, result in new request)
if not auth'd and HAVE previous fetched results... just returned them

Also

in unauthed world don't block loading of dashboard on fetching setting for favicon, this speeds up load of login page
replaced findBy with .find in some places
'settings' to NORMAN.SETTINGS
Fix issue where now populated fromHeader can be false
~Don't mix up CATTLE_BOOTSTRAP_PASSWORD and TEST_PASSWORD, this causes issues in the setup flow when they're different~ e2e tests bring up rancher with CATTLE_BOOTSTRAP_PASSWORD... and if so the fields to change password are hidden. this breaks the change i made to setup admin user's password with TEST_PASSWORD and not CATTLE_BOOTSTRAP_PASSWORD
Refactor setup test, re-enable check at end

Areas or cases that should be tested

Refresh on setup page

One request, partial response
Previously this was three blocking http requests

Refresh on log in page

One request, partial response
Previously this was three blocking http requests

Refresh on home page

One request, full response
Previously this was two blocking http requests (settings/setting)

Refresh on log in page, log in

Two requests, one partial and the second one full
Previously this was five blocking http requests

PR includes automated tests that cover the above cases
Areas which could experience regressions
As per sections above, but with no branding and then with branding (colour scheme et all is correct)
Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

Looks like e2e tests are failing on setup. Will investigate

The e2e test coverage and api interceptions look good to cover the validation of these multiple calls fix. That wait seems necessary too. @yonasberhe23


Cannot sign in to github: No action.

Type: Bug
Nothing happens when i try to click sign in to github. no redirect no errors nothing.
VS Code version: Code 1.84.0 (d037ac076cee195194f93ce6fe2bdfe2969cc82d, 2023-11-01T11:29:04.398Z)
OS version: Windows_NT x64 10.0.22621
Modes:

System Info

Item
Value

CPUs
12th Gen Intel(R) Core(TM) i5-1235U (12 x 2496)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
15.68GB (7.72GB free)

Process Argv
--crash-reporter-id b1feeaa3-a763-4d48-9513-b46a30a25825

Screen Reader
no

VM
0%

Extensions (3)

Extension
Author (truncated)
Version

codespaces
Git
1.16.2

python
ms-
2023.20.0

vscode-pylance
ms-
2023.11.10

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263:30880072
vscaac:30438847
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
282f8724:30602487
89544117:30613380
vscrp:30673768
showlangstatbar:30737416
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxpt:30866567
pythonnoceb:30805159
dsvsc013:30795093
dsvsc014:30804076
dsvsc015:30845448
pythontestfixt:30871694
pythonregdiag2:30871582
pythonmypyd1:30879173
pythoncet00cf:30874137
pythontbext0:30879054
dsvsc017cf:30880893

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

Can you follow these steps so that we can get more information on what's going on?

Open the Command Palette
Run the Developer: Set Log Level... command
To the right of Trace, click the double check mark button. ✔ ✔ (enables trace logging as the default)
Wait for the issue to happen...
Open the Output pane (ctrl+shift+u I think on Windows)
drop in this issue he contents of the following:

Microsoft Authentication Output channel
Log (Settings Sync) Output channel
Log (Main) Output channel

Open the Command Palette
Run the Developer: Set Log Level... command
To the right of Info, click the double check mark button. ✔ ✔ (to set the default back to info)

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Create mergerfs.findfile

This script tells you which drive holds the file you're looking for. It also warns you if there are multiple copies in different drives.

@trapexit I have been using mergerfs (with Snapraid) for many years now, and often I needed to know which physical drive a file was actually stored on. Recently, I started a file migration project that made this crucial to me. So using the knowledge exposed by mergerfs.consolidate, I created this script to identify the drive mergerfs found the file on, and also if it's duplicated on other drives (redundant, I know, but helpful in my case).


Add new checks and new script

ENH: Replace erroneous LabelValue
BF: Fix spacing for loading and saving in nrrd
NF: New script to print headers

Hello @GuillaumeTh, Thank you for updating !

In the file avnirpy/segmentation/utils.py:

Line 29:101: E501 line too long (108 > 100 characters)


gridOptions dict example

First, thank you for this much needed component!
Please, consider the MWE below. I cannot figure out the syntax to pass the list of options directly to gridOptions, could you provide an example?
from st_aggrid import AgGrid
import pandas as pd

df = pd.read_csv('https://raw.githubusercontent.com/fivethirtyeight/data/master/airline-safety/airline-safety.csv')

AgGrid(df, gridOptions= {'configure_selection':{'selection_mode':'multiple', 'use_checkbox':True}})

I'm working on a basic documentation.
If you want to specify the gridOptions dictionary by hand, you need to describe all columns using columnDefs.
It is easier if you use the GridOptionsBuilder

Thank you @PablocFonseca , I feel like aggrid will be much more used and fully explored once a basic documentation is available. It seems to have awesome capabilities.


better kithen ohai pinning

since it turns out kitchen-tests/Gemfile.lock isn't actually checked in
the prior change was still just effectively floating on master, this
now makes us parse the ohai version out of the root Gemfile.lock and
use that to install ohai from git in our virt.

travis failures are unrelated.


Scripts and processes - Script output

References
Add references/links to any related issues or PRs. These may include:

Related to REST Contract -> Pertaining to the "output" link -> "/api/system/processes/5/output"
Fixes GitHub issue, the output of the script can afterwards be used for additional testing etc

Description
For both the Angular team, as well as for the writing of certain REST tests, we want to be able to see the output of a script that has been started from the scripts and processes.
Instructions for Reviewers
Please add a more detailed description of the changes made by your PR. At a minimum, providing a bulleted list of changes in your PR is helpful to reviewers.
List of changes in this PR:

ProcessLog is a new db table that is used to keep the script output in the db.

This has been updated through the scripts and processes Flyway file
This also keeps the log level separately in the table for more specific information

The scripts that are handled through the RestDSpaceRunnableHandler are logged to the db
A new mode 'MANAGED' for the Context has been created

When this mode is used, spring retrieves a 'managedHibernateDBConnection'
This allows for more finegrained usage of the commits, since we need to be able to commit immediately after wanting to write to the logs since, if the process fails, and the log hasn't been comitted to the db, the information on WHY the script failed is lost

This context is separate from the thread and doesn't interfere with the script. For example, if we want to print to the logs that x items have been processed, but we do not want to actually commit it until all items are ready, we can commit this context, and make sure that the actual item changes are not committed.
This 'managed' context can basically be considered the DSpace5 context where you are completely responsible of the state of the context.
The 'normal' context for DSpace 6 and 7 is connected to the thread

ProcessOutputRest and ProcessOutputResource are added to support the retrieval through REST
ProcessRest added to support the link through the LinkRest framework
ProcessOutputLinkRepository added to support the retrieval call
Added required logic to xml files:

DAO in core-dao-services.xml
hibernate managed vs normal threadbound xml in core-hibernate.xml and hibernate-managed-ehcache-config.xml
Model object in hibernate.cfg.xml

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
[x] My PR passes Checkstyle validation based on the Code Style Guide.
[x] My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
[x] My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
[x] If my PR includes new, third-party dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[x] If my PR modifies the REST API, I've linked to the REST Contract page (or open PR) related to this change.

@jonas-atmire and @benbosman : I'd like to better understand the design here, as I was surprised to see this PR is writing the script output as a (potentially giant) string to the database.  Since all Process objects can have associated Bitstreams, why are we not just creating a text Bitstream of the script output instead of having to make all these Hibernate level changes just to support this feature.  It seems like that approach could have also worked -- I had imagined an approach where you are simply always writing the output to a temp file, and then (once completed or failed) saving that temp file as a Process Bitstream.
As I look at the code here, I'm finding the number of necessary Hibernate changes (for one new feature) worrisome...especially since there's no new tests (in HibernateDBConnectionTest or similar) to verify that this new "Managed" connection type is working how we expect. However, before we dig into that, I'd like to ask that simple design question to understand why you chose this implementation direction.

I too was startled to see process output being shoveled into the database.  On the other hand, the needed changes to Context provide yet another example of why Context is the wrong place to be keeping Session and why we need to abandon the idea that a unit of work can have only one Session.

@tdonohue / @mwoodiupui
Currently, we took the usage of this separate DB table because of:

If we were to keep the actual script output in a file, this removes the option (for later on) to push the output of the script to the UI so it can be followed 'live'
We wanted to avoid writing to a file since continuous writing to bitstreams isn't supported atm (Writing to a temp file, and writing once WOULD be an option possibly)
That being said, this most likely could use additional investigation into performance for the current initial implementation.

Before any further changes are done, this needs to be properly discussed to avoid additional back and forth on changed code obviously

I've verified how the output is being stored in this PR.
There are a few different options, all with their pro/con:

storing the output in the database

pro: easy to link to the process
con: the DSpace DB management doesn't allow committing some data while keeping other parts uncommitted (using 2 DB connections). This creates a large amount of code changes
con: if the script creates a huge amount of output, this increases the amount of DB rows significantly

storing the output in the assetstore

not possible since the assetstore doesn't support adding data to a file

storing the output in a file on the filesystem

pro: no overhead for adding contents per line
con: a script writing to a file and a REST endpoint reading the file to return the latest contents simultaneously can cause issues
con: linking the file to the script is harder
con: cleanup of the files is more tricky, deleting the script from the DB doesn't necessarily delete the separate file

Because non of them are ideal, perhaps a different approach should be used which only stores the output after the script completed or failed:

storing the output in the database, but only after the script completed or failed

pro: easy to link to the process
pro: no complex DB management
pro: the entire log can be stored in one DB row
con: if tomcat is shut down, the status may be lost

storing the output in the assetstore, but only after the script completed or failed

pro: easy to link to the process
pro: no complex DB management
pro: the entire log can be stored in one bitstream
con: if tomcat is shut down, the status may be lost

storing the output in a file on the filesystem, but only after the script completed or failed

pro: no problems with simultaneous reading/writing
con: linking the file to the script is harder
con: cleanup of the files is more tricky, deleting the script from the DB doesn't necessarily delete the separate file

From these options, my preference would go to either:

storing the output in the database, but only after the script completed or failed
storing the output in the assetstore, but only after the script completed or failed
In that preference, I did not verify how much work these options would require

Does anyone see other options, or has other preferences?

All of the "store after completion" options boil down to "write the developing output to a temporary file and remember where you put it."  The latter part:  for in-the-database, read the file back in and write a LOB; for Bitstream, formulate some metadata and "register" the file; for plain file, I don't know.
I really should dig into the code, but from examining the "con"s it seems to me that there is no persistent object to represent "an execution of a script".  Such an object would be the natural place to remember working storage containers, and deleting it would trigger removal of any linked log row/Bitstream/file.

The general preference mentioned in the meeting would be the option:

Storing the output in the assetstore, but only after the script completed or failed

In order to create the output prior to storing it in the assetstore, two potential solutions were suggested:

Simple file writing of the logs to a file containing the script's UUID. Upon completion or failure the file is migrated to a bitstream and removed from disk. If the tomcat shuts down, the file remains present
Using log4j writing to a separate file per script (to support multiple simultaneous scripts). Upon completion or failure the file is migrated to a bitstream and removed from disk. If the tomcat shuts down, the file remains present

The output would still be made available for Angular using the current output REST endpoint. This will read the bitstream and parse it to the output format

Closing in favor of: https://github.com/DSpace/DSpace/pull/2934


Network stream support

Sir this is amazing app hands down the best Android plyer
But sir please can u give support for network stream as it wasy easier to stream files than downloading and than play them it saves time

https://github.com/moneytoo/Player#how-do-i-open-a-streaming-link-where-do-i-enter-an-url


About the volume after packaging

When building, the vue-pdf-embed.js file contains pdfjs code, which increases the size. At the same time, if the caller has a pdfjs package, it will contain a duplicate package

Hi @sugar1999,
I'm going to provide more builds in the next minor release, so there will be options to load the lib with or without PDF.js (as mentioned in #128)

See https://github.com/hrynko/vue-pdf-embed/issues/128#issuecomment-1912275958


CSV writer: fixed EOL length to handle CRLF correctly (Issue #519)

Fixed EOL length to handle CRLF correctly
#519

+1


DB query optimization suggestion

In cases where there are multiple language and translation fields in a table, I would like to suggest a way to reduce the number of queries. I haven't used this library, so I'm not entirely certain about this solution. However, I thought this approach could reduce the query count and improve performance.
query_classes = args.group_by { |attr| self.mobility_query_class(attr) }
query_classes.each do |query_class, attributes|
  values = self.current_locales.map do |locale|
    attributes.map { |attr| send(:"#{attr}_#{locale}")}
  end.flatten

  count_by_group = query_class
    .where(locale: self.current_locales)
    .where(translatable_type: self.class.to_s)
    .where(key: attributes, value: values)
    .where.not(translatable_id: id)
    .group(:key, :locale, :value)
    .count

  count_by_group.each do |(key, locale, _value), count|
    self.errors.add(:"#{key}_#{locale}", message) unless count.zero?
  end
end

Hi @aniliyidogan. Thanks for the suggestion! Batching the queries using group is a great idea. I've tested your approach, and it works as expected.
I ran a benchmark with 10k records but didn’t notice a significant difference, though my development environment might not be ideal for this. However I think your suggestion will improve the performance anyways, because it performs a single query for each query_class with the locales and attribute values put together
Would you be interested in opening a PR for your suggestion after I merge the add test case branch? I’m currently in the process of adding test cases to the gem.


Fix: PR Build GitHub Action

-> I have not tested this but it should fix the issue:
Error: buildx failed with: ERROR: denied: installation not allowed to Write organization package

Make sure the following settings are set:

organization's settings
Navigate to "Actions" under "Code, planning, and automation"
Select "General"
Under "Workflow permissions", ensure that "Read and write permissions" is selected and "Allow GitHub Actions to create and approve pull requests" is checked

Changes:

Fix: Added the write action

Set it like you said. Let’s see. Thanks.


awaitElement should be exposed as an "action" type

--max-trailing-state-changes and --trailing-state-change-timeout are very blunt instruments to specify temporality. A better alternative would be to introduce at least one new action, Await sel which will always be considered valid and, when executed, uses the same logic as for readyWhen on a given selector.
A second approach would be to allow a similar action, Delay milliseconds although the former is likely a better / cleaner alternative.
Note that this feature is especially important in a "guided evolution" approach as provided by #62 (#61 ). Otherwise, blind evolution will likely never reach any targets of significance (in my testing on a real-world application).
[I will go ahead and implement this feature as it is required for my use-case (in conjunction with the PR mentioned above)].

This is done as of #62 being merged.

This is done as of #62 being merged.


Influx derivative query conflicts with bosun rules about grouping and where clauses in the query string.

Using influx derivative:
influx("db", '''SELECT  DERIVATIVE(mean("someValue")) FROM "table"''', "30d", "", "3d")
Results in:
fatal: main.go:121: couldn't read rules: conf: path/to/conf/rules.conf:xx:y: at <crit = $avgincreasel...>: expr: derivative aggregate requires a GROUP BY interval
Tried adding the necessary group by clause to the query:
influx("db", '''SELECT  DERIVATIVE(mean("someValue")) FROM "table" group by time(3d)''', "30d", "", "3d")
Results in:
fatal: main.go:121: couldn't read rules: conf: path/to/conf/rules.conf:xx:y: at <crit = $avgincreasel...>: expr: aggregate functions with GROUP BY time require a WHERE time clause
Then tried adding an arbitrary where clause:
influx("db", '''SELECT  DERIVATIVE(mean("someValue")) FROM "table" where time < now() group by time(3d)''', "30d", "", "3d")
This time bosun actually starts up however when checking the alert:
2017/08/23 07:51:21 info: check.go:588: check alert myalert start with now set to 2017-08-23 07:51:21.392396985
2017/08/23 07:51:21 error: check.go:712: influx query must not contain time in WHERE
2017/08/23 07:51:21 error: check.go:629: Error checking alert myalert: influx query must not contain time in WHERE
2017/08/23 07:51:21 info: check.go:636: check alert myalert done (584.145µs): 0 crits, 0 warns, 0 unevaluated, 0 unknown
2017/08/23 07:51:21 info: alertRunner.go:89: runHistory on total.message.count.increase took 48.016µs

It looks like this is actually coming from the influxdata/influxql module in vendor
https://github.com/bosun-monitor/bosun/blob/master/vendor/github.com/influxdata/influxdb/influxql/ast.go#L1793

The cause of this error is that InfluxQL requires GROUP BY time() for several functions, and while these are normally added by bosun, it only happens after the initial parsing is done.

The only good approach to a fix I see, taking into account more fanciness that comes into InfluxDB, like subqueries, is to:

remove from, to, groupbytimeinterval parameters from influx() function
let the caller control time limits in WHERE clause and GROUP BY however he wants

#1978 is a duplicate of this issue.

No-no-no, stalebot!


Conan Exiles error

I got this error when open Conan Exiles folder.

UModel never opened Conan pak files. You should unpack it first, then open game files. Details are in Conan thread on the forum, link could be found in compatibility table.


Feature/prefix path depth

The Vault driver being used doesn't support a per-lookup depth measurement, so I think this looks good. Once we replace the Vault driver with our own, we should allow it to be set on each lookup.


Ability to delete organisations that are rejected

Currently if an organisation has been rejected, it will just stay there name squatting until someone tries to re-request review. Users should be able to delete rejected organisations.
Also consider deleting organisations at other lifecycle stages.
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Fix Versions: Dockstore 2.X
┆Sprint: Sprint 41 Pufferfish
┆Issue Number: DOCK-1228
┆Epic: Organization Improvements

Verified that this works on dev. Created a pending org in the UI, then deleted it via API (Swagger).


Switch to Webpack

Removed Ruby dependencies
Removed Grunt
Uses webpack for assets bundling with simple npm scripts
SASS is now compiled with libsass
Haz dev server

See the updated README for build instructions.


ARROW-14623: [Packaging][Java] Upload not only .jar but also .pom

.pom files will be needed to publish packages at https://repository.apache.org/#staging-upload .
.jar files are generated at target/ and installed to ~/.m2/repository/org/apache/arrow/.
.pom files are only installed to ~/.m2/repository/org/apache/arrow/.
So this change collects artifacts from ~/.m2/repository/org/apache/arrow/ instead of build directory.
Dist path change (arrow/java/dist -> arrow/java-dist) isn't required but it's better that
we use out of source directory for dist path. It's easy to debug.

@kszucs If we cut 6.0.1 RC1, I want to include this.

@github-actions crossbow submit java-jars

@github-actions crossbow submit java-jars

https://github.com/ursacomputing/crossbow/releases/tag/actions-1097-github-java-jars has both .jar and .pom but version number are 7.0.0-SNAPSHOT not 7.0.0.dev63. We need {no_rc_snapshot_version} in Crossbow or need to use 7.0.0.devXX version in artifacts.

@github-actions crossbow submit java-jars

@github-actions crossbow submit java-jars

Artifacts use 7.0.0.devXXX version: https://github.com/ursacomputing/crossbow/releases/tag/actions-1099-github-java-jars

+1

@github-actions crossbow submit java-jars


Unary minus does nothing with decimal ratios

Even though it's confusing notation -n,m should produce the frequency ratio 1/(n,m) to be consistent with the binary minus operator.

Fixed incidentally.


Bundler::HTTPError - Can't install anything with bundle install

Hi! As of today, I can't install any bundles on my laptop (macOS high sierra). bundle install had been working just fine on my jekyll site for the past month, and now I get:
Fetching source index from https://rubygems.org/

Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Retrying fetcher due to error (4/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Could not fetch specs from https://rubygems.org/

Here is the output from ruby -ropen-uri -e 'eval open("https://git.io/vQhWq").read' :
Here's your Ruby and OpenSSL environment:

Ruby:           2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
RubyGems:       2.7.7
Bundler:        1.16.2
Compiled with:  OpenSSL 1.0.2o  27 Mar 2018
Loaded version: OpenSSL 1.0.2o  27 Mar 2018
SSL_CERT_FILE:  /usr/local/etc/openssl/cert.pem
SSL_CERT_DIR:   /usr/local/etc/openssl/certs

With that out of the way, let's see if you can connect to rubygems.org...

Bundler connection to rubygems.org:       failed  ❌  (execution expired)
RubyGems connection to rubygems.org:      failed  ❌  (timed out (https://rubygems.org))
Ruby net/http connection to rubygems.org: failed  ❌

Unfortunately, this Ruby can't connect to rubygems.org. 😡
Even worse, we're not sure why. 😕

Here's the full error information:
Net::OpenTimeout: execution expired
  /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/net/http.rb:937:in `initialize'
  /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/net/http.rb:937:in `open'
  /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/net/http.rb:937:in `block in connect'
  /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/timeout.rb:103:in `timeout'
  /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/net/http.rb:935:in `connect'
  /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/net/http.rb:920:in `do_start'
  /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/net/http.rb:915:in `start'
  (eval):90:in `<main>'
  -e:1:in `eval'
  -e:1:in `<main>'

You might have more luck using Mislav's SSL doctor.rb script. You can get it here:
https://github.com/mislav/ssl-tools/blob/8b3dec4/doctor.rb
Read more about the script and how to use it in this blog post:
https://mislav.net/2013/07/ruby-openssl/

Running the suggested script, I got:
/usr/local/Cellar/ruby/2.5.1/bin/ruby (2.5.1-p57)
OpenSSL 1.0.2o  27 Mar 2018: /usr/local/etc/openssl
SSL_CERT_DIR=""
SSL_CERT_FILE=""

HEAD https://status.github.com:443
#<Net::HTTPGatewayTimeOut 504 GATEWAY_TIMEOUT readbody=true>

Here is the output of openssl s_client -connect rubygems.org:443 -tls1 :
CONNECTED(00000005)
140736022356936:error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s3_pkt.c:1133:SSL alert number 70
140736022356936:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s3_pkt.c:522:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Start Time:<PHONE_NUMBER>
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Any idea how to fix this and why it randomly broke after working just fine last week?

It looks like everything is timing out -- are you behind a proxy of some kind?

No, but I ended up fixing the problem (hopefully for good) by reinstalling Ruby and Bundler.

Interesting. I just ran into this as well with the same symptoms thus far, but reinstalling hasn't fixed it yet.

@kirillian So it turns out while I had the newest ruby and OpenSSL installed via homebrew, bundler was not using it by default.
This ended up solving my issue: https://stackoverflow.com/a/37416716/9245716

This looks like the issue has been resolved.


[CXF 4.0.4] Make the context propagation for HC5 mode elegant

fix #954

Cherry-picked to https://github.com/quarkiverse/quarkus-cxf/pull/1271