Give guidance on reproducible builds

Some projects have raised concerns about challenges meeting the build_reproducible gold criterion. The purpose of this criterion is to counter malicious builds, as happened in SolarWinds' Orion, by enabling verifiable reproducible builds. We still want to counter the attack, but we may be able to relax the requirement slightly while still countering the attack:

Many projects don't release built software at all (Linux kernel, Apache Software Foundation). In those cases this can be marked as N/A. The project may still explain how to do verified reproducible builds in those cases (and get credit for it), but they should be allowed to say N/A in those cases.
Many projects struggle only because of timestamps being different when there's a rebuild. Those produce differences in bit-for-bit comparisons, but I don't see how such date/timestamp differences by themselves lead to subverted software (there would have to be something else to act as a trigger). Timestamp differences are one of the most common causes for non-reproducibility, and since those differences by themselves aren't security-relevant, it seems overly harsh to demand them. I think it's good to do because it makes later comparison easier, but as I said, it's probably overly harsh.

So under the `build_reproducible' gold criterion, modify:
        description: >-
          The project MUST have a reproducible
          build. If no building occurs (e.g., scripting languages
          where the source code is used directly instead of being
          compiled), select "not applicable" (N/A).

Change the second sentence to read:

If the project does not release built results (such as an executable, package, or container), but instead only releases unbuilt source code, the project MAY select "not applicable" (N/A).

        details: >-
          A reproducible build means that multiple parties can
          independently redo the process of generating information
          from source files and get exactly the same bit-for-bit
          result.  In some cases, this can be resolved by forcing
          some sort order. JavaScript developers may consider
          using npm shrinkwrap and webpack OccurenceOrderPlugin.
          GCC and clang users may find the -frandom-seed option
          useful. The build environment (including the toolset)
          can often be defined for external parties by specifying
          the cryptographic hash of a specific container or virtual
          machine that they can use for rebuilding. The reproducible
          builds project has documentation on how to do this.

Change "result" to "built result", and replace the final period with:

, for example, by adding sorts to enforce deterministic input ordering and setting date/timestamp values. For purposes of this badge, a project MAY consider a result a reproducible build if it produces the same bit-for-bit results except for timestamps. That is because it can be difficult to force consistent timestamps in some build environments and such differences typically cannot be used for attack (without some other additional subversion).

Many projects don't release built software at all (Linux kernel, Apache Software Foundation). In those cases this can be marked as N/A. The project may still explain how to do verified reproducible builds in those cases (and get credit for it), but they should be allowed to say N/A in those cases.

I think we should differentiate between builds reproducible for software that only distributes source code and can be reproduced for software that also distributes binaries. If the project distributes binaries (for example attached to their github release, but also docker images), they should also publish documentation on how to build this exact binary, bit-for-bit identical, from source. Projects like i-probably-didnt-backdoor-this, Tails and bitcoin-core are doing it successfully, but there are very few standard tools available for this (lots of talk around SBOMs but very few tools to setup a build environment based on an SBOM for example).
For projects that only distribute source code, there is no binary that can be reproduced but the build should still need to provide a stable, deterministic output to be considered builds reproducible. A downstream Linux Distribution can then take care that the binary they build and ship can be reproduced. The Linux kernel specifically is currently very non-trivial to build reproducible, Arch Linux and Debian are both struggling with it, so I don't think it should be considered build_reproducible or N/A for example.
I don't think upstream projects that are known to produce binaries/artifacts that are difficult to secure further down the supply-chain should be allowed in Gold Tier.

Many projects struggle only because of timestamps being different when there's a rebuild. Those produce differences in bit-for-bit comparisons, but I don't see how such date/timestamp differences by themselves lead to subverted software (there would have to be something else to act as a trigger). Timestamp differences are one of the most common causes for non-reproducibility, and since those differences by themselves aren't security-relevant, it seems overly harsh to demand them. I think it's good to do because it makes later comparison easier, but as I said, it's probably overly harsh.

Normalizing timestamps in a build is a fairly trivial issue, it's much easier to just fix the differences there instead of having to write programs that try to tell benign differences and underhanded backdoors apart with 100%-reliability. Needing manual intervention to inspect diffs should be the exception, not the norm for software with the build_reproducible gold criterion.

@marcprux hit a lot of important points, thanks!
The problem of doing something "bit-for-bit identical except for ..." presents pragmatic challenges.

more complicated verification process becomes a software development project unto itself
more error-prone which could lead to false positives, false negatives, etc.
might actually be easier to fix projects than to develop the tooling to extract the bits you want to verify

In short, it is trivial to compare two artifacts, it presents a whole world of difficulties to compare only parts of two artifacts.
I would strongly caution against using "reproducible builds" in any way other than https://reproducible-builds.org/docs/definition/ which really comes down to bit-for-bit reproducible without exception.

The projects that I use from the Apache Software Foundation, such as Apache Maven and Apache NetBeans, publish a "convenience binary" along with the source release, all under the Apache name. Apache NetBeans even publishes a Snap package binary. The Maven build is reproducible, but the NetBeans build has quite some way to go before being reproducible.
I have found it surprisingly, and frustratingly. difficult to get changes related to reproducible builds accepted by upstream projects. Holding the Apache Software Foundation to a different standard than other open-source projects just makes that even more difficult. It would remove my incentive to make the changes and one of their incentives to accept them.
I would prefer the meaning of reproducible builds to remain bit-for-bit identical, including timestamps. Even for organizations that truly publish only a source release, one could argue that they should have the gold badge only if that source can be built in a reproducible manner.

more complicated verification process becomes a software development project unto itself

I will second this, @vagrantc. My own App Fair process creates verifiably reproducible iOS apps, but it is a constant struggle against ever-changing versions of the tools generating indeterminate output in insidious new ways (e.g., due to changes in Xcode's compiler parallelization). My main motivation for spending all these hours on tedious devops debugging is the stretch goal that these apps eventually achieve gold certification, and thereby serve as paragons of trust to the mobile community.

As a strong supporter of bit-for-bit integrity without compromises: when developers report challenges producing software to adhere to some evaluation criteria (be that testability, security, performance or other), often it helps to introduce tooling improvements so that flaws (and opportunities) can be detected earlier in the assembly process (for example: the "shift security left" mantra, and similarly with continuous integration in general).
I have a sense that the challenges experienced by many developers are a result of the fact that we generally have to inspect the output of builds (diffs - sometimes binary) to identify where non-reproducible elements have appeared, and then perform sometimes-mentally-challenging detective work to theorize and evaluate what could have caused those artifacts to appear.
Hermetic build environments that can detect changes as soon as they're introduced during assembly could - I think - be an area where improved tooling might help to stem the introduction of non-reproducible elements early during development, in a way that could be largely-ecosystem-agnostic, and help to win developer mindshare.
There could be practical challenges implementing fail-fast hermetic builds (are filesystem reads/writes the unit of integrity?  is language-level and/or IDE-level support required?  how would ephemeral and tempfiles be handled?) but I think they're manageable.  And similar to test-driven-development: not everyone will want to adopt early-detection since it would add development friction - but for those who understand the value of it as an investment, the benefits should be clear.
(sorry for sidetracking a bit: again I would reiterate that there shouldn't be exceptions for timestamps, because it's not clear what even is simply a timestamp at a binary level, and it would open the door to the very risks that reproducible builds are intended to solve, and there are unanswered questions about how integrity verification could be performed on content that fundamentally differs -- all points that others have alluded to.  however I want to state both my support and suggestion that there may be solutions to address concerns)

Many projects struggle only because of timestamps being different when there's a rebuild. Those produce differences in bit-for-bit comparisons, but I don't see how such date/timestamp differences by themselves lead to subverted software (there would have to be something else to act as a trigger). Timestamp differences are one of the most common causes for non-reproducibility, and since those differences by themselves aren't security-relevant, it seems overly harsh to demand them.

I think this isn't a good idea because it can lead to the dangerous and false assumption that the rebuild with only a different embedded timestamp can be considered identical in behaviour. But any binary could change its behaviour when there's some specific embedded timestamp. Yes, that would be visible in the source, but might be intentionally hidden as well.
So while, when we get to the "only timestamp is different" level of almost-reproducibility, it's easy to go the last step (easiest: replace the timestamp in the binary you just built with the other one), this step is just as crucially important as all the other ones, so it can't get any special treatment.
(The Android App world has a related problem with it's embedded signatures, which you can never reproduce except by copying the signature from the original binary into your rebuild as a last step. But without this step and a different signature the app is expected to behave differently in many scenarios.)

Hermetic build environments that can detect changes as soon as
they're introduced during assembly

An option that should work until such environments are available would
be to compare the two build trees after a build. Those will have files
that aren't copied into the build artefacts, but the comparison could
be restricted to files that typically end up in the build artefacts.
That should help narrow down the source of non-determinism.

practical challenges implementing fail-fast hermetic builds

Essentially this would mean instrumenting all the tools used during a
build to record data and related metadata and record the chain of
transformation connecting the source files to the build artefacts.
The program receiving the instrumentation would then terminate the
build when it receives data different to a previous build.
That would have a lot of false positives though, since input that is
non-deterministic might not get represented in the build artefacts.
The build tracing feature would be useful for other situations too.
I think that I have seen a paper about a build tracing tool, but that
used ptrace rather than build instrumentation within tools and I
haven't been able to track down the paper.
--
bye,
pabs
https://bonedaddy.net/pabs3/

While I understand the desire for reproducible builds, in case such as Java where timestamps are introduced in to the zip-file archives (.jar, .war, and .ear files for those not familiar with Java), blasting the timestamps so they are all set deterministically set actually can cause useful information to be lost.
Case in point: Soon after Oracle acquired Sun Microsystems, pretty much every one of Oracle's patch release notes for Java (including some of their corresponding CVE descriptions) were of the intentionally vague form of "multiple unspecified vulnerabilities were patched" or some such BS). My management would ask me, "Would you please analyze the patches and tell us if there's anything we urgently need to patch?" (This was way before SCA tools BTW.) So I would extract all the .class files from (typically) the rt.jar and look at the modification timestamps to see which had been updated since the last patch release we were using. Then I'd de-compile those .class files and do the same for the .class files from corresponding jar from the previous patch release and then finally diff the two versions to see what Oracle had actually fixed. (Don't miss that work at all!) However, had those timestamps all been identical because of deterministic reproducible builds, it would have made that task take a hundred fold times or so longer.
So while there are times when deterministic, reproducible builds might be useful (they never will be unless people decide to verify all of that in their CI/CD pipelines, which I think most companies will be reluctant to do because of the build time resource commitment involved), IMO, for most cases, it brings very little added value.
Just my $.02.

... blasting the timestamps so they are all set deterministically set actually can cause useful information to be lost.

Having reproducible builds does not preclude incremental updates to Java archives. It's just that the dates of the old and new class files would be meaningful, such as their separate release dates. OpenJDK builds don't use such incremental updates anymore, but they could, and they could do so in a reproducible manner, allowing your detective work to go on as before.
Reproducible builds is about blasting away all the useless, meaningless differences: the timestamps of files created during the build, the unsorted order of files in their directories, or the random build paths used in a transient container. When the useless differences are removed, the meaningful differences can be found.

.. IMO, for most cases, it brings very little added value.

Oh, but its value to OpenJDK is already apparent, even though its build has been reproducible only since May. For just one example, this old Javadoc bug, only tangentially related to reproducible builds, would have been impossible to find, and its fix impossible to verify, without the easy ability to create bit-for-bit identical builds.

While I understand the desire for reproducible builds, in case such as Java where timestamps are introduced in to the zip-file archives (.jar, .war, and .ear files for those not familiar with Java), blasting the timestamps so they are all set deterministically set actually can cause useful information to be lost.
Case in point: Soon after Oracle acquired Sun Microsystems, pretty much every one of Oracle's patch release notes for Java (including some of their corresponding CVE descriptions) were of the intentionally vague form of "multiple unspecified vulnerabilities were patched" or some such BS). My management would ask me, "Would you please analyze the patches and tell us if there's anything we urgently need to patch?" (This was way before SCA tools BTW.) So I would extract all the .class files from (typically) the rt.jar and look at the modification timestamps to see which had been updated since the last patch release we were using. Then I'd de-compile those .class files and do the same for the .class files from corresponding jar from the previous patch release and then finally diff the two versions to see what Oracle had actually fixed. (Don't miss that work at all!) However, had those timestamps all been identical because of deterministic reproducible builds, it would have made that task take a hundred fold times or so longer.

If the timestamps are not deterministic they could very well be entirely arbitrary; you might end up with timestamps of whatever checkout the build of those class files happened to be performed on, whatever timestamp the developer happened to use at the time, whatever wonky clock was used, which would actually prevent you from being able to compare the timestamps in the way you actually described...
Clamping the timestamps to the last source change or some other meaningful timestamp will more reliably get you the feature you described, presuming the other files actually retain meaningful timestamps (last modification in VCS, for example, rather than whatever happened to be the on-disk time), and prevents files generated during the build from needlessly differing. And if they don't preserve meaningful timestamps, then you're no worse off that you were.
No need to blindly reset them if the process otherwise maintains meaningful timestamps; embedding the current clock time will nearly always require a maximally detailed process of comparison.

So while there are times when deterministic, reproducible builds might be useful (they never will be unless people decide to verify all of that in their CI/CD pipelines, which I think most companies will be reluctant to do because of the build time resource commitment involved), IMO, for most cases, it brings very little added value.

Nothing is useful unless people actually try to do it, true.
If we are talking about a best practice gold standard, well, let us not set the sights too low either. Recognizing that some things are harder and take more effort, and demonstrating that "this project follows all known best practices" vs. "this project follows many best practices" vs. "this project follows some best practices" should be reflected in the levels.

Just chiming in here to discourage any relaxation of the gold standard.  the gold standard should be clear: bit-for-bit identical reproducibility.  Please do not carve out subtle exceptions for variable timestamps.
For a project that distributes only source code artifacts, i still think it's worth asking during the review whether generated artifact used by the end user can be built reproducibly.  Obviously, we don't want to require source-only software projects to distribute binaries, but presumably the developers do actually have some practice in building some user-facing artifacts.  Such a project should be able to concisely describe a particular toolchain and set of compilation/configuration options and dependencies that are known to provide a reproducible build that covers a substantial portion of the codebase.


Image uploading. "The location field is required"

Hello,
It seems like image uploading has stopped working.
Whenever I try to save an image I get the following message:
"The location field is required"
It used to work properly in the past.
Do you know what might be the issue?
Cheers!

I have the same issue, actually I'm new on quarx and images was one of the main feayures I was looking for.

What version are you guys running? This was an issue that occurred recently but I thought was fixed recently. Any extra information you guys can provide would be appreciated. Thanks.

The version I am using is the last one ( v2.3.26 ) via composer.

Hey guys I just found this in my working copy, fix coming soon. Sorry about this.

@mlantz I just updated to to the JS fix (it worked, thanks!), but when I go to the "images" tab I'm getting 404s on the images I uploaded, and when I go to the posts tab and look for the file I uploaded under "Files" it gives me the "You haven't uploaded any files yet" message.
It looks like the files are stored under storage\app\files and images are stored under storage/app/public/images yet in the images tab it's trying to find files under storage/images

Hello, I also updated to the last version and I get the following errors on every page load
Refused to execute script from 'https://linkdeli2.inlinkz.org/quarx/asset/ZHJvcHpvbmUvZHJvcHpvbmUuanM-/YXBwbGljYXRpb24vamF2YXNjcmlwdA--' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
Refused to execute script from 'https://linkdeli2.inlinkz.org/quarx/asset/ZHJvcHpvbmUvZHJvcHpvbmUuanM-/YXBwbGljYXRpb24vamF2YXNjcmlwdA--' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
And finally a js error (which seemingly breaks the dropzone.js functionality)
Uncaught ReferenceError: _appTimeZone is not defined

@johnmans do you have something like APP_TIMEZONE=America/New_York in your .env file?

@rossity no, I tried adding/removing it but nothing changed

okay, I fixed the images displaying incorrectly. since it was a fresh L5 installation I hadn't run php artisan storage:link yet. All is well now!

Hello, I also updated to the last version and again get the "The location field is required", I cleaned the config cache php artisan config:cache then the suggested php artisan storage:link as I think I forgot to use it in the prod environment.
Now it's working fine.

Hey @rossity @johnmans @ChristianOrrala  et al,
I'm happy to resolve things. I'm going to close this issue, if there are other issues or you feel like things are missing in the docs, please let me know and I'll do updates accordingly. Thanks for your input. :)


Feature: Tests for http, https & ssh remotes

As mentioned in #18 :

This PR introduces support for ssh remotes by parsing the URLs into https,
The Repo class has been extended with 3 private methods: for obtaining remote URL, for parsing & validation and for ssh-to-https conversion (these functionalities should be available for all kinds of Repo instances),
The pytest fixture piepline now includes another parameter called remote_url which is passed to the factory method.

It was tested both by running testes manually and by usage in my Gitea instance.

Could you test out the latest develop branch? If that works for you we can close this PR.

As far as I can see, you have already implemented a feature to parse & handle ssh remotes through RemoteInfo class. I think your implementation based on string manipulation is more cleaner and readable than my regex one-liner.  However, you haven't implement tests for that, so I decided to integrate our approaches.
Somethings to consider:

In my eyes the RemoteInfo class looks like a member field dedicated for Repo class. In PR you will find changes to incorporate this idea.
The current naming convention of all these remotes variables gave me many headaches.  I suggest that some names should be more verbose.
The test suite doc_examples forced me to add an additional env variable (JAYPORECI_DOCS_EXAMPLES_TEST_MODE) dedicated solely to mocking the remote url in the main code.
In remotes/git.py I don't really understand why we need to duplicate information about branch and sha when we can (and we do) access it through repo. Something must be simplified, but in this moment I have no foggiest idea what it could be.

return cls(
            repo=repo,
            branch=repo.branch,
            sha=repo.sha,
        )

I have tested the changes on my Ubuntu 22.04 setup. The unit tests gave me all greens inside container.

I'll try and answer some of the queries:

RemoteInfo can indeed be absorbed into the Repo class but I didn't want to do it for two reasons:

Use cases might arise where the remote parsing can depend on what the publishing platform needs. For example some platform may only need the names of the repos etc.
I haven't yet done a lot of research on what kinds of use cases can come up while dealing with a single local and multiple remotes. Each remote platform can have it's own requirements and so I leave that decision to the person implementing the Remote class instead of absorbing that logic into the Repo class. If you notice; the RemoteInfo is only used in the Remote implementations instead of the Repo implementation. This is because the local git can be independent of the requirements of the place you want to publish your reports.

I agree about the naming conventions :D If there are better names that you can suggest I'm happy to use those. One conflict I want to fix is to start calling Gitea and Github as Platform instead of Remote. Then a Repo can have Remote information and can generate a Report which can be published on a Platform. However I'm still looking for other ways to name things since what makes sense in my head often does not make sense to others.
I didn't understand this part. If you need to mock remotes you can add them to the subprocess mock file? I'm surprised this did not fail in the CI itself. :thinking:  I'll look into this more when I work on this project again.
The duplication is there since the local repo can have certain branch names and the push can be done to a separate branch. For example a local feature-1 branch can be pushed to gitea with feature-1-myusername branch naming and to github with feature-1-archive naming. To support the case when CI needs to push this same branch to two separate upstreams with different names we do the duplication and don't automatically tie it up with whatever is the local remote/branch/sha.


RNG-76: Added primitive long constructor to SplitMix64

Coverage increased (+0.001%) to 97.956% when pulling 7285198b503c943c13d65d581bd3c3bc91b999b4 on aherbert:improvement-RNG-76 into cf2ba480595df791b7103d0bf75f261ddfa098b4 on apache:master.


[chip dv] Do not use cfg.clk_rst_vif.wait_clks() to wait for clock cycles

We need to replace the cfg.clk_rst_if.wait_clks() invocations in our test sequences with the appropriate clk / rst monitor in chip_if  for example, cfg.chip_vif.sys_clk_rst_if.wait_clks().
The reason for this is explained in this commit: https://github.com/lowRISC/opentitan/pull/14917/commits/bb2bb8abf3cefcb5bb0b25680b6c74051809e5cb
Previously, the wait_clks on this would wait on the external clock source, which was unsed in most tests, so it was incorrect all along. As of the commit above, the clock port of this interface is unconnected. The clock remains active to prevent breakages.

@weicaiyang, FYI.

SGTM

this is probably something that can't be deferred to M3 right? It sounds like if we don't fix this we might see random errors

AFAICT, there have not been any breakages related to this yet. Maybe we can defer to M3 if tests are largely passing. Its just that the DV sequences are waiting on clock events using a clock that has nothing to do with the chip.

that's kind of surprising there are no failures... alright, maybe let's defer like you said and see if anything catches fire hehe.

most of the wait_clk just wants to add some delays. How big the delay is may not really matter.
For things we really care, we should make it wait for an event.

wait but i thought the issue was that the "clk" we're sitting on may not always be there, so if we wait on that clock, things might just stall?

wait but i thought the issue was that the "clk" we're sitting on may not always be there, so if we wait on that clock, things might just stall?

cfg.clk_rst_if is a TB clock, which is always on but not used by DUT. I think Sri's point is to replace it with an actually design clock like sys_clk.

ah sounds good, i think i misunderstood it to mean the clock was not always on.


On GKE mounting volumes should no longer be required for GPUs.

GKE uses device plugins so we should no longer need to configure the TfJob
controller to mount files from the host.

So we can remove entries from the config map.

This change is

/test all


Non-deterministic behaviour, possibly macro-related

Rustfmt 0.6. In a crate I'm working on, I have a single (known) syntax error.
Running rustfmt --write-mode=diff src/lib.rs, it only picks up the error about 1/2 the time (the other 1/2 it reports no errors).
It seems to be due to an intermediate mod.rs, with contents (comment out the macro, and the bug disappears):
pub mod beta;

// This seems to be responsible.
random_macro!(pub trait One: Two);

See https://github.com/BenjaminGill-Metaswitch/rustfmt-bug-report for my minimum repro of this behaviour.

Huh, the first non-determinism error, afaik.

The non-determinism is because we list the files in a HashMap, so the order depends on the random seed. The bug is that once we encounter an error parsing a macro, for all subsequent macros we think we recovered from an error, and so don't format them either.
We could cancel errors by calling  context.parse_session.span_diagnostic.cancel(&mut e) instead of e.cancel(), but that's not a complete fix because I still can't see any way to cancel the recoverable errors. So it looks like we need to create a new parse session for macros?

cc @jseyfried - an interesting effect of the macro parsing/error stuff here.

I'm also seeing nondeterminism when I try to cargo fmt on a project that otherwise builds just fine: https://github.com/portier/portier-broker/pull/26
What's especially fun is that it'll sometimes get into cycles where rustfmt will make a change, and then a few runs later, will make the inverse of that change. So it formats and then unformats itself.

+1, we use rustup run stable cargo fmt -- --write-mode=diff in CircleCI and are being hit by this non-determinism.

I think #1393 is fine as a way to make rustfmt usable at least, but it still didn't fix the bug that caused the non-deterministic order to matter, which is that we don't handle errors in macro parsing correctly.

@philipc so the non-determinacy is fixed, but we don't format macros which we could? IIUC, this only manifests if there is a syntax error in a macro?

@nrc yes


Use Carbon Metrics in API Manager

We need to use Carbon Metrics and add useful metrics in the WSO2 API Manager to understand runtime behavior.

Please make sure that we have an easy way to retrieve metrics data whenever we want.

We already using carbon metrices in API manager. Hence closing the issue,


改国内镜像源。适用中国国情

大家都懂的，不需要可以注释掉。

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


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add mingw build to AppVeyor

@russelltg I somehow managed to configure the AppVeyor script. Take a look (in master)


Show repository configuration in admin panel

Gogs version (or commit ref):  <IP_ADDRESS>3

Description
The /admin/config url shows many configuration options but is not showing repository configuration (ROOT, MAX_CREATION_LIMIT, ...)
It would be useful information to have there

Patch has pushed to fix this issue, please test on develop branch.


Update check-outdated-content.yaml

Describe your changes
This PR removes "./" from the directory path in check-outdated-content.yaml because it affects file reference URL creation.
(For example, https://github.com/cncf/glossary/blob/dev-ko/./content/ko/cloud-computing.md)
Related issue number or link (ex: resolves #issue-number)
#2387
Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

PTAL @jihoon-seo


Enhance UI related to range of action, condition and value

Description
The value of each parameter of an action or a condition and each value of the input device has a predefined valid range which is being displayed in the MultiFunctionNumericControl and the RangeSlide. When the range is too wide or doesn't have an obvious limit, the control will not be displayed properly e.g.

Possible Solution

Format the range of the value using the DecimalFormat. But how many decimal points should we allow?
Disable the RangeSlider and use the CustomConditionalExpressionControl when the range is greater than some specified threshold. Or should we remove the RangeSlider entirely and use the CustomConditionalExpressionControl exclusively?

TODO

[x] Validate all ranges in generic*.json

[x] Improve UI/UX of the CustomConditionalExpressionControl by pre-initialized some expressions after switching from the RangeSlider and align buttons in the control

The UI of the CustomConditionalExpressionControl has been fixed in 017b4da655f8536face64af670f3044220b262fd. 1798dbdfe2ce2a34df718975e584f3363b6f7e06 updates range of many indefinite values in the MultiFunctionNumericControl to infinity instead of 9.99E7. @jetstreamc We need to fix the RangeSlider before closing this issue.


Scroll to selected item

Is there anyway scroll to selected item after opening dropdown ?

That should be happening already, but with no animation. Is it not working for you, or would you just like to add animation to it?
If it's not working, which browser/version are you using?


Restrict permission on history file

Restricts access to the history file to the user who is running the
greenclip daemon (equivalent to chmod 600).

Can you add it in the runDaemon before the forever call in order to set the file permission only once at startup ?
I will add it during the weekend, if you don't know how

Okay. Moved it to runDaemon.

Thanks ! Will try to make a release tomorrow or if I can't during the weekend

Archlinux package updated

Thanks. Just updated from AUR. I noticed a small thing: greenclip -v still says it is v3.0 and not 3.1


Web3 integration (in progress)

Here is an initial take on web3 integration.
The claim flow is designed, but only Meta Mask authentication is working so far.
I'm putting it out there in case someone wants to contribute the actual contract integration 😊 Otherwise I'll see if I can get around to it perhaps next week.

Closing this. Please see new PR #44


how to use Stride option, i want to to Skip 1st 50% keys In --key space range

HO wot use Stride Option, I din,t know about this Option clearly,
Accurately i want to to skip 50% key in this key renege<PHONE_NUMBER>00000000:7fffffffffffffffff
i want to start  it after 50% keys

Search : Decimal to Hexadecimal converter

don use stride , use switch in you command
--share 2/2
this will start from after 50% of your keyspace

don use stride , use switch in you command
--share 2/2
this will start from after 50% of your keyspace

I don't understand the --share command. What exactly does this do?

Please Explain --share option
and please could you please tell me there are how many keys in this range<PHONE_NUMBER>00000000:7fffffffffffffffff.
and how we can calculate

-share
The function divides the range into parts and searches in the specified part. For example: 5/10 will divide by 10 and will search in 5

Got it, Thanks man


Signed transaction printing could crash

Signed transaction printing could crash

This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a temporary error. The following address(es) deferred:
<EMAIL_ADDRESS>Domain rtfs.hu has exceeded the max emails per hour (179/150 (119%)) allowed.  Message will be reattempted later
------- This is a copy of the message, including all the headers. ------
Received: from github-smtp2-ext3.iad.github.net ([<IP_ADDRESS>]:36990 helo=github-smtp2b-ext-cp1-prd.iad.github.net)
by cp5.ezit.hu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.88)
(envelope-from<EMAIL_ADDRESS>id 1csDbZ-001vg9-I9
for<EMAIL_ADDRESS>Sun, 26 Mar 2017 21:13:34 +0200
Date: Sun, 26 Mar 2017 12:12:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
s=pf2014; t=1490555522;
bh=vHED4ZVXlNwzsZzuMT3fM/R+1MUep96xY/DH7vnP040=;
h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
List-Archive:List-Post:List-Unsubscribe:From;
b=fZCKcUj1AQLPJ3YFlZ+U+dkgMd1BekMUvTqrMEMQwXZyDD3VWsZgSjaVXzWUkdJtC
faHn7mceehRM0ze51KkPCPSScSQ/shRFJb8678i2cWiWxhfQURgjCnI2U0E7OZjJ/D
yMrbjaF+kK06hqGsuN/HGWQ0e+GJn13RA9VQLqdY=
From: Martin Holst Swende<EMAIL_ADDRESS>Reply-To: ethereum/remix<EMAIL_ADDRESS>To: ethereum/remix<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>In-Reply-To<EMAIL_ADDRESS>References<EMAIL_ADDRESS>Subject: Re: [ethereum/remix] Signed transaction printing could crash (#242)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_58d81282b6d2e_e0f3fd0e6ae3c3c1925ac";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: holiman
X-GitHub-Recipient: axic
X-GitHub-Reason: subscribed
List-ID: ethereum/remix <remix.ethereum.github.com>
List-Archive: https://github.com/ethereum/remix
List-Post<EMAIL_ADDRESS>List-Unsubscribe<EMAIL_ADDRESS>https://github.com/notifications/unsubscribe/AABPdCR9HXqC9nCL80bQSBGUED4Pr1Suks5rpriCgaJpZM4Mphqg
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address<EMAIL_ADDRESS>----==_mimepart_58d81282b6d2e_e0f3fd0e6ae3c3c1925ac
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Closed #242.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ethereum/remix/issues/242#event-1015781908
----==_mimepart_58d81282b6d2e_e0f3fd0e6ae3c3c1925ac
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Closed #242.
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58d81282b6d2e_e0f3fd0e6ae3c3c1925ac--


fix(Tactic/Simps): Prevent simps from viewing field_1 as a prefix of field.

Related zulip thread: https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/Custom.20name.20for.20projection.20in.20.60structure.20extends.60

!bench

bors merge


Support onTypeRename

For language like HTML it would be cool to be able to rename a closing tag automatically if a user changes the name of an opening tag. To make this happen we propose a new message onTypeRename which is comparable to on type format.

@dbaeumer is is to support HTML mirror cursor but with standard LSP requests?
If it that, it means that LSP client should support mirror cursor, LSP should provide a client capability for onTypeRename .
I love this idea and I would like to use it for our XML Language Server..

Yes, that is the idea also we will not talk about multiple cursor. The idea is to have ranges that must be kept in sync. The client can then decide on how to visualize this.

@dbaeumer Would love to adopt it 😉


update tests and README

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Details

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

Totals

Change from base Build<PHONE_NUMBER>8:
0.0%

Covered Lines:
127

Relevant Lines:
127

💛  - Coveralls


Integrate "direct color" / non-indexed 24bit color atop ncurses

first, a comment on nomenclature: these terms are subject to some disagreement. For the purpose of this bug, "TrueColor" will refer to "24-bit color making use of an 8-bit palette, which might be dynamic", "DirectColor" will refer to "24-bit color making use of 24-bit RGB specification", "256-indexed color" will be considered synonymous with "TrueColor", and "non-indexed" will be considered synonymous with "DirectColor". Note that these do not necessarily correspond to definitions in X11R6's "Visual types" (§2.5.5), nor do they necessarily correspond to NCURSES nor any terminal's terminology, nor do they necessarily correspond to any ISO 8613-6 (ITU T.416) definitions.
the story thus far....
NCURSES supports, on terminals which support it (inspect the output of tput colors), a 256-index palette composed of arbitrary 24-bit colors (8 bits each of R, G, and B). These colors can then be used as foregrounds and backgrounds in up to 32K colorpairs. NB: some terminals seem to indicate 64K colorpairs according to both tput pairs and COLOR_PAIRS, but will error out (#36) when init_extended_pair() is used with a pair above 32767 (sometimes it works fine; I've not yet figured this out; documentation seems to suggest a hard 32767 maximum based on the size of signed ints). These are known as "extended colors". This is all spelled out in the NCURSES FAQ, which is absolutely mandatory background reading. Note that the use of "color pairs" seems a pure NCURSESism, arising from terminals which did not allow the foreground and background to be specified distinctly:

Because some terminal types did not provide a way to set foreground and background colors independently, the concept of color pairs was introduced.

Reading the NCURSES documentation, it seems clear that backwards compatability, standards conformance, and wide hardware support (in terms of hardware diversity, not necessarily number of users) are major design goals. This is all noble. Furthermore (quoting again the NCURSES FAQ, 2019-11-14):

Using the ncurses 6 ABI, you have 256 colors, or 32767 pairs (the limit for a signed 16-bit number). That limit is good enough for realistic applications, which could not have that many character cells on a screen simultaneously (unless of course, using 1-pixel fonts to pretend to draw graphics, e.g., AA-lib). Since ncurses is used to draw text, that is not a valid issue.

and

That number of colors exceeds by a couple of orders of magnitude the ability of anyone to discern the differences and rely on those distinctions to aid them in viewing text.

Since outcurses seeks to be a blend of graphics and TUI, this doesn't really apply to us; these colors are a valid issue. I have furthermore demonstrated to my satisfaction that, for many images, it is impossible to achieve the visual quality of e.g. viu nor the TCT ("true color terminal") output of mpv without employing more than 256 simultaneous 24-bit colors. See #45 and #18 for more details.
Conclusion: NCURSES can and probably ought indeed stay above the fray until necessary escape sequences and semantics have been standardized and widely implemented. Unfortunately, we cannot achieve our goals, which include visibly appealing background graphics and animation effects in TUI programs on modern terminals optimizing for audience size rather than diversity of audience hardware. I hope this is an accurate and fair summation.
The NCURSES FAQ goes on about people with similar goals:

A small minority of terminals support an additional interpretation of SGR 38 and 48 alluded to in
ISO 8613-6 as direct colour...Bypassing the limits which can be derived from the terminal database (and veering off into the swamp of hard-coded behavior), the idle spectator might ask “why not add a special ad hoc interface to (somehow) just do it? The problem is that you cannot “just do it”—both ncurses and s-lang do optimization to address their legitimate users.

The "small minority" here once again seems to prioritize "terminal diversity" over "terminal instances", which is NCURSES's prerogative. The "legitimate users" of outcurses are primarily people making use of modern terminals on workstation and mobile UNIX machines, quite possibly remotely over SSH, desirous of -- let's admit it -- eye candy. Our goals are silly in the context of NCURSES, but not silly for us. Breaking necessary optimizations, however, is very undesirable.
With that said, direct color can certainly be run effectively over an SSH connection. The following screencap is taken from a terminal SSH'd into my office workstation, making the trip over my personal VPN. The terminal emulator (xfce4-terminal) is running at a size of 239x64, pretty big:

this works just fine without any noticeable lag (admittedly, my terminal emulator is eating rather more CPU than I'd like). But that's a screen of a single, non-occluded output plane. Our goal is to make such vivid graphics available in a PANELed context.
So our challenge becomes:

make some manner of 24-bit DirectColor available to our users through our API, implemented on the backend using escape codes, external to NCURSES, while
continuing to support the NCURSES functionality we know and love, particularly the Panels API, disrupting NCURSES as little as possible

For instance, what happens when we move_panel() an entirely NCURSES-drawn PANEL across the width of an underlying PANEL in which we have used escape codes directly? NCURSES couldn't know how to restore the uncovered text, since we didn't color it through NCURSES. We would be responsible for the redraw...but that doesn't honestly seem unworkable, so long as we do know how and what to repaint?
A bigger issue would involve getting our colors into the draw cycle. NCURSES draws onto its virtual screen, then (possibly following many virtual screen updates) updates the physical one. We rely on this for any kind of decent, flicker-free performance. Would we be able to inject our escape codes into the NCURSES drawing routine, or would we need apply them immediately after a doupdate()? Furthermore, would we need apply them wholly without NCURSES routines--i.e., would we need move the cursor with termios rather than the more pleasant NCURSES routines? Probably. This might admittedly be a major problem. Before launching any major effort, some experimentation will be necessary here.
I think there's a good chance we can get this done, but it's not guaranteed. I'd like to get Thomas E. Dickey to take a look at this writeup. It'll almost certainly piss him off a little, but his feedback would be invaluable. Of course, the 16 million color section of his FAQ concludes:

Without significant revision, there is nothing more to discuss.

  What we can do will really shape the "wow!" factor of our Thanksgiving demo.

I've privately sent Grandmaster Dickey a suitably sycophantic email, and hopefully might get some good feedback there.

I started down the road of shimming ncurses, and even considered some live-patching via eBPF. That's clearly madness, and I need get outside more. The more I think about it, the more this paragraph of @velartrill's essay rings true:

yes, ncurses supplies features like window-drawing and region invalidation (to avoid terminal flicker) that are much harder to implement yourself. no, you shouldn't have to implement it yourself. there should be a modern library to replace curses using the capabilities outlined here. but i swear to god developers have so completely forgotten how terminals work that i might be one of a handful of people left on earth who actually has the knowledge to, so they all just layer their bullshit on top of ncurses (which should never have survived the '90s) instead and it's ｍａｄｄｅｎｉｎｇ．

If I want to do this right, it may well be the case that I need write that library, and need just internalize that hard fucking fact, ugh.

for what it's worth, if you'd be interested in collaborating on a library to supply ncurses-like functionality with modern techniques i'd be happy to help out. the good news is that vast majority of terminals today, from xterm to Konsole to kitty to anything that uses libvte, have informally standardized on same escape codes for most things these days, and the ones that don't, like urxvt, simply lack support for direct color. you're correct that trying to interlace with ncurses is, shall we say, cursed.
we've been planning on adding some lightweight, modern terminal control features to libk so we could kill two birds with one stone and i could probably get a few more eyes on the problem at the very least. (libk is agpl but i'd be fine with dual-licensing any code my team contributes.)

for what it's worth, if you'd be interested in collaborating on a library to supply ncurses-like functionality with modern techniques i'd be happy to help out. the good news is that vast majority of terminals today, from xterm to Konsole to kitty to anything that uses libvte, have informally standardized on same escape codes for most things these days, and the ones that don't, like urxvt, simply lack support for direct color. you're correct that trying to interlace with ncurses is, shall we say, cursed.
we've been planning on adding some lightweight, modern terminal control features to libk so we could kill two birds with one stone and i could probably get a few more eyes on the problem at the very least. (libk is agpl but i'd be fine with dual-licensing any code my team contributes.)

for what it's worth, if you'd be interested in collaborating on a library to supply ncurses-like functionality with modern techniques i'd be happy to help out. the good news is that vast majority of terminals today, from xterm to Konsole to kitty to anything that uses libvte, have informally standardized on same escape codes for most things these days, and the ones that don't, like urxvt, simply lack support for direct color. you're correct that trying to interlace with ncurses is, shall we say, cursed.
we've been planning on adding some lightweight, modern terminal control features to libk so we could kill two birds with one stone and i could probably get a few more eyes on the problem at the very least. (libk is agpl but i'd be fine with dual-licensing any code my team contributes.)
nice to meet you, @velartrill ; I spent about an hour last night going through your site, and (strident leftism aside) suspect that we feel similarly about a lot of things :). hack on!

I wouldn't waste my time with ncurses. It doesn't do anything. Optimal cursor motion made sense in the days of 300 baud modem connections. But today it can often be harmful since bouncing around like that in your rendering algorithm means non-local memory access patterns that defeat caches and branch predictors. The rest of ncurses is just a second rate gui framework, that'd probably make microsofties gag if they ever saw it. The only things you need are ioctl() to pass the magnum to the kernel that gets you out of icanon, and then \e[y;xH to move the cursor. ANSI X3.64-1979 is nearly as universal as ASCII. Even old MS-DOS and Microsoft Windows support all the essential codes that are needed.

unforunately unless all your users are using kitty you do need some of the features ncurses supplies. in my essay that @dankamongmen linked there's a sample program at the bottom you can try running to see how bad flicker is when you re-render the entire screen at each update. region invalidation is the main thing a new library needs to be written for, tho there are also other small (but easy) things like using termios to extract the height and width of the terminal, without which you can't do much useful.
ideally in The Year of Our Lord Two Thousand And Nineteen we'd be moving away from VT emulators in the first place towards proper GUI terminals, but alas libtcod seems to be the best we're going to get in that space.

I spoke with Thomas E. Dickey, and conclude that there is no way to do this that doesn't require more effort, with a lesser chance of maintainable success, than building up something ab initio or, at the very least, sans curses.
Fair enough.

@velartrill Lexi, I got a chance to read your blog. Your rendering code works really well. Flicking was the fault of the stdio library. It was dispatching too many system calls, according to strace. Thankfully the C library provides a solution to the difficulties it introduces. open_memstream seems to be just what you need. Give this code a try: https://gist.github.com/jart/b9104dd959f2dd65ecdcb5ce69d332e6 I added a couple more things too, that I hope you'll enjoy, such as variable monospace widths.

@jart well i'll be damned. tested your code in a handful of terminals and you're absolutely right. even in xterm it behaves flawlessly. hell, it barely flickers even in a text-mode console. this is extremely good to know. (i think probably the best approach to this rather than using a memstream would be to allocate a buffer based on the current size of the terminal and reallocate on SIGWINCH if necessary, but that's armchair optimization; i haven't tested it myself.)

open_wmemstream in our case :D


Open: Define Workflow with CubeMX Generator

The current CubeMX workflow relies on the STM32CubeMX Launcher (which is a Windows only software).
It is also required to use a run command as shown below:
csolution run -s Premier.csolution.yaml -g STM32CubeMX
Current Problem: CubeMX is called multiple times, for each context. Specifying a context a the csolution command would solve the problem, but still creates some user confusion.  With the proposal below it should be possible to use csolution list generators to get a list of all existing scripts.
Proposal:
a) We should define a workflow that works on any supported operating system (Linux, Win, MacOS).  The STM32CubeMX Launcher might be replaced by a PATH environment variable setting that is created with CubeMX installation.
b) Perhaps the run command could be replaced by scripts (or batch files) that start the relevant generator.  This scripts could be generated using csolution convert.  Then only the script needs to be executed.
Open:
Open is still a workflow that would work for cloud based IDEs.  A potential solution is to display a README.md with manual instructions on how to run CubeMX.
Bug:
Note that the current workflow has also a problem with the directory for the generated files.
It uses .\generated\STM32L476RGTx
Instead of .\RTE\Device\STM32L476RGTx    <- this works in MDK
I guess there is some further testing with layers required as the location of the .\RTE directory may differ.
This is an project that shows this issue
Premier.zip

Regarding point (a) ==> this request has been shared with the CubeMX team.

Is the issue listed under "bug" already solved?

No, this bug is still present due to the  specified in the PDSC being overruled by the default "gendir" assumed by csolution.
I think https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/issues/207 needs to be extended in such a way that for backward compatibility we need to honor the  from the pack if it is explicitly specified.

closing this issue as it is covered somewhat by https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/issues/207 and #832.  The bugs itself have been addressed.


fix: issues from Mar-11-2023

fix #9
cc @icarusgk  @glopzel

Look like tests have failed due to latest commits sync from spanish-translation branch.

I think it's done with suggestions @icarusgk

Great! It'll be merged once mar-1 / mar-8 gets approved 🙌🏼


ummmmmm...this seems to need flash.....why?!?!?!?

please leave flash out of this app, which feels like a webview, not a native macOS app... :-/

Radiant is built on Safari webviews (built into OSX native apps), and Google has not built HTML5 support for Safari.  We're working on the next version of Radiant that uses embedded Chrome technologies that will allow for HTML5 support, but it's not ready yet (no estimates on completion yet as we all work on this in our free time, but I'm hoping to get it out soon).
tl;dr - Flash is necessary for now, but soon won't be.

I think this is a duplicate of #335?

Yep, closing as duplicate


let powershell core 6 join ubutu18.04

@jpsnover  ,   @joeyaiello  :
hi,
Tense time
Contact everyone,  do everything possible,   let powershell core 6 join ubutu18.04 too please !
contact him:  Craig Wilhite, Program Manager at Microsoft.
Let the powershell core 6 to the distribution’s official repository.
Help them solve the powershell compile issue in the distribution.
Do some tech.
look news
Microsoft and Canonical to Offer Enhanced VM Experiences for Ubuntu 18.04 LTS
http://news.softpedia.com/news/microsoft-and-canonical-to-offer-enhanced-vm-experiences-for-ubuntu-18-04-lts-520035.shtml

I find the link totally irrelevant because it is about HyperV. I could copy-paste into my Ubuntu VM already 5 years ago using VirtualBox.

Just want to confirm what this issue is asking for. Is it asking for publishing publishing to the ubuntu/18.04 package repo to allow the following package source to work for installing with sudo apt install powershell:

deb [arch=amd64] https://packages.microsoft.com/ubuntu/18.04/prod bionic main

If so, just wanted to add my note of interest here also. :+1:

Supporting 18.04 is certainly something we want.  Getting into a distro's official repo isn't likely going to happen (anytime soon at least) as it means the distro forks our code and maintains it.

Is it possible to do this:
Let Ubuntu's publisher Canonical place a powershell icon on the ubuntu desktop. The script behind this icon runs for the first time and can install powershell from ms repo.
Just like installing a copyright driver, let users activate themselves.
The same reasoning:
Provide a command in ubuntu server:
Enable-powershell

@SteveL-MSFT The repository I was referrencing is owned by Microsoft: https://packages.microsoft.com/
It is not owned by Canonical / Ubuntu. It is a separate repo that one configures their system to be able to install from.
Currently, powershell is available to install via earlier versions of Ubuntu (included in the Microsoft package repos up to version 17.04 of Ubuntu) but the 18.04 repo does not contain it. It does currently contain other packages that Microsoft has been maintaining, such as dotnet-runtime-2.1.0-preview2-26406-04 , aspnetcore-runtime-2.1.0-preview2-final , dotnet-host and aadlogin. `powershell isn't there. You can check which ones are currently in the Microsoft 18.04 repo here: https://packages.microsoft.com/ubuntu/18.04/prod/dists/bionic/main/binary-amd64/Packages

