[Pre-BEP] Computational Model Description

This issue is intended to host discussions on the Computational Model description specification, which is intended to become a BEP over the next few months.
If you would like to participate in this discussion, you can reply or subscribe to this issue on the right.
When working documents become available, they will be linked in this top post.

Just adding a link to the quick & dirty code implemented for this at Princeton: https://github.com/NeuroML/NeuroMLlite/commit/b171b91693c74dd48cfbfbc21d4ab9ebdaa67b99#diff-27e92ab9bacc4d0a6fc97ba5fe1c1187

Commentary on the Lee et al. paper is now posted as preprint: https://psyarxiv.com/q3rnx/

@poldrack Interested in getting involved. This issue has been on my to-do list for a long time now and was really glad when someone mentioned the preprint at the ReproNim training workshop.
@stewart-heitmann: you may like to participate of this initiative.

Thanks for the heads-up @pausz. I am not familar with NeuroML specifically but I am familiar with neural modelling in general.

Hi @stewart-heitmann, I was also not very familiar with the Brain Dynamics Toolbox. I'll install and try it out, as we're hoping to be able to interact more with the types of models it covers: https://github.com/NeuralEnsemble/Networks_SIG/issues/4

Including resources generated during the BIDS-computational Models here (provided by @effigies):

Summary document: https://docs.google.com/document/d/1hoLFzQYw-VqU5nuDjVz7NEOgJUGa4zmX1mA67CjM-UA

Some provisional BEP text (more notes from the meeting than a specific proposal): https://docs.google.com/document/d/1oaBWmkrUqH28oQb1PTO-rG_kuwNX9KqAoE9i5iDh1xw

Related: This BEP on computational models: #967


Rust new version

with async and wait.
Now wrappers/rust should be async-ified
ps: move tests/anoncreds_demos.rs	tests/demo.rs to wrappers/rust and rewrite, please

Please restart the CI run. The error message has nothing to do with this PR
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

@AxelNennker we decided to turn-off MacOS and iOS pipelines to unblock current PRs while Sovrin Foundation is working on the issue with the macos worker


_Variables.scss Compilation Error

Simply when i try to change the default color on my project the compiler throws this:
"argument $color of lighten($color, $amount) must be a color "
Even when i just compile the file without a change.

Did you compile materialize.scss? You should not directly compile _variables.scss.

the _variables.scss depends on _color.scss and _mixins.css You should include it first.
Generally, if you would like to create customized materialize build, you can create a scss file with context like materialize.scss and list only required things.
You can tune sass include path to override build in components files. Here is the sample for gulp build:
gulp.task('materialize.django.scss', () => {
  return gulp.src('./mycustom/materialize.scss')
    .pipe(sass({
      includePaths: ['./node_modules/', './mycustom/']
    }).on(
      'error', sass.logError
    ))
    .pipe(postcss([
      autoprefixer({
        browsers: supportedBrowsers
      })
    ]))
    .pipe(gulp.dest(
      './output/'
    ))
})

Here is how my sass files for this sample:
https://github.com/viewflow/django-material/blob/master/material/static/material/sass/materialize.scss
https://github.com/viewflow/django-material/blob/master/material/static/material/sass/_variables.scss

Closed due inactivity, feel free to reopen it if it is still necessary.


Hiding processes from other users and groups.

Add the following lines to /etc/sysctl.conf file:
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0

This will most likely break software that depends on dbus service. This will need to be heavily tested before adding this GhostBSD.

Creating an experimental security-enhanced ghostbsd-build (ghostbsd-se-build) repository is perhaps a good a way to separate concerns and study the effects of changes. We would not want to impact the current ghostbsd-build repository.

That can be done in a branch instead it is easier to maintain.

Those changes most likely will end up to ghostbsd/ghostbsd.

I agree. Creating a branch instead does make better sense.


[BUG] Prometheus Monitoring is showing "Page not found 404 Error" in cluster home

Rancher Server Setup

Rancher version: 2.7.1
Installation option (Docker install/Helm Chart): Helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE1

Proxy/Cert Details:

Information about the Cluster

Kubernetes version: 1.20.15
Cluster Type (Local/Downstream): Downstream

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider): Custom

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)

If custom, define the set of permissions: Admin

Describe the bug

Cluster home with Monitoring installed is showing "Page not found 404 Error".
To Reproduce

Installed Prometheus Monitoring app from Apps > Charts > Monitoring. After everything is installed, navigate to the Cluster home. Scroll to the bottom and the Cluster Metrics, Kubernetes Component Metrics and Etcd Metrics should now be displayed. However, it is showing "Page not found 404 Error".
Result
No Grafana graphs are shown, only "Page not found 404 Error".
Expected Result

The respective Grafana graphs should be displayed
Screenshots

Additional context

Did some digging on this with @mantis-toboggan-md and figured out that the requirement for the /k8s/clusters/local prefix has changed between Monitoring chart versions. This was related to some troubleshooting around the underlying proxy and nginx configuration, which has since been fixed.
In short:
For specific chart versions 100.2.0+up40.1.2 and 102.0.0+up40.1.2, links to Grafana should include the /k8s/clusters/local prefix
For any other chart version, including newer versions, links to Grafana should not include the /k8s/clusters/local prefix.
Both the link on Monitoring -> Grafana, and the embedded iframe views on the Cluster tab, should follow the same logic regarding the prefix. Right now these two locations appear to be using different rules to construct the URL, usually resulting in one or the other being broken for a given chart version.

Hello everyone, sharing my experience, it happens when for the "rancher-monitoring" App/Helm release (which is for 99% the kube-prometheus-stack), the Helm values:

global.cattle.clusterId
global.cattle.clusterName

are not set.
Those values are needed to build the Nginx rewrite rules correctly, to proxy the Grafana Kubernetes Service in the downstream clusters through the downstream cluster's API server proxy via the Rancher proxy.

@maxgio92  you are right. Update the helm option & redepoy all pods works like a charm.
For those you use fleet.yaml to deploy here is the value to put:
global:
cattle:
clusterId: global.fleet.clusterLabels.management.cattle.io/cluster-name
clusterName: global.fleet.clusterLabels.management.cattle.io/cluster-display-name


Feature/redbox 234 keep deleted file django reference

Context
After discussion with the wider product team about managing deleted documents, we decided to keep a reference to files in the Django database when the files were deleted from S3 and the core_api.
Changes proposed in this pull request
Now when a user chooses to delete an object, we delete the file from S3 rather than the whole Django object.
This also updates the UI with an interim version to show that the file is in a 'deleted' state.

Guidance to review
Run locally, including the database migrations (check nothing broken) - you might need to make reset-db before switching to a different branch. Try deleting a file and check how it displays - see if it deleted in minio.
Relevant links
https://technologyprogramme.atlassian.net/browse/REDBOX-234
Things to check

~[ ] I have added any new ENV vars in all deployed environments~
[x] I have tested any code added or changed
~[ ] I have run integration tests~

Probably worth merging main in again and running make format lint.


Updating Quote data model to allow for null Bid and Ask values.

I found that there were cases where the Bid and Ask may be null for certain securities. I included a test case that reflects this is the case. Let me know if you have any questions.

Hey guys, any chance you can take a look at this PR? It would be helpful for a project I am working on to get it into the main branch and nuget package.
Thanks,
Patrick

Hey Patrick, I'm sorry! We are running a little bit late. However, I will be pushing a new nuget package with your changes in a few minutes! Thanks for the changes!

No worries. Thanks for the response. I appreciate it.

NuGet Package 1.0.10 is now available with your changes. By the way, Henrique and I will review the other 2 pull requests this week as well! Thanks again!


Add dev and beta branches

It's not a good practice to push PRs directly to the main branch. We should consider adding at least two more permanent branches.
dev branch for pushing the PRs and beta for testing the PRs.
main should only receive updates from the beta branch.

#26


Default Theme font is not being applied correctly

How to reproduce

Create new project
Go to page with font
pop out into browser view

Describe the bug
When starting a new project, there is a discrepancy in what font is being applied. The Theme is set to use Inter yet it does not get applied to any text in the project only when the project is popped out in a browser window.
Expected behavior
In the global styles of the typography section fonts set here should be applied to the corresponding text styles
Operating System
macOS 13.5
Clutch Version
Desktop: 1.204.0-alpha.90b6c69e47 | Interface: v1.204.0
Other

This is related with Google fonts not being used by default as of now.


[BUG] [UI] review submit box is cut off

Gitea Version: 1.12.0+dev-142-g9b7737df2

Another issue with that box I noticed that small diffs (1 line), it will interfere with the page footer and extend below it. I think a proper fix is to use popper to position the box.

Closed by  #11252


PR for first comments from DTS

This PR deals with the JOSS review comments .

[ ] Update package name to be less general
[ ] Reorganise code to enable the user the easily select the background metric
[ ] Update metric.jl to be less messy
[ ] Clear up use of e.g. RelativisticDynamics.delta vs delta along with useful_functions.jl
[ ] Use GR convention to distinguish Levi-Civita tensor vs symbol
[ ] Update definition of Rtensor for less wasteful allocations
[ ] Update/remove schwarzchild_covariant_riemann function which is just a specialised version of riemann
[ ] Update the documentation in orbit.jl to refer to the correct parameters file
[ ] Rewrite constants so that only the $GM_{\odot}$ product is used, not $G$, $M$ separatley. Update definition of $c$ to be exact.
[ ] General updates to clarity and organisation of code
[ ] Update documentation/article to discuss SSCs more. Ensure any comments about SSCs are clarified to be either about SSCs generally, or for a particular SSC.
[ ] Discuss the choice to formulate as an ODE integration problem rather than action-angle.

@duetosymmetry Thanks again for all your input. I have addressed your comments as follows:

[ ] Update package name to be less general

It would be good to agree an alternative name before I implement the change. The subtitle of the article is "Relativistic Spin-Orbital Dynamics in Julia" which I think makes the application of the package more clear. Perhaps a rename to just RelativisticSpinOrbitalDynamics.jl? @dfm is there any issue on the JOSS side if I update the github repo name?

[ ] Reorganise code to enable the user the easily select the background metric
[ ] Update metric.jl to be less messy

The module metric.jl has been re-structured as follows.
Firstly, the metric_gAB functions have all been removed - these were only there previously to allow AD with respect to the metric during unit tests. Previously we were using Zygote.jl which requires pure functions (hence the metric_gAB) and avoidance of any array mutation We have now switched over to Enzyme.jl (which it looks like is now becoming the preferred package) and can operate directly on mutable arrays.
Secondly, all functions which are specific to the (Kerr) metric are now contained within metric.jl. For instance, the mapping from Keplerian orbital parameters to E,L,Q constants was originally in initial_conditions.jl - it has now been moved to metric.jl since it is a construction specific to Kerr. This makes it much easier to swap in/out alternative metrics in the future.

[ ] Clear up use of e.g. RelativisticDynamics.delta vs delta along with useful_functions.jl

We have cleaned this up to just use e.g. delta() throughout the src/ code.
The original idea of the useful_functions.jl module was to provide a module which housed functions that were either shared between other modules or whose purpose was slightly separate from the module from which they were called. For instance, the calculation of the Levi-civita tensor seems distinct from the explicit expressions for the ODEs, and one can easily imagine this function being used elsewhere. I have often seen utility function type modules like this in many codes.
However, this module has now been significantly paired back, with some functions moved only to the test/ area (e.g. kretschman scalar) and some (e.g. delta) moved into metric.jl since they are specific to Kerr. Some functions do remain in this module, for example calculating the Levi-civita tensor or the covariant spin tensor - since these functions serve a particular purpose but are more general and somewhat distinct from the modules that call them.
As I say, having a utility functions module is quite common and it provides an area to add any future general functions that may be shared between modules, but I don't feel particularly strongly about this point;  I am happy to remove and allocate the functions to the particular modules they are called from if preferred?

[ ] Use GR convention to distinguish Levi-Civita tensor vs symbol

This has now been updated in useful_functions.jl. We have two functions, levi_civita_symbol() and levi_civita_tensor()

[ ] Update definition of Rtensor for less wasteful allocations

This is a nice suggestion, and not one I had thought of before. However since the code is currently nowhere near being limited in speed or memory I personally don't feel it to be necessary at this time - would you agree? Whilst I agree that explicit allocations are wasteful, they are also conceptually straightforward and directly comparable with the standard form of the MPD equations. Such a decomposition is definitely, however, something that I will keep in mind for the future, especially w.r.t alternative number formats where scalings and allocations may become important.

[ ] Update/remove schwarzchild_covariant_riemann function which is just a specialised version of riemann

This was only present for testing that the Riemann tensor for Kerr correctly reduces to Schwarzchild. This has been removed from the main src/ code and brought into the unit tests.

[ ] Update the documentation in orbit.jl to refer to the correct parameters file.

This has been updated to the correct src/system_parameters.jl

[ ] Rewrite constants so that only the $GM_{\odot}$ product is used, not $G$, $M$ separatley. Update definition of $c$ to be exact.

This was a nice idea and the constants and definitions have now been updated accordingly.

[ ] General updates to clarity and organisation of code

Some updates to code organisation have already been discussed. In summary, the code has now been restructured as follows:

metric.jl now contains all metric-specific quantities
model.jl has been removed - the model struct is now defined in orbit.jl.
useful_functions.jl has been paired back

[ ] Update documentation/article to discuss SSCs more. Ensure any comments about SSCs are clarified to be either about SSCs generally, or for a particular SSC.

In the summary section of the article we now mention that the choice of SSC is equivalent to choosing the centre of mass and that we specifically take the TD condition for this work.
I am cautious about spending too much time in the article itself discussing choices and nuances of SSCs since it is quite involved and distracts from the main message. I have therefore relegated the discussion of this point to the docs page  and pointed readers to my go-to reference of Costa & Natário, 2015. I can of course expand more in the article itself if preferred.

[ ] Discuss the choice to formulate as an ODE integration problem rather than action-angle.

Formulation as an AA is interesting - thanks @duetosymmetry for bringing this up as an idea!
Ideally, looking long term I would like this package to be background independent. As you point out AA is only for a select few specific spacetimes. However, I think it could be worthwhile in the future exploring how to setup the code to use AA for those spacetimes where it is available, and so take advantage of long term precision.
On the other hand, with AA one is often primarily interested in exploring the fundamental frequencies of the system, rather than determining the evolution of position, spin, momentum etc. For pulsars, one is often interested in these quantities;  for instance the orientation of the spin axis will influence the received pulse, the momentum will influence the Doppler shift, etc.
I could also be misunderstanding something, but it seems like action angle coordinates for the evolution with respect to a distant observer (rather than Carter-Mino time) are currently only well established for Schwarzchild (https://ui.adsabs.harvard.edu/abs/2022arXiv220311952W/abstract) and have only recently (Jan 2023!) been applied to Kerr (https://ui.adsabs.harvard.edu/abs/2023arXiv230108150K/abstract)?
A sentence on the choice not to use AA has been added to the end of the second paragraph of the Statement of Need.

Let me know if you have any further comments or queries. One additional thing I need to do is complete the swap over from Zygote.jl to Enzyme.jl in the testing and notebooks, but this is not quite ready yet.
Cheers!

Thanks, @tomkimpson, for your herculean effort! I am kind of under water this week (and possibly for the next 2, with a proposal deadline looming...) so I can only make trivial comments right now. I agree that Rtensor allocation is not important here (as compared to an NR code where one would be computing this at every grid point). Regarding the AA formulation for (nearly) geodesic orbits in Kerr: The 2023 paper you referred to above is for the inspiral, but geodesic order is much farther ahead. The fact that AA can be done for Kerr geodesics was known since Carter (1968), but strictly going to AA variables is not necessary to get all the benefits. The fact that the Carter-Mino time parameter makes it possible to solve for radial and polar motions independently became widely known after Mino (2003) but you still get many benefits without it. The analytical solutions for geodesic order were written down by Fujita and Hikida (2009), and repackaged into a very convenient form in 1906.05090. The fact that the program continues to work to O(s^1) was shown by Vojtech Witzany, also in (2019). (This and most EMRI work expands in spin, as I mentioned before, since if you want to work to O(s^2), you should also be including the quadrupole moment, etc... so it's not really worth it to work to "all orders" in spin, since it's inconsistent anyway.)

Forgot to comment... @farr do you have any time to take a look while I'm tied up with other work?

All comments addressed. Merging and closing this PR -  will continue discussion in PR for reviewer 2


add example/test for placing Lib and a Func in a struct

I can't figure out the lifetimes. As far as I can tell, this should be valid:
use winapi::{HANDLE, DWORD, PCHAR, BOOL};

use winapi::{HMODULE, FARPROC};
use kernel32::{LoadLibraryA, FreeLibrary};
use sharedlib::{Lib, Func, Symbol, Result};

static path: &'static str = "winsta.dll\0";
type connect_a = extern "system" fn (hServer: HANDLE, SessionID: DWORD, TargetSessionID: DWORD, pPassword: *const u8, bWait: BOOL) -> BOOL;

pub struct Dll<'a> {
    lib: Lib,
    connect_a: Func<'a, connect_a>,
}
impl<'a> Dll<'a> {
    pub fn WinStationConnectA(&self, h: HANDLE, sid: DWORD, tsid: DWORD, pw: *const u8, wait: BOOL) -> BOOL {
        unsafe {
            self.connect_a.get()(h, sid, tsid, pw, wait)
        }
    }
}

pub fn load<'a>() -> Result<Dll<'a>> {
    let lib0: Lib = try!(unsafe {Lib::new(path)} );
    let sym = try!(unsafe {lib0.find_func("WinStationConnectA\0")});
    let dll: Dll<'a> = Dll {
        lib: lib0,
        connect_a: sym,
    };
    return Ok(dll)
}

It should be possible to put a Lib and a Func into a struct that's parameterized by a lifetime, since the Lib will outlive the Func. But the compiler claims that lib0 only lives until the end of the function, even though I move it into .lib. Clearly I intend it to live as long as the Dll struct lives, but I see the problem that interior mutability in Dll could result in assignment to .lib.
I imagine this use case isn't unique, and I couldn't find any examples in the documentation showing the correct way to do this.

Check out the new tests at the bottom of https://github.com/tyleo/sharedlib/blob/master/src/test/shared.rs
There are a few ways to do this. I provided examples for two safe ways, and one unsafe way.


Update BigQueryIO Documentation

Updated the description regarding failed rows for Storage Write API.
Made PCollection formatting consistent.

Please add a meaningful description for your change here
fixes #27298
Current documentation mentions WriteResult.getFailedInserts does not work for Storage Write API. But now WriteResult.getFailedStorageApiInserts will return the failed rows for Storage Write API.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

assign to next reviewer

/assign to next reviewer

@kennknowles Could you take a look at this PR?

R: @ahmedabu98

@ahmedabu98
Thank you. 👏

Also I think we can remove the sentence If there are data validation errors, the transform will throw a RuntimeException. That doesn't happen anymore, data validation errors should also go to the failed inserts DLQ

QQ I thought the "data validation errors" is this shema validation, isn't it? If no I'll quick fix the document.👍
https://github.com/apache/beam/blob/v2.50.0/sdks/java/io/google-cloud-platform/src/main/java/org/apache/beam/sdk/io/gcp/bigquery/StorageApiLoads.java#L112

QQ I thought the "data validation errors" is this schema validation, isn't it?
I think data validation refers to schema validation, but I don't think that specific link is related. R rows with mismatched schema do go to the DLQ. In practice most failed rows in the DLQ are due to this. I'm not sure how the behavior was before, but we don't fail the transform/pipeline now.

I think the line in the link you sent checks that the coder for the StorageApiWritePayload object exists (this does not validate data schema).

@ahmedabu98 Sorry for the delay in getting back to you.