@ScriptAutomate yes, we should publish 18.04 build to Msft repo once we have a 18.04 build of PSCore6.

Having just installed 18.04 and very keen to get cracking on some PowerShell in Linux I was pretty deflated to find it's not available yet. Any ETA at all on that?

@ScriptAutomate
Let powershell 6.01 binary file, join the server version ubuntu 18.04 iso file, or join the command "Enable-powershell",my original purpose is.
This is a very important thing until now. Unfortunately, there are no leaders to promote.

I'm trying to install PowerShell Core on Ubuntu 18.04 and found that there is no package available. Please let me know when will it be officially supported.

@KloudEzy
This already has been discussed and should be in place for the next release of PowerShell Core (Preview.3) for Ubuntu 18.04.
Next update is around the corner!

PSCore6.1-Preview3 has 18.04 debs

Congratulations   ！！！


New rule to eliminate method_missing node access

node.foo.bar.baz is horrible because:

node.class != node['class'] and cannot be fixed
if you use node.foo and we add a Chef::Node#foo (or Chef::Node::Attribute#foo or Chef::Node::VividMash#foo, etc, etc) we'll hose you on a minor update
https://tickets.opscode.com/browse/CHEF-3799

Relates to FC019.  Also likely relates to #128

Relates to FC039, at first I thought we could turn off FC039 if we did this, but the problem is that if you use node.keys we can't throw the new warning rule because that's a perfectly valid method, so its still legit that node['keys'] is a bad chef attribute to use because of the confusion.