(should probably remove that sentence

Yes, your comment resolved my QQ . The sentences should be removed. Thanks for letting me know.👍
I have added a new commit.👀.


WCAG 4.1.2: (devenv/tab item 'System.Windows.Controls.TabItem Header: Content:') Focusable sibling elements must not have the same Name and LocalizedControlType.

The following accessibility issue needs investigation.
App: devenv
Element path: tab item 'System.Windows.Controls.TabItem Header: Content:'
Issue Details: Focusable sibling elements must not have the same Name and LocalizedControlType. WCAG 4.1.2
How To Fix: Provide unique names for sibling controls that have the same ControlType property.
This accessibility issue was found using Accessibility Insights for Windows, a tool that helps debug and find accessibility issues earlier. Get more information and download this tool at https://aka.ms/AccessibilityInsights.

The problem here is that these tabs don't have a name property. I have no idea why this is a problem. There is a name attribute on the TabItem

Maybe the stack panel needs to have a name on it?

I think I was doing this wrong. Follow similar instructions to here: https://docs.microsoft.com/en-us/accessibility-tools-docs/items/WPF/ComboBox_Name

Closing as this is initial fast pass check.


Native: Missing Props

DatePicker

[ ] Why do we have showFilter and filterLabel props? Code Ref - these are missing from the doc.

These are present in all the components. They'll work if/when we add a SelectedFilters like component in native.


Make it easier to get started with stacker

I used stacker for a small project over break and it was painful to get up and running with it. A part of this was some unmerged PRs like stacker blueprint info as well as the dynamodb blueprint, but it was also annoying to have to remember the following:

create an env file
create a config file
invoke stacker
install private blueprints

i had to read through some existing projects use of stacker to remember the env/config file setup. setting up the virtualenv was annoying because it wasn't a python project. i didn't even attempt to install private blueprints because i didn't want to have to have to write a script to install them before running stacker.
my thoughts on how we might make this easier:
stacker init
something similar to npm init where we ask some questions with defaults that sets up the bare minimum file system that stacker depends on:

conf directory
yaml config
dev env file

i think this would make it easier to get stacker running within new projects faster
invoking stacker
I think this would have taken care of my last two points (invoking and installing private blueprints):
https://github.com/remind101/stacker/blob/master/scripts/docker-stacker
but the stacker version within the docker image isn't release-1.0
it might be cool to have these live within a stacker docker namespace? so i could have just run something like:
stacker docker build <namespace> <config> --private-stacks stacks? and it would take care of running these within docker for me.
using stacker
stacker blueprint info was really useful when getting back into stacker after being away from it for awhile. I think adding first class support for explaining troposphere types as well as maybe even discovering community blueprints would make this even better.

After you mentioned coming back to stacker in Slack, I started thinking about the on-boarding experience and came to many of the same conclusions.
Strongly agree about the init subcommand in particular. Hardest part will probably be the color of the bike...I mean the exact directory layout to do.
For the stacker-docker, you should be able to reference the release-1.0 tag to use the current version (maybe that was something fixed after your post here)
The only thing I'd like to do differently is handling private stacks. Installing them as python packages seems fine enough to me in docker, but handling the different versions of an blueprints via a python install in general isn't appealing to me. I'd rather have the ability to reference them directly (#332) or something akin to it.

I'm currently on-boarding with stacker myself and have been running in similar feels.  I plan to look into developing the init command over the next few weeks.

Another update: I converted my stacker-helloworld into a Cookiecutter project template:
https://github.com/remind101/stacker_cookiecutter
Assuming Cookiecutter is installed the usage is really simple:
cookiecutter gh:remind101/stacker_cookiecutter

A new project directory will be created in your present working directory.

init would help a lot, it's not clear that python setup.py install should be executed


How i could debug the frontend

Hello, I'm trying to debug the files in the angular folder, but I can not, because gulp's tasks do not allow it. Would you help me?

Hi @dojbraga
Can you provide more information? It's not clear what you're trying to do

Hi @jadjoubran
I am trying to do debugin in files into angular folder, but when i run gulp && gulp watch it's not possible.
I would like to know if the correct way to debug is running gulp && gulp whatch or if there is any task to debug with browsesync or outher way.
Example:
`export function RoutesRun($rootScope, $state, $transitions, $auth, API, ContextService) {
'ngInject';
let requiresAuthCriteria = {
    to: ($state) => $state.data && $state.data.auth
};

debugger;

let redirectToLogin = () => {
    'ngInject';
    if (!$auth.isAuthenticated()) {
        ContextService.clearContext()
        return $state.target('app.login', undefined, { location: false });
    } else {
        ContextService.setContext()
    }
};

$transitions.onBefore(requiresAuthCriteria, redirectToLogin, { priority: 10 });

}
`

Maybe throwing in a debugger; statement?
MDN Docs it works with Chrome dev tools too

`D:\WEB\laravel\projeto>gulp && gulp watch
[14:30:38] Using gulpfile D:\WEB\laravel\projeto\gulpfile.js
[14:30:39] Starting 'all'...
[14:30:39] Starting 'bower-js'...
[14:30:40] gulp-notify: [Laravel Elixir]
[14:30:40] gulp-notify: [Laravel Elixir]
[14:30:40] Finished 'bower-js' after 1.74 s
[14:30:40] Starting 'bower-css'...
[14:30:41] gulp-notify: [Laravel Elixir]
[14:30:41] gulp-notify: [Laravel Elixir]
[14:30:41] Finished 'bower-css' after 536 ms
[14:30:41] Starting 'copy'...
[14:30:41] Finished 'copy' after 79 ms
[14:30:41] Starting 'copy'...
[14:30:41] Finished 'copy' after 5.32 ms
[14:30:41] Starting 'webpack'...
[14:30:46]
[14:30:46] Finished 'webpack' after 4.93 s
[14:30:46] Starting 'sass'...
[14:30:46] Finished 'sass' after 476 ms
[14:30:46] Starting 'sass'...
[14:30:46] Finished 'sass' after 96 ms
[14:30:46] Starting 'styles'...
[14:30:47] Finished 'styles' after 227 ms
[14:30:47] Starting 'eslint'...
[object Object]
[14:30:48]
D:\WEB\laravel\projeto\angular\run\routes.run.js
15:13  error  Unexpected console statement  no-console
D:\WEB\laravel\projeto\angular\app\components\app-header\app-header.component.js
20:13  error  Unexpected console statement          no-console
21:13  error  Unexpected 'debugger' statement       no-debugger
26:13  error  '$http' is not defined                no-undef
26:44  error  'response' is defined but never used  no-unused-vars
✖ 5 problems (5 errors, 0 warnings)

Hi @dojbraga
Isn't your page running in the browser?
It may be because $http is not defined in app-header.component.js

I was able to debug! Thank you @jadjoubran


Implement mrb_raise with panic

The gymnastics and sad times in artichoke/ferrocarril#168 become unnecessary if we have a memory safe unwind. panic is exactly that.
Implement mrb_raise, mrb_raisef and mrb_protect in Rust in mrb-sys exported to C so libmruby can use them.

This is currently blocked on https://github.com/rust-lang/rfcs/pull/2699.

The linked RFC resulted in unwind ABIs: https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html
Upstream tracking issue: https://github.com/rust-lang/rust/issues/74990

The C-unwind ABI has been implemented and is currently on nightly: https://github.com/rust-lang/rust/pull/76570.

this is happening! https://github.com/rust-lang/rfcs/pull/2945#issuecomment-1152045161


How to work with @Configurations guarded by @Profile

I have a configuration class that is conditional via @Profile. This does not seem to be supported at run-time. I tried to specify "-Dspring.profiles.active=kubernetes" as BP_NATIVE_IMAGE_BUILD_ARGUMENTS to only activate this in builds for deployments, but this did not help.
What alternatives do I have?
@Configuration
@Profile("kubernetes")
class SQSConfig() {

    @PostConstruct
    fun postConstruct() {
        logger.info("Created SQSConfig")
        logger.info("EVENT_QUEUE_URL: >${System.getenv("EVENT_QUEUE_URL")}<")
    }

    @SqsListener("\${EVENT_QUEUE_URL}", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
    fun receiveEvent(@NotificationMessage eventRaw: String, @NotificationSubject subject: String) {
        logger.info { "Received SNS/SQS event $subject: $eventRaw" }
    }

    companion object : KLogging()
}

I think this is a duplicate of #1411.

Thanks. I think the info on the linked issue will help me out.
Just out of curiosity: what is actually preventing @Profile and @Conditional annotations from working in spring native? Is there a fundamental hurdle or is it a matter of time and priority? From my naive perspective, I would have guessed, the conditions "just" have to be baked into the generated BeanFactories, so they can be evaluated at runtime...

They work but currently they are evaluated at build time, see https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/#spring-aot for more details. We may provide a more flexible system later.


Move timestamp/duration formatting to utils [Step results #5]

We will need them from other places, it's not longer just execute who will be dealign with times.
Depends on https://github.com/teemtee/tmt/pull/2979
Pull Request Checklist

[x] implement the feature

Tests are failing with:
AttributeError: type object 'ExecutePlugin' has no attribute 'format_duration'


Update KsuidFactory.java

Adds the option to pass an Instant supplier to the public static factory functions.

Ideally the same change for TSIDs as well :)

Hi, @sollecitom
Released version 4.1.1 with your updates.
As for TSIDs, it's now using LongSupplier to get the current milliseconds. In this case, I didn't choose Supplier<Instant> because Instant's nanoseconds are not needed.
Thank you again!


Drag and Drop and resize bugs on month view

Do you want to request a feature or report a bug?
Bug
What's the current behavior?
Hello,
Since 0.33.2 version, Drag and drop is unusable on month view. : The dragged Dom element is not under the cursor during the drag.
Same problem with right resize. The resized dom element size one more day (eg: 3 days instead of 2)
No problems on 0.32 version for the drag and drop. But the resize was not functional on 0.32
No problems on week views, just on month view.
Version of React 17.01
Browser : Google Chrome 89
What's the expected behavior?
Same DD has 0.32 version.

Hi guys! same issue over here, is there any fix available? somebody?
It would be highly appreciated.
Thanks in advance

somebody?

Source is available for anyone to edit. It appears this should do the trick:
https://github.com/jquense/react-big-calendar/pull/1892/files

There is a similar issue on the week view when extending all-day events. Because of the offset it's often impossible to extend events until Sunday.

I wonder if this is a related issue;
See the erratic behavior here in week view.

https://github.com/jquense/react-big-calendar/pull/1892 was merged and 0.33.3 was released.
This issue can be closed.

Is anyone else having problems with this in 0.33.6?

Is anyone else having problems with this in 0.33.6?

Yes, I have the same problem


actool: validate should support --signature

From @jonboulle on November 27, 2014 9:9
Copied from original issue: coreos/rocket#76

To clarify
actool validate --signature <image>

Would both validate the image and print the signature?
Or would the usage be:
actool validate --signature (<sig string>|sig filename) <image>

Would both validate the image and print the signature?

Per #129 (which I subsequently updated), I think you are confusing an image's ID (hash sum) with its signature (gpg); we want actool validate to be able to confirm that a given signature is valid for a given image.


Suggestions

Package Version
3.1
Laravel Version
11
PHP Version
8.2
Problem description

The table sorts on created_at in ascending order, so all new activity is at the end of the pagination.
In Rmsramos\Activitylog\Resources\ActivitylogResource, there are many misspellings of "Compoment."

Expected behavior

It should be sorted in descending order.
It should be spelled "Component."

Steps to reproduce

Add ->defaultSort('created_at', 'desc') to the table.
Change "Compoment" to "Component."

Reproduction repository (issue will be closed if this is not valid)
https://github.com/dharen008/Vendors.git
Relevant log output
No response

@rmsramos i have seen another error on the plugin, if the causer->name is on softdelete it will have null error
You can fix it like this
public static function getCauserNameColumnCompoment(): Column
{
return TextColumn::make('causer.name')
->label(__('activitylog::tables.columns.causer.label'))
->getStateUsing(function (Model $record) {
            if ($record->causer_id == null) {
                return new HtmlString('—');
            }

            return $record->causer->name ?? 'Record deleted';
        })
        ->searchable();
}

Package Version
3.1
Laravel Version
11
PHP Version
8.2
Problem description

The table sorts on created_at in ascending order, so all new activity is at the end of the pagination.
In Rmsramos\Activitylog\Resources\ActivitylogResource, there are many misspellings of "Compoment."

Expected behavior

It should be sorted in descending order.
It should be spelled "Component."

Steps to reproduce

Add ->defaultSort('created_at', 'desc') to the table.
Change "Compoment" to "Component."

Reproduction repository (issue will be closed if this is not valid)
https://github.com/dharen008/Vendors.git
Relevant log output
No response

You can add to composer.json
"repositories": [         {             "type": "vcs",             "url": "https://github.com/dvsapps/activitylog"         }     ],
and then inside require change to
"rmsramos/activitylog": "dev-main",

defaultSort to $table #37
You can add to composer.json
"repositories": #[ { "type": "vcs", "url": "https://github.com/dvsapps/activitylog" } ],
and then inside require change to
"rmsramos/activitylog": "dev-main",
then composer update

i will not use your repo because the dev already merge it with your update


[Feature] Use Protobuf for DB (and network?) serialization

Protobuf will probably add a few bytes overhead -- worth it for storage for forwards and backwards compatibility, but network is another call. I still think it's worth it.

Any reason for protobuf as opposed to cap'n'proto already used by the network? It's consistently faster in benchmarks and the schema is simpler.

flatbuffers is likely to be even faster, and it also has a schema-less variant, flexbuffers, which might be more practical for pure storage purposes.

https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html
I'm not super strongly protobuf-only mode/have a great reason for protobuf, I've just used it a lot, and the difference in performance at the scale of a node makes runtime perf of serialization a non-issue. If others feel strongly in favor of others, I'm open.
I'm not a fan of any schema-less solutions though.

Closing, as it's no longer applicable to testnet2.


How do I undefine a MACRO

here is piece of code in libcurl:
#include "curl_setup.h"
#ifndef HAVE_SOCKETPAIR
int Curl_socketpair(int domain, int type, int protocol,
                    curl_socket_t socks[2]);
#else
#define Curl_socketpair(a,b,c,d) socketpair(a,b,c,d)
#endif

/* Defined here to allow specific build configs to disable it completely */
#define USE_SOCKETPAIR 1

#endif /* HEADER_CURL_SOCKETPAIR_H */

i would like to un define USE_SOCKETPAIR ,how do i do that .i know there r some config inside port directory from vcpkg,but i just dont know how to do that .I would appreciate that if someone can help me out

I checked the source code and did not define HAVE_SOCKETPAIR anywhere. This macro should not be enabled.

I checked the source code and did not define HAVE_SOCKETPAIR anywhere. This macro should not be enabled.

u r right,but this is NOT what I care( FYI,source code will implement Curl_socketpair by it own,  instead calling API)
I just want to know if it is ok to remove the "socketpair system",controled by the "USE_SOCKETPAIR "

@hotbroker That's okay, but that's personal customization.
You need to modify source code in VCPKG_PATH/buildtrees/curl/src/url*_.
Just change #ifndef HAVE_SOCKETPAIR to #if 0 will solve your issue. I guess.

@hotbroker That's okay, but that's personal customization.
You need to modify source code in VCPKG_PATH/buildtrees/curl/src/url*_.
Just change #ifndef HAVE_SOCKETPAIR to #if 0 will solve your issue. I guess.

well,if i do it in this way,I know how it works。but I remove & install this lib  after changing source code , didnt the vcpkge will release a new package of source code again?
so eventually it may not work,I tested this on zlib

@hotbroker You may need to patch to complete these tasks, and use the patch in portfile.cmake.
Since I'm not sure if this feature is officially supported, I recommend against using it as a feature.

@hotbroker You may need to patch to complete these tasks, and use the patch in portfile.cmake.
Since I'm not sure if this feature is officially supported, I recommend against using it as a feature.

老铁，你是中国人啊？哈。按你那么说的，我要去修改cmake了

@hotbroker 个人的修改我建议打patch，基准目录是VCPKG_PATH/buildtrees/curl/url-*，以此为基准用git init .来打补丁，然后把补丁放到VCPKG_PATH/ports/curl里面。
以后如果更新版本也没关系，直接revert portfile.cmake然后git pull，最后把补丁加到portfile.cmake里面就行了。
不过有可能更新导致你打补丁的文件修改了，从而使补丁失效。这时候你得重新打一次。

@hotbroker 个人的修改我建议打patch，基准目录是VCPKG_PATH/buildtrees/curl/url-*，以此为基准用git init .来打补丁，然后把补丁放到VCPKG_PATH/ports/curl里面。
以后如果更新版本也没关系，直接revert portfile.cmake然后git pull，最后把补丁加到portfile.cmake里面就行了。
不过有可能更新导致你打补丁的文件修改了，从而使补丁失效。这时候你得重新打一次。

目前看应该是只能改这里了。暂时先这样吧，谢谢了。cmake还不是很会看，里面有些变量都不知道哪 来。

cmake自带一些变量，如果不是VCPKG_开头的或者在source中搜不到，可以去cmake官网搜一下。


I'd like to join this project's community

Your public repo
https://github.com/mami-st/gov4git-identity-public.git
Your public branch
main

Hi, have you contributed to the project?

@GlenWeyl, if contributing to a project is a condition of becoming a community member, where can I find a list of contributable projects?

You can submit a PR addressing any of the issues on the main repo.  But I just sent you the Discord link as well.  Contributing is not a strict condition of joining the community, but given that there are some possible sybil attacks we only want to allow people who have real interest in contributing to join.

@GlenWeyl
She is Mami Sato, who joined Discord in 01/15/2024. Maybe this issue is generated automatically by Gov4Git program and she does not know it. I'll mention her.
https://discord.com/channels/1133444567031627846/1142734351881220116/1196331999141560420


VPVC Pilot invitation Deep link not working

Context: After receiving invitation e-mail, reviewing credentials, and in the screen with the QR Code.
Nothing happens when taping "Open Wallet App"

blocks #669

Seems like this is an issue in the wider issuer-kit codebase, working on a fix

Duplicates #669


Don't include lure itself from github...

I could be wayyy off but my understanding is that means building go would always at least partly use some remotely published version and not local changes?
At least that's what I experienced locally...

It seems my workflow was different from everyone else's. Reject?


global is not defined | Breaks HMR

Version
@nuxtjs/supabase: v1.0.2
nuxt: v3.6.5
Error
After installing Nuxt/supabase, the hot module reload breaks and in the dev console the following error appears:
Uncaught ReferenceError: global is not defined

Step to Reproduce

npx nuxi create <project-name>
yarn add -D @nuxtjs/supabase
Add Nuxt Config:

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  devtools: { enabled: true },
  modules: ['@nuxtjs/supabase'],
  supabase: {
    url: process.env.SUPABASE_URL,
    key: process.env.SUPABASE_KEY,
    serviceKey: process.env.SUPABASE_SERVICE_KEY,
    redirect: false, // disable global redirect to login page
  },
})

yarn dev
Error appears in console

Seems the Demo application breaks too: https://github.com/nuxt-modules/supabase/tree/main/demo

I've come across the identical issue, where both form validation and HMR are failing to function correctly.

I was able to fix this by updating the nuxt.config.ts and installing axios
  vite: {
    optimizeDeps: {
      esbuildOptions: {
        define: {
          global: "globalThis",
        },
      },
    },
    resolve: {
      alias: {
        '@supabase/node-fetch': 'axios',
      },
    },
  },

I was able to fix this by updating the nuxt.config.ts and installing axios
  vite: {
    optimizeDeps: {
      esbuildOptions: {
        define: {
          global: "globalThis",
        },
      },
    },
    resolve: {
      alias: {
        '@supabase/node-fetch': 'axios',
      },
    },
  },

replaced axios with isomorphic-fetch and works like a charm. THANK YOU.

I was able to fix this by updating the nuxt.config.ts and installing axios
  vite: {
    optimizeDeps: {
      esbuildOptions: {
        define: {
          global: "globalThis",
        },
      },
    },
    resolve: {
      alias: {
        '@supabase/node-fetch': 'axios',
      },
    },
  },

actually just this seems to be enough. The problem is in @supabase/node-fetch library
  vite: {
    assetsInclude: [/\.mov/, /\.apng/],
    resolve: {
      alias: {
        '@supabase/node-fetch': 'isomorphic-fetch',
      },
    },

},

It works ✨. Thank you @xkabr00 and @markus-gx .

Seems the Demo application breaks too: https://github.com/nuxt-modules/supabase/tree/main/demo

Thank you 🔥


Update redirect config to new blog location

#387
@angiejones does this satisfy what you're requesting? If not, where is the "old" link you're referring to in #387?
Pending @angiejones review, leaving to @dayhaysoos to field the PR and merge alongside the other work flowing in for Phase 2.

We should probably add a Redirect on Netlify config just in case anyone tries to access the old link, yeah? If I remember correctly, this blog was announced and shared publicly

Oh just found there was an issue for this #387, going to check now

I'm going to make sure this gets into main


Hardware Randomizer not sufficient on NonStop x86

I am trying to track this down and am having difficult figuring out what is going on. With a build configuration using --with-rand-seed=rdcpu and enable-fips, I am expecting the hardware randomizer on NonStop x86 to get its random bytes from the x86 hardware _rdrand64()  builtin function, which it seems to do correctly. However, if I do not have PRNGD running, the RAND_bytes seems to not return data correctly. Tracking this down is hard because it is on a customer system for which I do not have access and buried inside git, although checking the git code shows that it is invoking RAND_bytes, and the DLL is built correctly.
Requesting assistance tracking down the root cause or at least being able to trace this. All OpenSSL tests, both in or not in FIPS mode all pass. git is invoking RAND_bytes directly. It seems like this was working correctly at some point in the 3.0.1 timeframe.

There is a failure path if _rdrand64() returns a zero value.  There have been CPUs which reported success (carry = 1) but returned zeros, hence this check.
If one source fails, others will be tried.  This might explain why PRNG fixes things.
The only suggestion I can think of otherwise is lots of prints to figure out exactly what's happening.

Thanks. I will set up a test program for _rdrand64() and have the user try it.

I have tested the _rdrand64() built-in function that wraps the hardware randomizer. It always returns 1 after 1000000 iterations. I'm back to being at a loss about this.

That's a new one :(
PRNGD seems like the way to go or rely on the system's RNG.  OpenSSL doesn't support other entropy sources.

That's a new one :(
PRNGD seems like the way to go or rely on the system's RNG. OpenSSL doesn't support other entropy sources.

PRNGD does not allow FIPS, so we used the hardware randomizer. The code is here, but I am concerned it is somehow not being accessed.
https://github.com/openssl/openssl/blob/d0a3b9d1eb1fc510ec3447b44803bbf5520a0c47/providers/implementations/rands/seeding/rand_cpu_x86.c#L59-L89

Did you check the output from _rdrand64() in addition to the return value?  There are systems which return success but don't produce a random value.  The continuous tests will detect this and shut the DRBGs down.
I didn't think RDRAND had ever been FIPS approved.  It certainly couldn't be under the current SP 800-90B requirements.
I'll also note that the OpenSSL 3.0 FIPS provider grabs seed entropy from outside the boundary and this wouldn't preclude using PRNGD or the OS.  This is the reason for the caveat about key quality in the certificate.  It was done this way because there was no chance we'd have been able to meet the current SP 800-90B requirements.

Did you check the output from _rdrand64() in addition to the return value? There are systems which return success but don't produce a random value. The continuous tests will detect this and shut the DRBGs down.

Yes, it's very random, and the x86 hardware HRNG does data all of the 140.x tests.  It passed all of the jitter tests and was approved by this team when I put the code in.

I didn't think RDRAND had ever been FIPS approved. It certainly couldn't be under the current SP 800-90B requirements.
I'll also note that the OpenSSL 3.0 FIPS provider grabs seed entropy from outside the boundary and this wouldn't preclude using PRNGD or the OS. This is the reason for the caveat about key quality in the certificate. It was done this way because there was no chance we'd have been able to meet the current SP 800-90B requirements.

This configuration ./Configure nonstop-nsx_64 --with-rand-seed=rdcpu enable-fips is permitted (and the one in use in this situation), while --with-rand-seed=egd does not allow enable-fips, which is why the above enhancement was made.

Did you check the output from _rdrand64() in addition to the return value? There are systems which return success but don't produce a random value. The continuous tests will detect this and shut the DRBGs down.

Yes, it's very random, and the x86 hardware HRNG does pass all of the 140.x tests. It passed all of the jitter tests also and was approved by this team when I put the code in.

I didn't think RDRAND had ever been FIPS approved. It certainly couldn't be under the current SP 800-90B requirements.
I'll also note that the OpenSSL 3.0 FIPS provider grabs seed entropy from outside the boundary and this wouldn't preclude using PRNGD or the OS. This is the reason for the caveat about key quality in the certificate. It was done this way because there was no chance we'd have been able to meet the current SP 800-90B requirements.

This configuration ./Configure nonstop-nsx_64 --with-rand-seed=rdcpu enable-fips is permitted (and the one in use in this situation), while --with-rand-seed=egd does not allow enable-fips, which is why the above enhancement was made.

@paulidale @mspncp I've been looking into the code below:
https://github.com/openssl/openssl/blob/c4cb151b4d19f5f2eb302baafac65e36e4408381/providers/implementations/rands/seeding/rand_unix.c#L273
to try to figure out how this would get down to the x86 RNG on NonStop and I'm not seeing it. The compiler defines are __TANDEM (NonStop) and _TNS_X_TARGET (x86 variant).

I am having difficulty finding an appropriate test and breakpoint to try to resolve this. The goal is to get down to get_hardware_random_value. I have tried test_rand (does not get called) and test_rdrand_sanity (skips). Help please.

Have you tried to run openssl rand -hex 10 in the debugger?

That's what I do (on Linux), directly from the root of the source directory.
 util/wrap.pl gdb --args rand -hex 10

Have you tried to run openssl rand -hex 10 in the debugger?

I just tried it. It does get to the correct get_hardware_random_value code and returns 384 bytes of random. It then throws a SIGSEGV.

SIGSEGV backtrace is:
#0  0x7fe330b9 in ossl_cipher_hw_generic_ecb (dat=0x10004f570,
    out=<value optimized out>, in=<value optimized out>,
    len=<value optimized out>)
    at /home/ituglib/randall/openssl-3.1/providers/implementations/ciphers/ciphercommon_hw.c:42
#1  0x7fe2d89b in ossl_cipher_generic_block_update (vctx=0x10004f570,
    out=<value optimized out>, outl=<value optimized out>, outsize=64,
    in=0x6fffe650 "", inl=48)
    at /home/ituglib/randall/openssl-3.1/providers/implementations/ciphers/ciphercommon.c:367
#2  0x7fc4712d in EVP_EncryptUpdate (ctx=0x10004f3d0, out=0x6fffe620 "",
    outl=0x6fffe684, in=0x6fffe650 "", inl=48)
    at /home/ituglib/randall/openssl-3.1/crypto/evp/evp_enc.c:643
#3  0x7fc46e12 in EVP_CipherUpdate (ctx=0x10004f3d0, out=0x6fffe620 "",
    outl=0x6fffe684, in=0x6fffe650 "", inl=48)
    at /home/ituglib/randall/openssl-3.1/crypto/evp/evp_enc.c:419
#4  0x7fe13b8e in ctr_update (drbg=<value optimized out>,
    in1=<value optimized out>, in1len=<value optimized out>,
    in2=<value optimized out>, in2len=<value optimized out>,
    nonce=<value optimized out>, noncelen=0)
    at /home/ituglib/randall/openssl-3.1/providers/implementations/rands/drbg_ctr.c:280
#5  0x7fe13e63 in drbg_ctr_instantiate (drbg=<value optimized out>,
    entropy=<value optimized out>, entropylen=<value optimized out>,
    nonce=<value optimized out>, noncelen=<value optimized out>,
    pers=<value optimized out>, perslen=29)
    at /home/ituglib/randall/openssl-3.1/providers/implementations/rands/drbg_ctr.c:321
#6  0x7fe29996 in ossl_prov_drbg_instantiate (drbg=0x10002cd70, strength=0,
    prediction_resistance=0, pers=0x7fff3be0 "OpenSSL NIST SP 800-90A DRBG",
    perslen=29)
    at /home/ituglib/randall/openssl-3.1/providers/implementations/rands/drbg.c:460
#7  0x7fe12b1a in drbg_ctr_instantiate_wrapper (vdrbg=0x10002cd70,
    strength=<value optimized out>,
    prediction_resistance=<value optimized out>, pstr=<value optimized out>,
    pstr_len=<value optimized out>, params=<value optimized out>)
    at /home/ituglib/randall/openssl-3.1/providers/implementations/rands/drbg_ctr.c:336
#8  0x7fc55ee1 in evp_rand_instantiate_locked (ctx=0x10002cd10, strength=0,
    prediction_resistance=0, pstr=0x0, pstr_len=0, params=0x6fffeae0)
    at /home/ituglib/randall/openssl-3.1/crypto/evp/evp_rand.c:505
#9  0x7fc55f8b in EVP_RAND_instantiate (ctx=0x10002cd10, strength=0, prediction_resistance=0, pstr=0x0, pstr_len=0, params=0x6fffeae0)
    at /home/ituglib/randall/openssl-3.1/crypto/evp/evp_rand.c:518
#10 0x7fcf51de in rand_new_drbg (libctx=0x0, parent=0x10002cc20,
    reseed_interval=256, reseed_time_interval=3600)
    at /home/ituglib/randall/openssl-3.1/crypto/rand/rand_lib.c:600
#11 0x7fcf3dc4 in RAND_get0_primary (ctx=0x0)
    at /home/ituglib/randall/openssl-3.1/crypto/rand/rand_lib.c:647
#12 0x7fcf46c0 in RAND_get0_public (ctx=0x0)
    at /home/ituglib/randall/openssl-3.1/crypto/rand/rand_lib.c:678
#13 0x7fcf45c1 in RAND_bytes_ex (ctx=0x0, buf=0x6fffed70 "", num=10, strength=0)
    at /home/ituglib/randall/openssl-3.1/crypto/rand/rand_lib.c:363
#14 0x7fcf47f3 in RAND_bytes (buf=0x6fffed70 "", num=10)
    at /home/ituglib/randall/openssl-3.1/crypto/rand/rand_lib.c:374
#15 0x7006d33b in rand_main (argc=1, argv=0x805a018)
    at /home/ituglib/randall/openssl-3.1/apps/rand.c:123
#16 0x7005c612 in do_cmd (prog=0x100020690, argc=3, argv=0x805a008)
    at /home/ituglib/randall/openssl-3.1/apps/openssl.c:418
#17 0x7005c22e in main (argc=3, argv=0x805a008)
    at /home/ituglib/randall/openssl-3.1/apps/openssl.c:296
#18 0x700157e0 in _MAIN () at \BLPROD.$RTAL.T8432ACN.CMAIN64C:52

Can you reconfigure and rebuild with --debug?

Can you reconfigure and rebuild with --debug?

In progress.

0302ed947942cf204bd4
Process (2,679) exited normally.

This did invoke get_hardware_random_value correctly.

Maybe --debug introduces too many changes. You could try without --debug  and instead replace -O3 with -O0 -g manually in the Makefile's CFLAGS after configuring. Hopefully then the error will reoccur.

Maybe --debug introduces too many changes. You could try without --debug and instead replace -O3 with -O0 -g manually in the Makefile's CFLAGS after configuring. Hopefully then the error will reoccur.

Actually, when I rebuilt clean, the SIGSEGV went away. So things are looking good. The question for me now is why git is ending up requiring PRNGD on this build where the x86 RNG should be used. Is there something at runtime that might be causing this?

Are you sure git is using your OpenSSL library? Did you check ldd `which git` ?

Are you sure git is using your OpenSSL library? Did you check ldd `which git`?

100% sure. There is only one git and one OpenSSL on the system.

Git doesn't seem to use much of the OpenSSL API directly, except for imap-send.c:
~/src/git$ git grep -i -e openssl -e evp | grep -F .c
imap-send.c:#ifdef NO_OPENSSL
imap-send.c:#ifndef NO_OPENSSL
imap-send.c:#ifndef NO_OPENSSL
imap-send.c:#ifdef NO_OPENSSL
imap-send.c:#if (OPENSSL_VERSION_NUMBER >= 0x10000000L)
imap-send.c:     * OpenSSL does not document this function, but the implementation
imap-send.c:#ifndef NO_OPENSSL
imap-send.c:#ifndef NO_OPENSSL
imap-send.c:#ifndef NO_OPENSSL
imap-send.c:#ifndef NO_OPENSSL
imap-send.c:    decoded_len = EVP_DecodeBlock((unsigned char *)challenge,
imap-send.c:    if (!HMAC(EVP_md5(), pass, strlen(pass), (unsigned char *)challenge, decoded_len, hash, NULL))
imap-send.c:    encoded_len = EVP_EncodeBlock((unsigned char *)response_64,
imap-send.c:            die("EVP_EncodeBlock error");
imap-send.c:        "you have to build git-imap-send with OpenSSL library.");
imap-send.c:#ifndef NO_OPENSSL
imap-send.c:#elif defined(NO_OPENSSL)

So my wild guess is: maybe the seeding is done indirectly by libcurl, see ossl_seed() in lib/vtls/openssl.c.

This is entirely possible and might well explain the situation. The problem is on a git add and push, where random data is required, but it is not calling RAND_bytes directly. The more I think about it, it could be in the curl code. I will ask that team.

Actually, you should be able to verify my conjecture before asking questions on the curl project, even without debug symbols for git and libcurl by running the git command in the debugger with a suitable breakpoint in libcrypto.

Would that it could be so. The relevant call appears to be across a fork(), which cannot be set in the platform debugger at this time. I can force the code into the debugger but need to know exactly where to break, put the call in, rebuild, then test git with the debug library. Suggestion?

According to strace, git executes git-remote-https after the fork (assuming you are using https), which is one of the gitremote-helpers.
msp@debian:~/tmp/playground$ strace -f git push --set-upstream origin foo |& grep exec
execve("/usr/bin/git", ["git", "push", "--set-upstream", "origin", "foo"], 0x7fff1815d648 /* 45 vars */) = 0
[pid  2180] execve("/usr/lib/git-core/git", ["/usr/lib/git-core/git", "remote-https", "origin", "https://github.com/mspncp/playgr"...], 0x55e9c91ce2c0 /* 48 vars */ <unfinished ...>
[pid  2180] <... execve resumed>)       = 0
[pid  2181] execve("/usr/lib/git-core/git-remote-https", ["/usr/lib/git-core/git-remote-htt"..., "origin", "https://github.com/mspncp/playgr"...], 0x5645ceac4ef0 /* 48 vars */ <unfinished ...>
[pid  2181] <... execve resumed>)       = 0
Username for 'https://github.com':

You could try to figure out how you can call it directly, so you can debug without crossing a fork.

As for the breakpoint: if it is possible for you to build lib curl with debug symbols as well, I would set it to ossl_seed().

Skimming through gitremote-helpers, it seems like you need to send it some commands on stdin in order to get it to connect. Unfortunately, I lack the time to dig further. Happy debugging!

After breaking in ossl_seed(), I end up back in RAND_bytes(), which seems correct. I have asked the curl team for any wisdom on this.

Did the seeding succeed? If not, the DRBG is an error state, and RAND_bytes() should fail.

I have asked the curl team for any wisdom on this.

Just for my curiousity: where did you ask? I didn't find it, neither on GitHub, nor on curl-users.

I have asked the curl team for any wisdom on this.

Just for my curiousity: where did you ask? I didn't find it, neither on GitHub, nor on curl-users.

<EMAIL_ADDRESS>

Note to @bagder: question https://curl.se/mail/lib-2023-03/0011.html is related to this issue here.

Did the seeding succeed? If not, the DRBG is an error state, and RAND_bytes() should fail.

I have to rebuild curl in debug mode. Still looking.

Did the seeding succeed? If not, the DRBG is an error state, and RAND_bytes() should fail.

I have to rebuild curl in debug mode. Still looking.

In my full debug version, I cannot tell whether seeding succeeded, but it seems to. curl returns CURLE_OK from ossl_seed(). RAND_bytes is never called in the suggested sample.

RAND_bytes is never called in the suggested sample.

Ok, let's return to your original problem. Here are some thoughts and ideas:

In my full debug version, I cannot tell whether seeding succeeded, but it seems to. curl returns CURLE_OK from ossl_seed().

I would expect that in the normal case, when all works as expected, the function ossl_seed() returns early, because OpenSSL 1.1.0+ seeds automatically and no action by curl is necessary (as stated in the comment below):
  if(rand_enough()) {
    /* OpenSSL 1.1.0+ should return here */
    if(data->multi)
      data->multi->ssl_seeded = TRUE;
    return CURLE_OK;
  }

https://github.com/curl/curl/blob/master/lib/vtls/openssl.c#L972-L977

... the RAND_bytes seems to not return data correctly.

What does this mean exactly? Does RAND_bytes() return 0? (If the DRBG is in an error state, it is expected that 0 is returned and no output generated.)
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/crypto/rand/rand_lib.c#L370-L375

However, if I do not have PRNGD running, ...

Did you think of stopping the PRNGD before debugging git-remote-https? Please ensure that it is not running. If the error reoccurs, try set a breakpoint at ossl_drbg_get_seed() which implements the get_entropy() callback for the DRBG and try to figure out why it fails.
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/drbg.c#L132-L147

I would expect that you enter ossl_drbg_get_seed() twice; the first time for the  DRBG, which will request randomness from its parenht, the  DRBG,...
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/drbg.c#L135-L136
...the second time for the  DRBG which will attempt to get a fresh seed using ossl_pool_acquire_entropy:
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/drbg.c#L135-L136
So actually it's easier to just set a breakpoint at  ossl_pool_acquire_entropy. If the breakpoint is hit, debug it and find out why it fails.

I would expect that you enter ossl_drbg_get_seed() twice; the first time for the <public> DRBG, which will request randomness from its parent, the <primary> DRBG,...
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/drbg.c#L135-L136
...the second time for the <primary> DRBG which will attempt to get a fresh seed using ossl_pool_acquire_entropy:
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/drbg.c#L135-L136
So actually it's easier to just set a breakpoint at  ossl_pool_acquire_entropy. If the breakpoint is hit, debug it and find out why it fails.

Working on this. Scheduling the PRNGD outage takes time.

Ok, no problem. I'm not in a hurry 😉

I am, if I have to make the March 14 date for some reason.

Ok, no problem. I'm not in a hurry 😉

I am, if I have to make the March 14 date for some reason.

Scheduling the PRNGD outage takes time.

You don't need to stop the PRNGD if that's not possible. (Is it a production system?) You can simulate the absence of the PRNGD by changing the DEVRANDOM_EGD #define to an impossible socket path and rebuild.
Actually, it's a mystery to me why your openssl library queryies the EGD in the first place, because if you use only --with-rand-seed=rdcpu and not --with-rand-seed=rdcpu,egd then only OPENSSL_RAND_SEED_RDCPU should be defined but not OPENSSL_RAND_SEED_EGD.
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/seeding/rand_unix.c#L713-L722

I am, if I have to make the March 14 date for some reason.

Please note that the repository is already frozen for the release.

Scheduling the PRNGD outage takes time.

You don't need to stop the PRNGD if that's not possible. (Is it a production system?) You can simulate the absence of the PRNGD by changing the DEVRANDOM_EGD #define to an impossible socket path and rebuild.
Actually, it's a mystery to me why your openssl library queryies the EGD in the first place, because if you use only --with-rand-seed=rdcpu and not --with-rand-seed=rdcpu,egd then only OPENSSL_RAND_SEED_RDCPU should be defined but not OPENSSL_RAND_SEED_EGD.
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/seeding/rand_unix.c#L713-L722

It is a mystery to me as well. That's why I'm asking and trying to resolve this issue. Will try this experiment.

Could you please run  perl configdata.pm --dump and post the output?

Could you please run  perl configdata.pm --dump and post the output?

Command line (with current working directory = .):

    perl ./Configure nonstop-nsx --prefix=/home/ituglib/randall --openssldir=/home/ituglib/randall/ssl --with-rand-seed=rdcpu --debug enable-fips

Perl information:

    perl
    5.30.3 for NSV-D-nonstop_kernel

Enabled features:

    acvp-tests
    aria
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    bulk
    cached-fetch
    camellia
    capieng
    cast
    chacha
    cmac
    cmp
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    egd
    engine
    err
    filenames
    fips
    fips-securitychecks
    gost
    idea
    legacy
    loadereng
    md4
    mdc2
    module
    multiblock
    nextprotoneg
    ocb
    ocsp
    padlockeng
    pic
    pinshared
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    secure-memory
    seed
    shared
    siphash
    siv
    sm2
    sm3
    sm4
    sock
    srp
    srtp
    sse2
    ssl
    ssl-trace
    static-engine
    stdio
    tests
    tls
    ts
    ui-console
    whirlpool
    tls1
    tls1-method
    tls1_1
    tls1_1-method
    tls1_2
    tls1_2-method
    tls1_3
    dtls1
    dtls1-method
    dtls1_2
    dtls1_2-method

Disabled features:

    afalgeng            [not-linux]      OPENSSL_NO_AFALGENG
    asan                [default]        OPENSSL_NO_ASAN
    asm                 [no asm_arch]    OPENSSL_NO_ASM
    buildtest-c++       [default]
    crypto-mdebug       [default]        OPENSSL_NO_CRYPTO_MDEBUG
    devcryptoeng        [default]        OPENSSL_NO_DEVCRYPTOENG
    ec_nistp_64_gcc_128 [default]        OPENSSL_NO_EC_NISTP_64_GCC_128
    external-tests      [default]        OPENSSL_NO_EXTERNAL_TESTS
    fuzz-afl            [default]        OPENSSL_NO_FUZZ_AFL
    fuzz-libfuzzer      [default]        OPENSSL_NO_FUZZ_LIBFUZZER
    ktls                [default]        OPENSSL_NO_KTLS
    makedepend          [unavailable]
    md2                 [default]        OPENSSL_NO_MD2 (skip crypto/md2)
    msan                [default]        OPENSSL_NO_MSAN
    rc5                 [default]        OPENSSL_NO_RC5 (skip crypto/rc5)
    sctp                [default]        OPENSSL_NO_SCTP
    threads             [config]
    trace               [default]        OPENSSL_NO_TRACE
    ubsan               [default]        OPENSSL_NO_UBSAN
    unit-test           [default]        OPENSSL_NO_UNIT_TEST
    uplink              [no uplink_arch] OPENSSL_NO_UPLINK
    weak-ssl-ciphers    [default]        OPENSSL_NO_WEAK_SSL_CIPHERS
    zlib                [default]
    zlib-dynamic        [default]
    ssl3                [default]        OPENSSL_NO_SSL3
    ssl3-method         [default]        OPENSSL_NO_SSL3_METHOD

Config target attributes:

    AR => "ar",
    ARFLAGS => "qc",
    CC => "c99",
    HASHBANGPERL => "/usr/bin/env perl",
    RANLIB => "ranlib",
    RC => "windres",
    bn_ops => "THIRTY_TWO_BIT",
    build_file => "Makefile",
    build_scheme => [ "unified", "unix" ],
    cflags => "-g -O0 -Wextensions -Wnowarn=203,220,272,734,770,1506 -Wbuild_neutral_library -Wverbose -Wtarget=tns/x -Wsystype=oss -Wilp32 -WIEEE_float",
    cppflags => "",
    defines => [ "OPENSSL_BUILDING_OPENSSL", "OPENSSL_VPROC=\$(OPENSSL_VPROC)", "_XOPEN_SOURCE", "_XOPEN_SOURCE_EXTENDED=1", "_TANDEM_SOURCE", "B_ENDIAN", "_TANDEM_ARCH=3" ],
    disable => [ "threads" ],
    dso_scheme => "DLFCN",
    enable => [ "egd" ],
    ex_libs => "-lrld",
    includes => [  ],
    lflags => "-Wxld=\"-set systype oss\" -Wxld=\"-set floattype ieee_float\"",
    lib_cflags => "",
    lib_cppflags => "",
    lib_defines => [  ],
    module_cflags => "",
    module_cxxflags => undef,
    module_ldflags => "-Wshared",
    perl => "/usr/bin/perl",
    perl_platform => "Unix",
    shared_argfileflag => "-Wxld_obey=",
    shared_cflag => "",
    shared_defflag => "-Wxld_obey=",
    shared_defines => [  ],
    shared_extension => ".so",
    shared_ldflag => "-Wshared",
    shared_rcflag => "",
    shared_target => "nonstop-shared",
    sys_id => "TANDEM",
    thread_defines => [  ],
    thread_scheme => "(unknown)",
    unistd => "<unistd.h>",

Recorded environment:

    AR =
    ARFLAGS =
    AS =
    ASFLAGS =
    BUILDFILE =
    CC =
    CFLAGS =
    CPP =
    CPPDEFINES =
    CPPFLAGS =
    CPPINCLUDES =
    CROSS_COMPILE =
    CXX =
    CXXFLAGS =
    HASHBANGPERL =
    LD =
    LDFLAGS =
    LDLIBS =
    MT =
    MTFLAGS =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL =
    RANLIB =
    RC =
    RCFLAGS =
    RM =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =

Makevars:

    AR              = ar
    ARFLAGS         = qc
    CC              = c99
    CFLAGS          =
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXXFLAGS        =
    HASHBANGPERL    = /usr/bin/env perl
    LDFLAGS         =
    LDLIBS          =
    PERL            = perl
    RANLIB          = ranlib
    RC              = windres
    RCFLAGS         =

NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at the
build file for more exact data:
    Makefile

build file:

    Makefile

build file templates:

    Configurations/common0.tmpl
    Configurations/unix-Makefile.tmpl

Ah, now I understand: egd is explicitly enabled in your configuration:
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/Configurations/50-nonstop.conf#L22
I was confused, because according to my understanding, by default (--with-rand-seed=os) a platform-specific set of seeding options is chosen, whereas if you specify a specific option (list) (--with-rand-seed=rdcpu,...), then only this option(s) would be enabled. Now it seems that configuration options are added, not replaced. Is that correct, @levitte?

Looking at the list of enabled features, all seems fine: both egd and rdrand are enabled, but as we saw in https://github.com/openssl/openssl/issues/20394#issuecomment-1458802703, rdrand is tried first. So it seems like in your case it is failing at runtime.

Try setting the breakpoint at ossl_prov_acquire_entropy_from_cpu().

Ah, now I understand: egd is explicitly enabled in your configuration:
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/Configurations/50-nonstop.conf#L22
I was confused, because according to my understanding, by default (--with-rand-seed=os) a platform-specific set of seeding options is chosen, whereas if you specify a specific option (list) (--with-rand-seed=rdcpu,...), then only this(these) option(s) would be enabled. Now it seems that options from the configuration file are added, not replaced. Is that correct, @levitte?

Can this be legitimately disabled on the ./Configure command using no-egd?

Well, try it ;-)

Just run the configure command, perl configdata.pm --dump will then tell you if it worked.

If it's just for testing, you can also just remove line 22 of 50-nonstop.conf.

If it's just for testing, you can also just remove line 22 of 50-nonstop.conf.

It's funky platform. ia64 only supports EGD while x86 supports rdrand. I might rearrange 50-nonstop.conf a bit if this works.

Building with no-egd seems to do the trick, at least for OpenSSL. I am going to test with git using my test build. If it works out, we will start distributing with this option but leave the 50-nonstop.conf untouched in case others want to build with a richer set of randomizers. I will update the NOTES-NONSTOP.md file under this issue with a discussion of the situation.

I'm glad to hear that it works for you now, although your solution (resp. workaround) does not match with any of my theories. Initially, you wrote that on the target machine seeding failed if the PRNGD was not running:

However, if I do not have PRNGD running, the RAND_bytes seems to not return data correctly.

According to the code, the rdcpu option is tried before the egd, so the logical explanation was that the former option failed and seeding depended on the latter:
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/seeding/rand_unix.c#L713-L722
Now you tell me you solved the problem by disabling egd altoghether. This does not make sense to me and leaves me with the feeling that we still haven't fully understood your problem and just fixed the symptom, not the cause.

I'm glad to hear that it works for you now, although your solution (resp. workaround) does not match with any of my theories. Initially, you wrote that on the target machine seeding failed if the PRNGD was not running:

However, if I do not have PRNGD running, the RAND_bytes seems to not return data correctly.

According to the code, the rdcpu option is tried before the egd, so the logical explanation was that the former option failed and seeding depended on the latter:
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/seeding/rand_unix.c#L713-L722
Now you tell me you solved the problem by disabling egd altoghether. This does not make sense to me and leaves me with the feeling that we still haven't fully understood your problem and just fixed the symptom, not the cause.

I agree that this does not get to the root cause. My current hypothesis is that the lack of initialization from git on the OpenSSL API may be contributing. As far as I can see, git does not invoke any OpenSSL API call except for RAND_bytes(). The curl team has indicated that curl accepts whatever comes from OpenSSL. However, I do not understand the side effects of ossl_seed() being called successfully by curl, and whether that causes a selection of PRNGD.

The curl team has indicated that curl accepts whatever comes from OpenSSL. However, I do not understand the side effects of ossl_seed() being called successfully by curl, and whether that causes a selection of PRNGD.

My understanding is, that libcurl has nothing to do with the problem: If everything works as expected, ossl_seed() will simply return early without doing anything, because the DRBG is already seeded and in a working state, see my previous https://github.com/openssl/openssl/issues/20394#issuecomment-1458543319.

The curl team has indicated that curl accepts whatever comes from OpenSSL. However, I do not understand the side effects of ossl_seed() being called successfully by curl, and whether that causes a selection of PRNGD.

My understanding is that libcurl has nothing to do with the problem: If everything works as expected, ossl_seed() will simply return early without doing anything, because the DRBG is already seeded and in a working state, see my previous #20394 (comment).

Right. But no other initialization of OpenSSL is being done. If there is a requirement to do that, it is missing from git.

Right. But no other initialization of OpenSSL is being done. If there is a requirement to do that, it is missing from git.

That is not true. libcurl inits OpenSSL via the lib/vtls/openssl.c:ossl_init() function.

Right. But no other initialization of OpenSSL is being done. If there is a requirement to do that, it is missing from git.

That is not true. libcurl inits OpenSSL via the lib/vtls/openssl.c:ossl_init() function.

I'm sorry, I'm not a curl internals expert.

Right. But no other initialization of OpenSSL is being done.

@rsbeckerca Since OpenSSL 1.1.1, all initialization (including the seeding of the RNG) are done automatically, there is no action by the application required. Many of the infamous initialization calls are no-ops nowadays and exist only in order not to break old code.

That is not true. libcurl inits OpenSSL via the lib/vtls/openssl.c:ossl_init() function.

This is correct, and it doesn't contradict what I wrote in the previous paragraph, because for OpenSSL 1.1.1 curl just initializes libssl
https://github.com/curl/curl/blob/master/lib/vtls/openssl.c#L1696-L1712
and does not call all those hideous intialization functions anymore
https://github.com/curl/curl/blob/master/lib/vtls/openssl.c#L1731-L1738
and ossl_seed() will not do more than notice that the RNG is already initialized.

Before I get to updating NOTES-NONSTOP.md, one question: If egd and --with-rand-seed=rdcpu are specified, and PRNGD is not running, should OpenSSL ignore errors connecting to PRNDG to move on to the hardware randomizer or is the intent to fail if PRNGD is not running, as we have observed.

The code checks the CPU's RNG first and if that's sufficient (which it always should be), it shouldn't ever check PRNGD at all.  If it does check the PRNGD and it isn't running, it will fail to gather entropy.
It's not clear why you're seeing this manner of failure.

The code checks the CPU's RNG first and if that's sufficient (which it always should be), it shouldn't ever check PRNGD at all. If it does check the PRNGD and it isn't running, it will fail to gather entropy.
It's not clear why you're seeing this manner of failure.

I've been trying to debug that and if I ever get a reasonable trace I will report it .

The code checks the CPU's RNG first and if that's sufficient (which it always should be), it shouldn't ever check PRNGD at all. If it does check the PRNGD and it isn't running, it will fail to gather entropy.
It's not clear why you're seeing this manner of failure.

I've been trying to debug that and if I ever get a reasonable trace I will report it. (insert sigh here)

should OpenSSL ignore errors connecting to PRNDG to move on to the hardware randomizer or is the intent to fail if PRNGD is not running, as we have observed.

The current seeding strategy is as simple as this: try all available sources in a fixed order of preference, until you got enough randomness (aka „entropy“), otherwise fail.

No, that's not correct. The entropy gathering daemon (EGD) is the last option of all. As you can check yourself here on GitHub if you follow the links and look for the OPENSSL_RAND_SEED_... defines.
https://github.com/openssl/openssl/blob/4e5602888da4053f38120dfd0df1c0ac33c967ed/providers/implementations/rands/seeding/rand_unix.c#L713-L722
The following git oneliner shows you all options in the order they are attempted in ossl_pool_acquire_entropy:
git grep -pn -e OPENSSL_RAND_SEED_ providers/implementations/rands/seeding/rand_unix.c

... many lines omitted ...
providers/implementations/rands/seeding/rand_unix.c:623: size_t ossl_pool_acquire_entropy(RAND_POOL *pool)
providers/implementations/rands/seeding/rand_unix.c:625: #  if defined(OPENSSL_RAND_SEED_NONE)
providers/implementations/rands/seeding/rand_unix.c:632: #   if defined(OPENSSL_RAND_SEED_GETRANDOM)
providers/implementations/rands/seeding/rand_unix.c:658: #   if defined(OPENSSL_RAND_SEED_LIBRANDOM)
providers/implementations/rands/seeding/rand_unix.c:664: #   if defined(OPENSSL_RAND_SEED_DEVRANDOM)
providers/implementations/rands/seeding/rand_unix.c:704: #   if defined(OPENSSL_RAND_SEED_RDTSC)
providers/implementations/rands/seeding/rand_unix.c:710: #   if defined(OPENSSL_RAND_SEED_RDCPU)
providers/implementations/rands/seeding/rand_unix.c:716: #   if defined(OPENSSL_RAND_SEED_EGD)
There is also no special error treatment resulting in an early abort of the entropy gathering. In other words, there is no distinction between an entropy source which returns 0 bits of entropy and one that fails, it is simply ignored and the next one is tried.

@mspncp explained it better but that's why I'm completely confuzzled by EGD making a difference.  It shouldn't be queried for entropy.

... that's why I'm completely confuzzled by EGD making a difference. It shouldn't be queried for entropy.

I completely agree with @paulidale, as I already pointed out in https://github.com/openssl/openssl/issues/20394#issuecomment-1461793484:

Now you tell me you solved the problem by disabling egd altoghether. This does not make sense to me and leaves me with the feeling that we still haven't fully understood your problem and just fixed the symptom, not the cause.

... that's why I'm completely confuzzled by EGD making a difference. It shouldn't be queried for entropy.

I completely agree with @paulidale, as I already pointed out in #20394 (comment):

Now you tell me you solved the problem by disabling egd altoghether. This does not make sense to me and leaves me with the feeling that we still haven't fully understood your problem and just fixed the symptom, not the cause.

I agree and am digging further into it.

What we just did a test of OpenSSL 3.0.10 built without no-egd and no PRNGD available that passed 100% on x86, We are going to go back to that configuration and retest git and curl. We have not identified the root cause but the problem seems to be resolved - I will confirm when we have a custom built git and curl with the new 3.0.10 build.

3.0.10 works correctly with git with PRNGD down, just using the hardware randomizer. This looks like it is resolved. Thank you all for the support.


Add copy method to pod pkg

Adds a copy method to the pod pkg which can copy files from one of the pod's containers. Has two options:

With tar - creates a tar archive of a path inside the container (good for copying directories if a container supports it)
Without tar - copies the contents of a single file

/cc @kononovn @vkolodny


Fix LS completions suggestion contains invalid characters

Purpose

Fix LS completions suggestion contains invalid characters

Fixes #17629
Check List

[x] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #17628 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #17628   +/-   ##
=======================================
  Coverage   19.76%   19.76%
=======================================
  Files          51       51
  Lines        1336     1336
  Branches      214      214
=======================================
  Hits          264      264
  Misses       1058     1058
  Partials       14       14

Continue to review full report at Codecov.

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


How to make image blur?

Hello sir, I am using this library and it is working nice. Now i want to make image blur by using this library. Is there any solution for this?
Thank you.

Hi vikashparajuli,
Blurring images is not the goal of this library. You can find some other libraries that may help you here:


Fixed alert-message div's text color.

Added missing commas that were causing alert-message.success text to not be white.

Thank you!

Just an FYI, this change was also merged with pull request #9 from @erikhuisman.


Invert structure of acknowledgements so that we store a hash of ackno…

…wledgements for user ids - enables us to show warning message for every account someone uploads for
This branch shows a warning any time someone tries to upload for someone new whom they are allowed to upload for.
N.B The warning message currently blocks all controls. We may want to enable users to still use the user selector for choosing different person so they don't have to dismiss the message if they accidentally clicked on the wrong user. Not sure if this is thinking it over too much or not though....

I think this is the route we want to go so merging into other branch to look at the diff in one place.


realText in ja_JP

Included the novel called Run,Melos! by Osamu Dazai from Project Aozora Bunko to provide japanese real text.

I'm Sorry. start fresh.


Support libadalang23

I tried to build against libadalang23. That results in a build failure:
extraction-primitive_subps.adb:14:35: error: invalid use of subtype mark in expression or call
extraction-primitive_subps.adb:37:35: error: invalid use of subtype mark in expression or call

Appears that libadalang has changed LALCO.Ada_Type_Decl to a range. I changed Node.Kind = LALCO.Ada_Type_Decl into Node.KInd in LALCO.Ada_Type_Decl. Is this correct?

Libadalang did indeed change Ada_Type_Decl.
Using in instead of = seems indeed the right solution.
We currently have no plans in updating to libadalang 23.0, but we will look into this issue when we will move to a newer version of libadalang.

Of course, the answer it at (the documentation of) libadalang:

if they just divided Ada_Type_Decl up into sub categories then in is correct.
if they added elements to Ada_Type_Decl then = old_element is correct.
if they splitted and added elements to Ada_Type_Decl then in <range of old_elements> is correct

However, in the last two cases, it might be that the dependency graph extractor wanted more elements than libadalang did provide and this change enables that:
in that case in <range of relevent_elements> would be the preferred solution.


: Implementing the isToday functionality of Date.

Checklist

[x] New Extension
[x] New Test
[ ] Changed more than one extension, but all changes are related
[ ] Trivial change (doesn't require changelog)

 : feature/test

          2 Messages

  :book:
  Executed 130 tests, with 0 failures (0 unexpected) in 1.219 (1.486) seconds

  :book:
  Executed 122 tests, with 0 failures (0 unexpected) in 1.496 (1.792) seconds

  Generated by :no_entry_sign: danger

Current coverage is 34.96% (diff: 100%)

Merging #291 into master will increase coverage by 0.12%

@@             master       #291   diff @@
==========================================
  Files            46         46
  Lines          2038       2042     +4
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            710        714     +4
  Misses         1328       1328
  Partials          0          0

Powered by Codecov. Last update 7c988bf...a602670


tests: better coverage across the board

[ ] add integration tests ensuring all the behavior we have outlined in the design spec
[ ] better unit test coverage

adding the good first pr label, because test could be added for any function, big or small, we also have a framework for integration testing where you could easily copy paste another test and change some things to test something else

here is an example of an integration test: https://github.com/golang/dep/blob/master/remove_test.go#L9

if you want to write a test, just write here what you wish to test so no one takes the same one :)

Looks like Context.LoadProject is uncovered.  Any particular reason?  If not, I can work on a unit test for that one after I figure out who you've all set up / torn down test files for os calls in other tests.  Sound okay?

@tro3 no reason for it :) that's be a great help - you'd effectively be codifying some very important rules about how we decide what the boundaries of projects. Thanks!

No problem.  Do you have a doc as to what the intended behavior is, or would you prefer I use the existing code as the "spec" and write tests to cover it and guard against future breakage?

@tro3 nope, no actual spec for it, so best to take code as spec and work from there.
ideally...if you have time 😄 ...you could also write up some docs explaining how it works, so that we can sorta retro-spec it. would ease discussions about it in the future, and/or contribute to the docs that we are sorely lacking

Will do.  One question - I assume the lock file is supposed to always be in the same directory as the manifest?  If so, there is a bug when locating the root while ascending.

I was just working on some initial tests for LoadProject. I can create a PR for that if that's ok, and expand cases from there.

@mem ah, thanks, that'd be great! though it looks like @tro3 is already working on some for LoadProject. Maybe have a look at their PR, see if you can suggest some of those additional cases? Or if not, I'm sure we can find something else :)

Sure, no problem. It was more of an accident. I looked at the open issues, spotted this one and started working on that function just to get a feeling of the code structure, etc. I'll look at the coverage for other functions and post here before writing anything else :-)

No worries, @mem - I just looked at #199 and they could be pulled and not step on each other.  I'll leave it up to @sdboyer.  My PR tonight or tomorrow will also include the ascending bug fix, which I moved to #198, and a (slightly) improved docstring.

I think we're doing much better with this now, especially with the harness. I'm gonna close this out in favor of more specific issues 😄


nrfjprog.py: Fix snr globbing to allow leading 0s

This is needed for sanitycheck hardware maps which take the serial
number directly from USB metadata.
Signed-off-by: Øyvind Rønningstad<EMAIL_ADDRESS>

Without this fix we were not able to run device-testing with hm maps on our platforms. Now the flashing works again


fix error in console

After I change the modalmgr_keys to other key map, every time I trigger the modalmgr_keys, the console shows an error: modal_tray is nill...

I commented out those lines, and forgot to initialize modal_tray.
-- function modalmgr:entered()
    -- modal_stat(white,1)
-- end

Thanks for your contribution.


Copy anndata in metric decorator

It does, but it always did as this is how metrics are run and tested anyway. What is does mean is that if for whatever reason we ever change that, we now need to change it in two places -- but I doubt we would.

Good point about the testing. Agreed that we likely wouldn't change this (in v1 anyway ^^).


Proposal - Add label filters for volume

This is the request from the new change of
https://github.com/docker/docker/pull/21270  which added label for volume

#dibs

ping @thaJeztah  and @vdemeester  Let me know WDYT.  Thanks

Sounds good to me :+1:

@HackToday Sounds good to me, go ahead :wink:

This has been fixed by #25628


Configurable refuseTimeout for offers

I have 120 slaves and want to run app with 90 tasks on unique hosts. Currently it takes about a minute and a half to finish deployment (health checks are involved too), I'd like to deploy much faster. Here's how I see deployment process for a single host now:

Marathon gets an offer, tries to match with pending tasks.
Previous version of the same app is still running on the host, offer declined.
Marathon launches one task on another host, kills task on the host with declined offer.
Marathon gets an offer from the host with killed previous version of the app, launches task.

Host is unused for at least 5 seconds between 2 and 4, that makes deployment slower.
Looks like Mesos has Filters for driver.launchTasks and driver.declineOffer where you can specify the timeout for an offer, but Marathon does not take advantage of this.
I propose to add cli flag --offer_refuse_seconds to Marathon to configure the timeout. I can probably do it myself.
Any thoughts?

I am not quite sure that this should use Filters. Filters actually reduce the offers that we receive from Mesos.
What is required is basically hoarding offers because we expect to be able to use them not now but very soon. Offers that are not declined by frameworks count towards the total resource usage of the framework. Thus a framework is penalized for keeping hold of all resources thus we need to do this smartly.
This is quite a complicated code change, unfortunately.

Filters actually reduce the offers that we receive from Mesos.

message Filters {
  // Time to consider unused resources refused. Note that all unused
  // resources will be considered refused and use the default value
  // (below) regardless of whether Filters was passed to
  // SchedulerDriver::launchTasks. You MUST pass Filters with this
  // field set to change this behavior (i.e., get another offer which
  // includes unused resources sooner or later than the default).
  optional double refuse_seconds = 1 [default = 5.0];
}

Setting this to 1.0 instead of 5.0 should give back refused resource offers sooner. Am I wrong here?

Ok, so basically we are not adding filters but reducing the timeout of existing ones.
I am not sure if Mesos communicates all unused resources whenever they become available or just periodically in a fixed interval. I just asked @tillt  (one of the Mesos core guys) to research that for us.

#1931

Yep, that's implemented. Sorry for not following up on this, @bobrik. Didn't get a response for that and I forgot it.


Arrives at the pokemon but continues without catch it.

Please check configuration at http://jsonlint.com/ before posting an issue.
Expected Behavior
On the map config, moving and arriving at the pokemon and catch it.
Actual Behavior
arriving at the pokemon but, doesn't catch it, just move another target. My bag and pokeballs are okay and the both catches other pokemons regularly.
Steps to Reproduce
catch the the pokemon
Other Information
OS:
Git Commit: (run 'git log -n 1 --pretty=format:"%H"' and paste it here)
Python Version: (run 'python -V' and paste it here)

Enabling snipe temporarily solved my problem.

@PlanetoftheMapes For it doesn't even say  "encountered X", just arrived at X then it continues moving.
Is sniping dangerous for banning?

Same here.
Walking but never catching.

Ok I have fixe it with a good config.
Juste place task "CatchVisiblePokemon" and "CatchLuredPokemon" AFTER "MoveToMapPokemon".
And I have place task "MoveToFort" in last.
This work !
The Bot Walking, Encoutered and catch pokemon.

Hi I had the same issue and I corrected it by reordering the sequence of tasks and by adding the missing parameters from the file config.json.map.example (dev version)
Now it works like a charm =)


⚠ Fortnite has degraded performance

In ceee228, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1572 ms

Resolved: Fortnite performance has improved in d65b996.


test: add more tests to topology spread constraints plugin

Description of your changes
This PR adds more tests to the topology spread constraints plugin.
I have:

[x] Run make reviewable to ensure this PR is ready for review.

How has this code been tested
N/A
Special notes for your reviewer
A minor part of this PR overlaps with another test PR.

 Will retry tomorrow.

Thanks, @Arvindthiru!


Keyword arguments to Proj() are silently ignored when projparams are specified

I came across this when trying to initialize a Proj() and include geoidgrids:
proj = pyproj.Proj('EPSG:3162', geoidgrids='CGG2013an83.gtx')
proj.crs.is_vertical
>>> False

This is confusing.  Why is it not taking my geoidgrids?  Did I get the file name/path wrong?
Turns out the positional argument projparams is mutually exclusive with any passed **kwargs:
https://github.com/pyproj4/pyproj/blob/632c39818e77f8226bbec0db2a3fbe7fc02f7d33/pyproj/proj.py#L143
Yet there is no indication that this is not a valid way to initialize it.
In my opinion it should throw an exception, and it could perhaps be made clearer in the documentation as well.  It's a minor user experience thing, but still something I had to spend time troubleshooting.  Happy to attempt a PR if others agree.
(stackexchange thread that spawned this)

Happy to attempt a PR if others agree.

I think that would be a nice addition. A PR would be welcome 👍

@gberardinelli are you still interested in attempting this fix?

Thanks for the reminder, proposed my dinky lil' change with https://github.com/pyproj4/pyproj/pull/570
I wasn't sure if it would be appropriate to attempt to merge projparams and kwargs, but that could be another option if so (within the CRS object?)

Thanks for getting started on this :+1:

I wasn't sure if it would be appropriate to attempt to merge projparams and kwargs, but that could be another option if so (within the CRS object?)

It wouldn't hurt. If it is invalid, PROJ will raise an exception. So, if you would like to make that change, I would do it in the CRS.__init__ method.

I gave it a shot but I'm not really sure what I'm doing at this point, feels a bit kludgey.  Tests in test_proj all pass...

Looks good. Mind adding a test for the CRS class as well?


New folder for data without page breaks

Once we address page breaks (issue #3) we want to create a new data folder for each chapter with no page breaks

Done via https://github.com/STAT325-S24/HistoryAmherstCollege/commit/86fee17332ad2bcee8cff27e4c77cca86384f1eb


Alignment issue

The output results have an alignment issue.
I'm going to fix it as soon as it's possible.

The issue fixed.