[Refactor][config-ui] merge board and project in create-blueprint.jsx

What and why to refactor
https://github.com/apache/incubator-devlake/blob/7b0199a6d8557d4f18b73200d619a96d10df0163/config-ui/src/components/blueprints/create-workflow/DataTransformations.jsx#L66-L73
board and project have the same logic, and the same usage. So we need to merge them into one var.
Similarly, I can deal with configuredProject and configuredBoard, activeProject and activeBoard in the same way.
Describe the solution you'd like
merge board and project into connectionScope

@likyh The Active/Configured Board and Project Entity state vars should be consolidated to either a) [configuredRecord, setConfiguredRecord] or b) [configuredEntity, setConfiguredEntity] or c) Some naming group better than a) or b)
By design it's state would be an Instance of any one of the following Data Models that represents a "Board" or "Project" or "Job" or some other future Entity to be treated as the main scope entity.

GitlabProject
GitHubProject
JiraBoard
JenkinsJob
BitbucketProject (Future example )
AzureJob  (Future example )
....

Entity ID can easily be obtained by the Model's Accessory method (gitlabProject.getEntityId()), since all models will have the base traits required for these model instances.
gitlabProject.getEntityId()   // "91837121231"

githubProject.getEntityId() // "merico-dev/lake"

Variant can be used to control business and logic flow based on the varying concept types so UI features can tailored to the differing project concepts.
gitlabProject.get('variant')   // "project"
gitlabProject.variant // "project"

jiraBoard.get('variant')   // "board"
jiraBoard.variant // "board"

jenkinsJob.get('variant')   // "job"
jenkinsJob.variant // "job"


Apache CXF client set custom ExecutorService

Apache client does not allow to specify custom ExecutorService(in our case OpenTracing-aware), therefore when simultaneously invoking multiple async requests parent is not correctly inferred.

Closing, CXF filters are executed in the same thread so linking with a parent works as expected.

however async response filter is executed in a different thread so it cannot close scopes!


add guidance on adding files and a dataset script

There are various times when you may want to upload files to the hub but have some more control over how the dataset is loaded via a dataset loading script. This can be relevant:

when the original host may prefer not to have the additional traffic from downloads
the original data is in a format that is not amenable to streaming/computational access or is very slow to process/load
the dataset contains complex configuration options
??

When the contributor decides to remove a specific instance from the data
Some instances in the dataset may have different license than others, e.g. one instance may be in public domain and allowed to use for commercial project, another one isn't


<system|char|{> breaks token

We love this solution, we have templates we are using to generate some basic JSON messages, however when we use a system char of { it breaks the rest of the token system.
<system|char|{> "status_code": "{statuscode}",  <system|char|}>
Results in
{ "status_code": "{statuscode}", <system|char|}>
Removing the first line and all is good.
Any ideas on a fix for this?

Related to #6

Thanks for coming back to me so quickly, we just using the library.

We've done a hack to work around it.  We know it's not a good solution, but it will work for our situation.  Assume it might not wont work in <iff| statements etc

We've done a hack to work around it in our copy of the source but dont think it's good enough to submit a pull request.  It will work for our requirements

We've done a hack to work around it in our copy of the source but dont think it's good enough to submit a pull request.  It will work for our requirements

Thanks! Good idea, but I agree with what you say, so this is "a good start" for my fixing this problem.

Fixed this problem.
I worked a while about this issue - and basically your idea was the best solution.
Closing for now - reopen if this is not good enough!

Docs: https://jonasr.app/xrm-tokens/#system

Awsome, thank you!


FEATURE: Neotree Rendering Causes Cursor Flickering; Synchronous Rendering Desired

Did you check the docs?

[X] I have read all the docs.

Is your feature request related to a problem? Please describe.
I have a keybinding set up as follows:
nmap('_', '<cmd>Neotree source=filesystem reveal=true position=current <CR>', 'Open neotree')

When I trigger this keybind on the currently focused buffer to open Neotree, I've noticed that the cursor's position flickers during the rendering process.
I'm suggesting if it might be possible for the Neotree rendering to be executed synchronously. In essence, I'd prefer the system to wait until all the folders are loaded and only then display the content. While it might introduce a slight delay, I believe it's preferable to the current flickering which, to some users like myself, can be uncomfortable or even straining to the eyes.
To illustrate:
Current Behavior (when I use the above keybind):
https://github.com/nvim-neo-tree/neo-tree.nvim/assets/7958527/dbfcf8f1-4c13-4d8b-afe1-f5c633ffb33a
Desired Behavior (using fern as an example):
https://github.com/nvim-neo-tree/neo-tree.nvim/assets/7958527/343118c8-f8b7-4ab3-938b-7c55a1b5884f
(and the command for fern is this — :Fern . -reveal=% -wait
I truly appreciate all the hard work you've put into this project. It's fantastic! Thanks for taking the time to consider this suggestion.

Correct me if I'm wrong I believe you want this option?
https://github.com/nvim-neo-tree/neo-tree.nvim/blob/80dc74d081823649809f78370fa5b204aa9a853a/lua/neo-tree/defaults.lua#L400

@pysan3 hey! Sorry for the long reply. This flag works, but only at some situation.
This is when I open and neo-tree no need to "scroll" the buffer:
https://github.com/nvim-neo-tree/neo-tree.nvim/assets/7958527/091a7441-2508-4472-a76f-694875b058e2
And here is when tree list is long and neo-tree need to scroll to exact file:
https://github.com/nvim-neo-tree/neo-tree.nvim/assets/7958527/4f5d9f22-1842-42f7-ad63-cbca21ff257b
So, could neo-tree make scroll before actually showing the content? Otherwise it feels painful for me 🥲


Full Node Windows Support

I'm building an application that runs locally on Windows (& Mac & Linux) PCs and uses Base to communicate with other applications. I would like a "1-click" option to start a Base full node on these OS's, but Base seems to require Docker to run. This dependency makes it extremely difficult to programmatically deploy Base full nodes, because Docker Desktop on Windows requires the user to navigate through different splash screens, login, and the Docker service won't automatically start on boot. I have tried configuring Docker Desktop.exe in about every way their documentation specified, and it is still non-user friendly. There's always some UI pop-up or mandatory Docker login that can't be automated before the Docker service starts (especially on Windows)
I would like to request a native way for Base to install a full node on Windows and OSX (silently), without requiring the need for Docker. I can drop a Geth.exe binary and configure it locally, but I need some way to remove Docker from the equation.
Ideally, there would be some pre-compiled .EXE and .DMG that when run, would install ETH geth, Base geth, and start downloading the blockchain on startup, while exposing the RPC API on localhost. That binary should be able to take in a directory path to where the blockchain data is downloaded to - so users could configure the blockchain(s) to download to an external hard drive or network share.

Hi there! A contributor recently published these guides on how to run a Base node without using Docker -- for Windows, I believe you'll need to use the Windows Subsystem for Linux<EMAIL_ADDRESS><EMAIL_ADDRESS>It's pretty technical but it is possible. With regard to running a DMG/EXE, since there is no user interface and Base Nodes are command line applications, I think it if ultimately this is the goal (quick/easy setup) I would recommend a node provider: https://docs.base.org/tools/node-providers
Hope that helps! :)


Flex Component: Add gap prop

Add gap prop to Flex Component
Description
Use theme spaces to set the flex property gap on your Flex component.
Demo
Example on : https://design-system-7r256h8ex-strapijs.vercel.app/?path=/story/design-system-technical-components-flex--base
API
<Flex gap={2}>
  <IconButton label="Edit" icon={<Pencil />} />
  <IconButton label="Create" icon={<Plus />} />
  <IconButton label="Delete" icon={<Trash />} />
  <IconButton label="Publish" icon={<Play />} />
</Flex>

Discussion

Should gap also allow responsive properties just like the padding props in the Box component?

Thanks also for this PR. I really like it, but need to confirm gap is within our browser support matrix (not sure about IE11): https://caniuse.com/flexbox-gap

Thank you, flex gap would be great!
I wonder though if we couldn't use strapi-design-system/src/helpers/handleResponsiveValues.js helper to allow responsive values + possibility to custom column / row gap?

Our Grid component already does this, it allows:
gap={4}
gap={{ desktop: 5, tablet: 2, mobile: 1 }}
gap="10px 20px"

WDYT?

Thank you, flex gap would be great! I wonder though if we couldn't use strapi-design-system/src/helpers/handleResponsiveValues.js helper to allow responsive values + possibility to custom column / row gap?

Our Grid component already does this, it allows:
gap={4}
gap={{ desktop: 5, tablet: 2, mobile: 1 }}
gap="10px 20px"

WDYT?

I was thinking the same 😉☝🏼

Discussion
Should gap also allow responsive properties just like the padding props in the Box component?

Not sure why but I had to "Approve and run" for the tests to run.
Should be good now - just need to wait for the tests to pass!

@MattieBelt You'll need to update the storyshots.
cd packages/strapi-design-system
yarn test -u


May 2024 Endgame

05/27 Code freeze for the endgame
05/31 Endgame done
06/05 Expected release date (this may change)

Monday

[x] Check that all queries in this issue use the current milestone @benibenj
[x] Run OSS tool @benibenj
[x] Update links in the Endgame notebooks to point to new milestone @benibenj
[x] Code freeze at 10pm PT, PRs should no longer be accepted to ensure a green build
[x] Ensure we have a green build on all platforms at 10pm PT
[x] 🔖Ensure all closed feature-requests either have a verification-needed or on-testplan label
[x] Create test plan items following the template here by 11pm PT

[x] Remind the team that TPIs should be written so that anyone can test. If this is not feasible, then TPI authors should assign specific testers @benibenj

[x] Update your availability for testing here - https://tools.code.visualstudio.com/team-manifest team

[x] Update availability of testers in vacation (Check OOF section in the Internal Backlog Plan). Double check N/A testers. @benibenj
[x] Remind team that in the event of sickness or overload with TPIs, to inform the endgame champ ASAP so items can be reassigned

[x] Remind team to go through their fixed issues for the milestone and update repro steps for issues which require more detailed instructions.

Tuesday

[x] Test plan items assigned (using https://tools.code.visualstudio.com/test-plan-items)

Run the tool multiple times to balance load if test items come in later and assignments are already made
Assigned to you

[x] Test build starts at 7am CET
[x] Test plan ready by 8am CET
[x] Remind the team about the priorities

Tuesday should be dedicated exclusively to testing activities. Our goal is to ensure the completion of all Test Plan Items (TPIs) and subsequently proceed with the verification phase. Fixes or commits should be refrained from unless there are exceptional circumstances such as blocked TPIs or build-related issues. On Tuesday Redmond EOD, only blocked TPIs should remain open with a corresponding label blocked and status update comment in the issue.
Redmond members commence testing the TPIs authored by Zurich members, enabling them to address any feedback on the following day.

[x] 🔖Testing
[x] 🔖Verification needed
[x] 🔖Verification (If verification needed is finished)

Wednesday

[x] 🔖Testing

These remaining TPIs should be the ones that are currently blocked. Discuss during the standup and redistribute assignments based on the TPI owner and the test coverage. For instance, if a TPI is owned by a member from Zurich and has not undergone sufficient testing, it will be reassigned to one of the Zurich team members.

[x] Remind team members to triage issues found in testing and assign major issues that they intend to fix to the current milestone. Remind team to move out or close other open issues/PRs on the milestone that they do not intend to fix this milestone.
[x] 🔖Verification needed
[x] 🔖Verification
[x] Message team members as needed to add steps to verification-steps-needed issues @benibenj

Thursday

[x] Make sure the insider build is green @benibenj
[x] Confirm with team extension authors when to disable continuous insider builds (includes vscode.dev publishing). The default time is Thursday EOD (Redmond) @benibenj
[x] Fixing (self-assigned, milestone assigned)

Increased scrutiny sets in due to testing being completed. Fixes pose a much higher risk
Move open issues/PRs to the next month that can be deferred

[x] Emphasize to the team that we want to verify as many issues as we can before the branching time, and ping team members as needed to remind them to add steps to verification-steps-needed issues  @benibenj
[x] 🔖Verification needed
[x] 🔖Verification
[x] By Thursday EOD (Redmond), branch from main and release @Iramos15

[x] Disable the continuous release by toggling the continuous release button on the top-right corner of the Builds page
[x] Branch following repositories to release/<x.y>

[x] vscode
[x] vscode-distro
[x] vscode-dev

[x] Localization: Run Update VS Code Branch build with release/* as the VS Code Branch parameter (it's the default so you shouldn't have to change anything)
[x] Announce main is open for business and all issues on the current iteration are candidates and that the candidate release process is to be followed.
[x] Build and manually release Insider from release/<x.y> branch for Code
[x] Build and manually release Insider from release/<x.y> branch for vscode.dev (if there were vscode.dev candidates)
[x] Remind team extension authors to check if all release branch changes have been published to users. If not, they need to build and manually release a new prerelease version of their extension. @benibenj

[x] Build but don't release a stable build from release/<x.y> branch to ensure stable build is green @benibenj
[x] Bump up the version in package.json on main - @benibenj
[x] Create next milestone on microsoft/vscode repo and ensure that it has a due date. The created milestone and its due date will be automatically synced across our repos. @benibenj

Friday

[x] Only candidate issues are open and assigned to 🔖milestone
[x] All issues 🔖verified
[x] All open PRs on the milestone 🔖merged or deferred
[x] candidate fixes should be made for major bugs only - to be discussed in stand-up meeting and approved
[x] Endgame champion / authors of candidate PRs should find testers to test merged candidates. VS Code candidates should be tested on newly released Insiders.
Satellite modules/npm packages ready, version updated, smoke tested

[x] yo generator @aeschli
[x] js-debug @connor4312
[x] Debug Adapter Protocol @connor4312
[x] vscode-debugadapter-node @connor4312
[x] vscode-test-web @aeschli

[x] All release notes updated

release notes are collected in a file named _v<Major>_<Minor>.md_ in this repo directory
Release notes screen recording guidance: https://microsoft-my.sharepoint.com/:p:/p/buhollan/Ecg_j89jzlVGtfqWGy7SQBEB_OsuLPZ65jjKRVlo_OdlgA

[x] Acknowledge third-party pull requests in release notes. @benibenj
[x] Acknowledge issue trackers from the community @chrmarti
When done fixing/verifying and there are changes since last build at the end of day PT

[ ] Build and manually release Insider from release/<x.y> for Code @Iramos15
[ ] Build and manually release Insider from release/<x.y> for vscode.dev (if there were vscode.dev candidates) @Iramos15

Friday/Monday

[ ] Polish release notes redmond
[x] Schedule an endgame restrospective with with @benibenj, endgame buddy, and next for next week. Retrospective template
[x] Decide whether a Patch Tuesday release will happen:

Check the internal iteration plan for scheduled security issues (MSRCs) to determine if a Patch Tuesday release is needed.
If no Patch Tuesday release is planned, use the Patch Tuesday E-Mail Template to let the Updates team<EMAIL_ADDRESS>know of that fact. Please cc Monacotools on this email as the client patching team has asked us to do so. @benibenj
Otherwise, if a Patch Tuesday release is necessary, start off a Patch Tuesday Release plan @benibenj

[ ] Remind the team: if they are going to be OOF for more than five days during the next iteration, assign someone to look out for critical issues in their feature areas and fix them if necessary. This helps with bug identification and fixing for recovery releases. @Iramos15

Monday - Wednesday

[ ] 🔖milestone issues
[ ] 🔖candidate issues
[ ] Polish release notes redmond
[ ] Cherry-pick hand-picked and reviewed changes to release/<x.y>, and close open candidate issues that have already been merged to the release branch. @Iramos15
[ ] Build Insider from release/<x.y> (roughly on a daily basis) @Iramos15
[ ] Manually release Insider @Iramos15
[ ] Endgame champion / authors of candidate PRs should find testers to test merged candidates. VS Code candidates should be tested on newly released Insiders. team
[ ] Build but don't release stable for all platforms as new candidate issues come in @Iramos15
[ ] Documentation updated
[ ] Run scripts/test-documentation.sh|bat after compiling the vscode repo, and fix any issues regarding new undocumented colors. Changes made to the vscode-docs repository must be merged to the main branch of that repository for the script to acknowledge them. False positives within the color section in vscode-known-variables.json can be moved under the others section of that file. @Iramos15
[ ] Coordinate the official release timing with team and more specifically, team extension authors (ex: Jupyter and Copilot rely on VS Code release) @Iramos15

Note: The Insiders build needs to be in the wild for 24 hours before we can enter the last phase of the endgame, though the sanity testing step alone can happen earlier if there are no new candidates. @Iramos15

Wednesday/Thursday - Expected release day (this may change)

[ ] Build stable for all platforms @Iramos15
[ ] Build but don't release an insider build based on main for all platforms @Iramos15
[ ] Sanity Testing

[ ] Windows 64 bit owner

[ ] System Installer
[ ] User Installer
[ ] Archive
[ ] Server
[ ] CLI

[ ] Windows ARM64 owner

[ ] System Installer
[ ] User Installer
[ ] Archive
[ ] CLI

[ ] macOS Intel owner

[ ] Archive
[ ] Universal Archive
[ ] Server
[ ] CLI

[ ] macOS ARM64 owner

[ ] Archive
[ ] Universal Archive
[ ] Server
[ ] CLI

[ ] Linux x64 owner

[ ] Archive
[ ] DEB
[ ] RPM
[ ] Snap

[ ] Linux Server owner (can be tested from any OS with Docker)

[ ] x64
[ ] ARM32
[ ] ARM64
[ ] x64 Alpine
[ ] ARM64 Alpine

[ ] Linux CLI owner (can be tested from any OS with Docker)

[ ] x64
[ ] ARM32
[ ] ARM64
[ ] x64 Alpine
[ ] ARM64 Alpine

[ ] Publish website @ntrogh @Iramos15
[ ] Release stable from builds page @Iramos15
[ ] Trigger the vscode.dev Deploy pipeline for release/x.y for the prod deployment target. Note that there are four deploy approvals needed - one for overall and one per each of the three service regions @Iramos15

[ ] Request approval from another team member at the necessary step to deploy the vscode.dev build. @Iramos15

[ ] Create an official release @Iramos15

[ ] Create a tag (make sure you pull the release branch first): git tag <x.y.z>
[ ] Push the tag: git push origin <x.y.z>
[ ] Create a GitHub release: Open the GitHub tags, and click far right ... > Create Release. Use the correct title and description from our release notes. Also change the relative links for the key highlight list items to absolute links Example

[ ] Twitter announcement @chrisdias
[ ] Create and publish next release notes placeholder @ntrogh
[ ] Enable scheduled insider builds @Iramos15
[ ] Release insiders based on main @Iramos15
[ ] Publish @types/vscode @Iramos15
[ ] Close the milestone on GitHub @Iramos15

It's really cool that you guys make the planning and execution of vs code development this open and transparent for the community, thank you for that.
I was wondering if the outcome/results of tasks and goals defined in the Iteration Plan are also made public. Sometimes I see things that really interest me but don't get released and I'm always curious about what happened (generally stretch goals, exploration and investigations)

I was wondering if the outcome/results of tasks and goals defined in the Iteration Plan are also made public. Sometimes I see things that really interest me but don't get released and I'm always curious about what happened (generally stretch goals, exploration and investigations)

They should all have issues assigned to them that you can follow along and subscribe to. No further information besides what is in those issues is provided.

They should all have issues assigned to them that you can follow along and subscribe to

I see. Well, often they are assigned issues that are very old feature requests that generally don't get updated unless they are implemented, e.g:
💪 Deep folder settings https://github.com/microsoft/vscode/issues/32693 @sandy081
I'm looking forward for that one but I think it is unlikely that it will be implemented in this iteration. I would really appreciate some more info. The issue is from 2017.

Microsoft recently integrated CleatType Text Tuner support into Chrome/Chromium/Skia. This was released in Chromium 124. Since then, font rendering in Chrome has improved drastically on Windows (especially for small font sizes).
https://chromestatus.com/feature/6236420349100032
Is there a plan to integrate latest Chromium build or at least Chromium 124 in VSCode as well?


Add basic Cucumber features

Closes #13

Hey @n3wscott,
WDYT about this one? :)

LGTM!!
we will have to make a whole bunch of these.
Can you also add the interface that an sdk has to implement or add that implementation here?

@n3wscott thanks for merging! Time to update sdk-java & sdk-go PRs 🎉

Can you also add the interface that an sdk has to implement or add that implementation here?

There is no interface to implement, but the steps (via the framework)
See https://github.com/cloudevents/sdk-go/pull/474 for an example of such

I mean the contract that cucumber expects to add  these tests to an sdk


sup: remove

Motivation for this change
Abandoned by upstream, and has dependencies with quite some issues, it's about time we get rid of it.
ZHF: https://github.com/NixOS/nixpkgs/issues/68361
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @cstrahan @lovek323 @nicknovitski

Still needs to be dropped from pkgs/top-level/all-packages.nix:19646.

Thanks, I accidentally pushed this hunk to another branch.

Thanks.
Cherry-picked as 1fed83d3df4.


Add wait_for_completion parameter to resize&open&forcemerge APIs (#6228)

Description
Relates to #6228 .
The main changes of this PR are:

Add wait_for_completion query parameter to shrink/split/clone/open/forcemerge APIs, when the parameter is set to false, the API will return a task immediately and then run the long running operation in background, when the long running operation completes the result of the generated task will be stored into the .tasks index. The parameter wait_for_completion defaults to true,  so it will not impact the old behavior of the API which will block until the operation completes or timeout.  Additionally, except forcemerge API, a parameter named task_execution_timeout is added to shrink/split/clone/open APIs, that's because for these long running operations, we have to wait the shards of the index specified by users to be STARTED, but if the shards cannot be assigned then the generated task will not finish, so we must have a timeout parameter to control the task's max execution time, when the timeout expires, the task's result will be stored into the .tasks index. The task_execution_timeout parameter defaults to 1h.
For shrink/split/clone APIs, move some request validation in advance so that users can get validation errors immediately when they call these APIs with the parameter wait_for_completion setting to false, if we don't do so, users have to check the generated task's status by _tasks API and then they can see the validation errors.
Fix a bug found in shrink/split/clone API, the query parameter timeout and cluster_manager_timeout take no effect, that's because the value of the both parameters are not passed to TargetIndexRequest, so the value user specified are lost. Maybe it's hard to test both of the two parameters so we don't have this test case.
Add some unit tests and yaml rest tests for the changes.

Issues Resolved
#6228
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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

@andrross can you help to take to look at this PR?

Haven't dug into the PR yet, but it looks like there are some test failures that may be related (haven't seen them fail otherwise so I don't think they are flaky):
org.opensearch.smoketest.SmokeTestMultiNodeClientYamlTestSuiteIT.test {yaml=indices.stats/13_fields/Fielddata fields - pattern}
org.opensearch.smoketest.SmokeTestMultiNodeClientYamlTestSuiteIT.test {yaml=search.aggregation/160_extended_stats_metric/Basic test}

Codecov Report

Merging #6434 (eceb40f) into main (8bda365) will decrease coverage by 0.11%.
The diff coverage is 45.23%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##               main    #6434      +/-   ##
============================================
- Coverage     70.77%   70.66%   -0.11%
+ Complexity    59092    59075      -17
============================================
  Files          4802     4802
  Lines        282968   283034      +66
  Branches      40793    40800       +7
============================================
- Hits         200267   200014     -253
- Misses        66239    66590     +351
+ Partials      16462    16430      -32

Impacted Files
Coverage Δ

.../index/reindex/AbstractBaseReindexRestHandler.java
6.66% <ø> (+0.69%)
:arrow_up:

...on/admin/indices/forcemerge/ForceMergeRequest.java
46.34% <0.00%> (-3.66%)
:arrow_down:

...main/java/org/opensearch/rest/BaseRestHandler.java
73.07% <0.00%> (-7.21%)
:arrow_down:

...rest/action/admin/indices/RestOpenIndexAction.java
34.78% <0.00%> (-22.37%)
:arrow_down:

...est/action/admin/indices/RestForceMergeAction.java
64.70% <16.66%> (-26.97%)
:arrow_down:

...h/rest/action/admin/indices/RestResizeHandler.java
55.55% <16.66%> (-12.10%)
:arrow_down:

...rch/action/admin/indices/shrink/ResizeRequest.java
60.57% <57.14%> (+3.95%)
:arrow_up:

...ch/action/admin/indices/open/OpenIndexRequest.java
86.11% <60.00%> (+31.27%)
:arrow_up:

...n/admin/indices/forcemerge/ForceMergeResponse.java
90.47% <100.00%> (+4.76%)
:arrow_up:

...h/action/admin/indices/open/OpenIndexResponse.java
100.00% <100.00%> (ø)

... and 519 more

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

Haven't dug into the PR yet, but it looks like there are some test failures that may be related (haven't seen them fail otherwise so I don't think they are flaky):
org.opensearch.smoketest.SmokeTestMultiNodeClientYamlTestSuiteIT.test {yaml=indices.stats/13_fields/Fielddata fields - pattern}
org.opensearch.smoketest.SmokeTestMultiNodeClientYamlTestSuiteIT.test {yaml=search.aggregation/160_extended_stats_metric/Basic test}
org.opensearch.test.rest.ClientYamlTestSuiteIT.test {p0=indices.stats/10_index/Index - blank}

I've fixed these test failures yet, the reason of the failures is that .tasks index will be created automatically when the shrink or split index operation completes if the query parameter wait_for_completion is false, but in other yaml test cases the .tasks index maybe refreshed or searched unintentionally, this will introduce an unexpected warning this request accesses system indices: [.tasks] ... direct access to system indices will be prevented by default, and then cause the  test cases to fail. I've add some code to delete the .tasks index in the end of the shrink&split yaml test cases, currently all gradle checks have passed yet.

The security check fails, but it may not related to this PR.

@andrross I've fixed the test failures yet, could you help to review the code change?

The failed test
org.opensearch.cluster.routing.allocation.decider.DiskThresholdDeciderIT.testIndexCreateBlockIsRemovedWhenAnyNodesNotExceedHighWatermarkWithAutoReleaseEnabled is a flaky test and there is an issue opened.

@reta could you help to take a second look at this PR?

@andrross it seems that reta doesn't have much time to review this PR, could you help to have someone else to review this? We want to incorporate this PR into release 2.7 and some other functionality depends on this change, so it would be fine if we merge this PR in advance.


Align the exporter and the trigger name

Fix #903
Use 'application' as the trigger name consistently.
Since 'application' would be a too generic name for
the Exporter bean, use a BeanPostProcessor to install
the exporter in the MetricExporters bean.
(Capture  the option as part of #902)

LGTM. Maybe Spring Boot could accommodate "application" as a trigger key natively in the future (avoiding the BPP).

I believe this is a wrong approach for the problem. We have already agreed that each channel (boot and stream) would be independent of each other. They do after all, have different payloads.
Now, by reusing the includes property from boot, it means that they do have different payloads, but only one way to filter. So let's imagine the scenario where a user is using boot metrics, and it's used to receive one message per metric emission, and he subscribes to everything in the http subsystem. Along comes stream and start pushing integration metrics on it, and now, if the client of the metrics from stream does not care about http, it's receiving that data as well.
The best analogy I can make here is of a Table on a database, where you have two clients with different connections, but all the suddenly you only have one projection to rule both connections.

Now, by reusing the includes property from boot, it means that they do have different payloads, but only one way to filter.

This is doing exactly the opposite: spring.export.metrics.trigger.application is the namespace for properties that apply exclusively to ApplicationMetricsExporter. The one thing that the PR does is to make sure that the exporter is registered under the name application (and not a name derived from its), which means that properties such as delay-millis also apply to it.

My bad, I thought we were only allowing global setting for all exporters. Having our own configuration is what I was really worried about. Please forgive and forget what I said :D

Squashed and Merged as d6fe841


Correction for raw affiliation Northern Ontario School of Medicine, Lakehead University, Thunder Bay, Canada P7B 5E1.

Correction needed for raw affiliation Northern Ontario School of Medicine, Lakehead University, Thunder Bay, Canada P7B 5E1.
raw_affiliation_name: Northern Ontario School of Medicine, Lakehead University, Thunder Bay, Canada P7B 5E1.
new_rors: 05yb43k62;023p7mg82
previous_rors: 05yb43k62
works_examples: W2054936663
contact: b91c6d81fba528b887e864ed2c7b81d5:d30e5c6e @ ourresearch.org

This issue was accepted and ingested by the OpenAlex team on 2024-10-09. The new affiliations should be visible within the next 7 days.


Question: How to change the base url?

Version: Latest
I am using springfox to generate my api documentation. Everything is working and generating successfully.
However, I am using Akana to protect my API, which means I have a different base url than the one on my box. Is it possible to configure the base url?

@ALeonard9 You'd need to have Akana (sorry I haven't used it), send in the appropriate X-FORWARD-XXXXX headers to get it to translate correctly.

@dilipkrish Do you have an example header?


drawn backwards  ？？？？？

Hello, are the starting positions of shape_hm_gt and hm_gt drawn backwards (the opposite case of symmetry in the middle of the picture)? Because when I look at the original picture, I guess it's upside down

The original starting point of the picture is on the left, but the gt runs to the right.


Document "Mute/Unmute topic" mobile app feature

In the mobile app, topics can be muted/unmuted via the long-press menu. This menu can be accessed from the topic bar on any message, as well as the top bar in a topic narrow, and the list of topics for a stream.
We should document this feature on https://zulip.com/help/mute-a-topic.
Instructions for accessing the long-press menu should be added using a new macro in templates/zerver/help/include for reusability.
Related issues: #22144, #22147

Proposed approach for this issue: #22178

Potentially relevant discussion: https://github.com/zulip/zulip/pull/22158#discussion_r888418410

Duncan Keall is working on this issue.

@zulipbot claim


Presets props are sent to the API, which are not sent by the official UI.

While debugging my requests against the API and comparing it with the ones from the WebUI, I noticed something weird.
My first thought was that the presets files are outdated, but indeed they do match the ones I can export from the Web UI.
The following properties in red are part of the preset files, but the Web UI does not send them to the API, while this library does.

I don't know, if this affects the generation (because I seem to have other issues atm) or if the API ignores them, but I think we should make sure our requests matches them from the official Web UI.

These values are default values, they do not affect the generation because :

Their value put them in a "disabled" state (does nothing)
Their behavior should be disabled when they are not part of the preset by not being in the 'order' parameter.

One thing that could be done is filtering out parameters that are not part of enabled sampling methods (not in 'order'), which is what the website does.

If you're using Anime_v3 model, different default settings between the website and this repo are:

the website default uses k_euler sampler with scale 5
this repo uses k_euler_ancestral sampler with scale 11

This can affect the result, remember to set the sampler if needed.

All 3 models use different default configuration, the current default is more a holdover from v1 than anything. It feels awkward to change these default at each new version, considering any model can be used with an ImagePreset; rather I want people to customize their configuration (even more so there is no official settings preset in image gen).
One thing I could do, however, is make a factory function that would build the ImagePreset from the defaults of the chosen model, and remove the defaults.
"Explicit is better than implicit."

Zen of Python


Upgrade GitHub Actions

https://github.com/actions/checkout/releases
https://github.com/actions/setup-python/releases
https://github.com/codecov/codecov-action/releases

Cool, thanks!