Acces cookie data fetched from request

Cannot find a way to access the cookie data fetched from the request made ,
If vmod_reqwest does not support it please let me know how can I accomplish the same using any other vmod
I am using the below syntax for making the API call :
new client = reqwest.client();
        client.init("get_visitor_id", "URL");
        client.send("get_visitor_id");

Hi,
there's the .get_header() method you can use: https://github.com/gquintard/vmod_reqwest/blob/main/vmod.vcc#L78-L80
You'd use it like this:
        client.init("get_visitor_id", "http://api.example.com");
        client.send("get_visitor_id");
        set req.http.my-cookie = client.header("get_visitor_id", "set-cookie");

please let me know if that solves your need

But I have multiple Set-Cookie key value pairs and it picks only the first one and ignores the rest
Is there a way all the values can be extracted and then set to the cached response

Ah, you are correct! I will add a way to collect all the headers
On Wed, Feb 22, 2023, 00:02 Aadarsh Verma @.***> wrote:

But I have multiple Set-Cookie key value pairs and it picks only the first
one and ignores the rest
Is there a way all the values can be extracted and then set to the cached
response
—
Reply to this email directly, view it on GitHub
https://github.com/gquintard/vmod_reqwest/issues/5#issuecomment-1439580822,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA42AKNNFNCG6RDP3GW2BGDWYXB2LANCNFSM6AAAAAAVDHPU74
.
You are receiving this because you commented.Message ID:
@.***>

Thanks a Lot !!!
Can u give an estimate by when you can add that function so that I can look for another solution or wait as per my timeline.

most probably this weekend, it's just a matter of:

updating vmod.vcc to add a collect argument, or similar
teach .header() to watch out for more than one item
write some tests

not a huge time investment, I just need to find a slot. Alternatively, if somebody on your side wants to get their feet wet with rust, I'll happy to mentor and/or review a PR ;-)

@Aadarsh-Verma, please have a look at the latest main commit (https://github.com/gquintard/vmod_reqwest/commit/6d7d53a6e7c00f1920b1b96261743b814bce5743), you can now specify sep to tell vmod_reqwest to collect the headers in a single string. I assume in your case that should be something like
        client.init("get_visitor_id", "http://api.example.com");
        client.send("get_visitor_id");
        set req.http.my-cookie = client.header("get_visitor_id", "set-cookie", sep = "; ");

please let me know if that covers it, and of course reopen this issue if it doesn't

Using This Dockerfile
`
FROM rust:1.61-buster
WORKDIR /vmod_reqwest
ARG VMOD_REQWEST_VERSION=0.0.6
#ARG RELEASE_URL=https://github.com/gquintard/vmod_reqwest/archive/refs/tags/v${VMOD_REQWEST_VERSION}.tar.gz
ARG RELEASE_URL=https://github.com/gquintard/vmod_reqwest.git
RUN curl -s https://packagecloud.io/install/repositories/varnishcache/varnish72/script.deb.sh | bash && apt-get update && apt-get install -y varnish-dev clang libssl-dev git
RUN git clone https://github.com/gquintard/vmod_reqwest.git &&
cd vmod_reqwest &&
cargo build --release
FROM varnish:7.2
COPY --from=0 /vmod_reqwest/target/release/libvmod_reqwest.so /usr/lib/varnish/vmods/
USER root
RUN apt-get update && apt-get install -y net-tools curl`
Getting the error below :
#10 112.7   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/varnish-0.0.14/src/vcl/backend.rs:73:5
#10 112.7    |
#10 112.7 73 | use std::ffi::c_char;
#10 112.7    |     ^^^^^^^^^^^^^^^^ no c_char in ffi
#10 112.7
#10 112.7 error[E0432]: unresolved imports std::ffi::c_char, std::ffi::c_uint
#10 112.7  --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/varnish-0.0.14/src/vcl/ctx.rs:3:16
#10 112.7   |
#10 112.7 3 | use std::ffi::{c_char, c_uint, c_void};
#10 112.7   |                ^^^^^^  ^^^^^^ no c_uint in ffi
#10 112.7   |                |
#10 112.7   |                no c_char in ffi
#10 112.7
#10 112.7 error[E0432]: unresolved imports std::ffi::c_char, std::ffi::c_uint
#10 112.7   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/varnish-0.0.14/src/vcl/http.rs:15:16
#10 112.7    |
#10 112.7 15 | use std::ffi::{c_char, c_uint};
#10 112.7    |                ^^^^^^  ^^^^^^ no c_uint in ffi
#10 112.7    |                |
#10 112.7    |                no c_char in ffi
#10 112.7
#10 112.7 error[E0432]: unresolved imports std::ffi::c_char, std::ffi::c_int
#10 112.7  --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/varnish-0.0.14/src/vcl/processor.rs:8:16
#10 112.7   |
#10 112.7 8 | use std::ffi::{c_char, c_int, c_void};
#10 112.7   |                ^^^^^^  ^^^^^ no c_int in ffi
#10 112.7   |                |
#10 112.7   |                no c_char in ffi
#10 112.7
#10 112.7 error[E0432]: unresolved import std::ffi::c_char
#10 112.7   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/varnish-0.0.14/src/vcl/ws.rs:13:16
#10 112.7    |
#10 112.7 13 | use std::ffi::{c_char, c_void};
#10 112.7    |                ^^^^^^ no c_char in ffi
#10 112.7
#10 112.9 For more information about this error, try rustc --explain E0432.
#10 112.9 error: could not compile varnish due to 5 previous errors
#10 112.9 warning: build failed, waiting for other jobs to finish...
Attatched the whole build result over here :
https://paste.sh/ZkTLMY99#uoiLk9mGcO7anYlVtlonunut
Let me know if I am doing something wrong

thanks, that's interesting, I can reproduce with your Dockerfile, but not on my machine. It's possible a cargo version issue or something

confirmed, if you change your first line to FROM rust:1.67-buster you should be fine.
I'll keep this issue open until you can confirm

Thanks a lot !!! This is working fine I am not facing the compilation errors on updating the rust version
However there is a small change
`
FROM rust:1.67-buster
WORKDIR /vmod_reqwest
ARG VMOD_REQWEST_VERSION=0.0.6
#ARG RELEASE_URL=https://github.com/gquintard/vmod_reqwest/archive/refs/tags/v${VMOD_REQWEST_VERSION}.tar.gz
ARG RELEASE_URL=https://github.com/gquintard/vmod_reqwest.git
RUN curl -s https://packagecloud.io/install/repositories/varnishcache/varnish72/script.deb.sh | bash && apt-get update && apt-get install -y varnish-dev clang libssl-dev git
RUN git clone https://github.com/gquintard/vmod_reqwest.git &&
cd vmod_reqwest &&
cargo build --release
FROM varnish:7.2
#COPY --from=0 /vmod_reqwest/target/release/libvmod_reqwest.so /usr/lib/varnish/vmods/
COPY --from=0 /vmod_reqwest/vmod_reqwest/target/release/libvmod_reqwest.so /usr/lib/varnish/vmods/
USER root
RUN apt-get update && apt-get install -y net-tools curl`
the libvmod_reqwest.so file is in this directory /vmod_reqwest/vmod_reqwest/target/release/libvmod_reqwest.so
instead of the directory mentioned in the official Dockerfile

Also needed your help with something related to varnish
I am trying to make varnish ignore headers and cookies from including in the hash_data without unsetting them
but I cannot find any solution for the same , Can u suggest a documentation that I can go through that would help me
Also a platform where I can discuss the issues that I am facing generally on varnish

ah, thanks, changing WORKDIR /vmod_reqwest to WORKDIR / should fix the issue, but I'll check and correct, thank you for reporting it.
Does the new function work as expected?
Regarding hashing, that should be fairly easy as adding anything to the hashing key is done explicitly via hash_data (https://varnish-cache.org/docs/trunk/users-guide/vcl-hashing.html), so you don't need to unset the header, just to not call hash_data on it. If I'm not making any sense, I'd be happy to discuss that over on the discord channel (https://varnish-cache.org/support/). I'm in the PST timezone, so our schedule may not match, but there are plenty of good folks ready to help

Does the new function work as expected?
yes it's working as expected.


add change line to make output clear

make output clear
# ./clusteradm upgrade clustermanager
clustermanager installed. starting upgrade
upgraded completed successfully

Signed-off-by: jichenjc<EMAIL_ADDRESS>

/approve
/lgtm

/retest

/lgtm


Get Homebrew ruby on path?

To get doc building working right on Mac under the Matlab Desktop GUI, we'll probably need to pull in Homebrew, because it's the Ruby that'll have bundler.

This is tricky. The way to do this would be to check if bundler is installed and ruby is a new enough version, and if not, then search for a Homebrew installation and add that to $PATH with setenv().
Maybe we should just show users how to pull in Homebrew using their startup.m?

This is tricky. The way to do this would be to check if bundler is installed and ruby is a new enough version, and if not, then search for a Homebrew installation and add that to $PATH with setenv().
Maybe we should just show users how to pull in Homebrew using their startup.m?

I added a dev-kit/pull_in_homebrew_ruby.m that developers can call manually. I'm not comfortable calling it automatically yet.

I added a dev-kit/pull_in_homebrew_ruby.m that developers can call manually. I'm not comfortable calling it automatically yet.


isNotRedirectedResponse function is used without an argument

https://github.com/NekR/offline-plugin/commit/fbdd643f9886ed4f3563b5e433f6aad3922ede60#diff-1d7b31069861fdf22fcaeba0f48ba565R559

@Tuch
https://github.com/NekR/offline-plugin/releases/tag/v4.9.1
https://github.com/NekR/offline-plugin/releases/tag/v5.0.0

@NekR good job, and thank you :thumbsup: :thumbsup: :thumbsup:


Reset live stream duration player

I have a project play video stream from a Television station and I have 2 components, 1 component for play video in Main Application and 1 component to work with fullscreen player. In the main application when I click to go to Fullscreen in Main Component it will pause video in this component and run in Fullscreen Component. Now when I back Main Component I want this video player is reset and player duration same the Fullscreen before. Has any method function or props can do it?
Thanks for reading and sorry for my bad English.

@ducchungtx Do you find any Solution??

@ducchungtx Do you find any Solution??


Ignore a class in evaluation. and train

I am trying to use ignore class in train and eval of the network. but class_indexes is not in iou_score and jaccard_loss?

Solved by Update


this.el.width is not a function

I am using Grafana 3.1.1 and installed version 0.1.7 of this plugin with the grafana-cli command.
I can create a new heatmap panel and it graphs everything ok when I first create it. When I switch between two different dashboards, the heatmap panel is blank and gives the "this.el.width is not a function" error. If I refresh the browser window, then the heatmap shows up.
I am using an OpenTSDB data source.

Sorry for late response...
The error might be occurred in epoch library.
Please tell me your environment. (OS, browser, etc.)

I looked a little bit into it too, and it also looks like a problem in the epoch library to me.
Grafana is running on CentOS 7, and I am accessing it with firefox on fedora 22.
After playing with it some more, I've found that refreshing sometimes doesn't work, and occasionally the heatmap panel will come up ok when changing dashboards. The issue is difficult to reproduce consistently but it comes up often enough to be a problem.


$ElementType does not typecheck

The following code
type State = {
  app1: {stateApp1: string},
  app2: {stateApp2: string},
  app3: {stateApp3: string}
}

const extractProp= <K: $Keys<State>>(propName: K, state: State): $ElementType<State, K> =>{
 return  state[propName]
}

does not type check. Am I missing something or there is a problem in Flow?
on flow.org/try  $ElementType<State, K> resolves to
{stateApp1: string, stateApp2: string, stateApp3: string}

should it not be something like the following?
 {stateApp1: string} | {stateApp2: string} | {stateApp3: string}

This sounds really similar to #4211.

It looks like this issue explains the expected behaviors for most use cases (for example set method for immutable object). Really looking forward to get this fixed.

Duplicate of #4211.


Adding multiple skip connections

I am trying to create RNNs where each node has (possibly multiple) skip connections to nodes multiple time steps apart . Could someone explain how I can modify the computation of the hidden state (h_t) to take into account all previous hidden states multiplied by a suitable sparse vector ?
Thanks

@akshay13ml That is a bit complicated to implement. You might be able to do something like that by nesting RNNs. Here is an example : https://github.com/Element-Research/rnn/issues/229 (although not exactly what you want). Another possibility is to build your own module. To do this for LSTMs, I would recommend starting from SeqLSTM, subclassing and modifying it to suit your needs. It all depends on what exactly you want to do as some use-cases could be built as a Module outsize the LSTM (like NormStabilizer which is applied between LSTMs in a stack).


Add octet-stream (PEM and DER) and x-pkcs7-certificates to unpack_cert_content

This PR addresses the issues previsouly discussed about nonstandard URL references in the Authority Information Access field of x509 certificates.
PS: I found a TLS certificate using x-pkcs7-certificates so I decided to add it as well, despite being deprecated.

Hi @fredericoschardong,
Thanks! I made a couple further changes:

Moved the test to test_registry.py and only test path building instead of full validation (we're working with a bunch of "real" certs with relatively short lifetimes, so this makes the test easier to maintain)
Changed the order of the branches so that the PKCS#7 DER case is evaluated first. This didn't matter previously because there was no overlap between the content type groups, but since application/octet-stream is in several groups, we have to be a bit more careful.
General cleanup to make the code easier to merge.

If you're OK with these changes I'll squash them and merge them into the master branch, while also keeping them around for a potential 0.19.7 release.

Thank you, @MatthiasValvekens.
Because we are no longer bound by SSL certificates, I added the certificate that triggered this PR. In addition, I converted the certificates to DER to make the loading procedures easier.
Please let me know if you want anything changed. Everything appears to be in order to me.

I squashed your commit and merged it into master with modifications for the changes to the API & test setup over there. Thank you!
I'll probably do at least one more patch release on the 0.19.x branch before releasing the work that's currently on master, hence why I asked to branch off this earlier tag. Is this issue currently blocking you?

I'll probably do at least one more patch release on the 0.19.x branch before releasing the work that's currently on master, hence why I asked to branch off this earlier tag. Is this issue currently blocking you?
EDIT: I figured I might as well release 0.19.7 right now. I've also updated the dependency in pyHanko, but haven't released that one yet. Can be arranged if it's a blocker for you, though. I just about have enough material for a (small) minor version bump over there.

Yes, it is blocking me. I would greatly appreciate it if you could make a new release (of pyHanko) that incorporates our changes.


Added LinearSVC_Scale_PolynomialFeatures

update model accuracy description below model.score
it has description for r2,mae and mse which are for regression problems


Support for Korean language fine-tuning

First of all, thank you for sharing such a good reference.
I'm wondering if Korean language fine-tuning is supported in this project. I see that Chinese (zh) language fine-tuning is supported, but I'm not certain about Korean support.
If Korean is not yet supported, would it be possible to add support for Korean language fine-tuning as well? I believe expanding the language coverage would be beneficial for Korean users who want to fine-tune models with Korean datasets.
I might have missed existing documentation or implementation about Korean support. If it's already supported, could you point me to the relevant documentation?

It is supported. Just do the same steps as other languages.
And for languages except Chinese we do not extract Bert features, so 3-bert will be an empty folder

I couldn't proceed with the training due to my misunderstanding of the guide, but now the issue has been resolved and I've confirmed it's working properly. Thank you.


clean grpc response

Summary
clean grpc response
Purpose
avoid having content in the return value that duplicates the content of the error.
Contents
erase message and is_ok in  the return value of responses
Testing Methods Performed
make test t=./manage_container p=medium

@sakamoto-souta
Please rebase this branch to latest main branch:  5d0d080e65fbacb14eb8ed9a5e5d8e86d11ecba4 :bow:


check-log-newlines: Check only the cilium repo.

The script checked everyting under github.com and failed for non-related code. Start the check on the current directory instead of backing up by two levels, since the script is run by make in the main cilium directory.
Signed-off-by: Jarno Rajahalme<EMAIL_ADDRESS>

test-me-please

test-me-please

test-me-please


Add _maxCommitmentAge check in constructor to ensure _consumeCommitment is working.

close #120

Your analysis is incorrect; a large maxCommitmentAge will not result in an error here.


[FLINK-19594][web] Make subtask index start from zero

What is the purpose of the change
This pull request modified web ui subtasks starting index from 0, which can make consistent in the REST API.
Brief change log
*modify web ui subtasks starting index, remove +1 syntax
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Documentation
This pull request doesn't introduce a new feature.

@flinkbot run azure

Thanks for your contribution, @zlzhang0122 Could you please paste the new web UI pictures here after applying your changes?

Thanks for your contribution, @zlzhang0122 Could you please paste the new web UI pictures here after applying your changes?

Sure.

The changes LGTM, @zlzhang0122 could you squash your commits as single one commit?
I noticed that you have one commit to modify the time format and the other two commits to merge branch when I plan to merge your code.
BTW, I think [FLINK-19594][web] Make subtask index start from zero could be a better title.

The changes LGTM, @zlzhang0122 could you squash your commits as single one commit?
I noticed that you have one commit to modify the time format and the other two commits to merge branch when I plan to merge your code.
BTW, I think [FLINK-19594][web] Make subtask index start from zero could be a better title.

@Myasuka Thanks for your reply, I have finished it.

@zlzhang0122 Could you rename your commit title also as [FLINK-19594][web] Make subtask index start from zero? We don't have component as [flink-runtime-web]. Moreover, don't leave spaces between [FLINK-19594] and [web].

[FLINK-19594][web] Make subtask index start from zero

Sure.

@zlzhang0122 Could you rename your commit title also as [FLINK-19594][web] Make subtask index start from zero? We don't have component as [flink-runtime-web]. Moreover, don't leave spaces between [FLINK-19594] and [web].

Sure.


Android: Unexpected token '.' (http://<IP_ADDRESS>:8081/index.delta?platform=android&dev=true&minify=false:88794) at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)

package.json

{
"name": "Simple",
"version": "0.0.1",
"private": true,
"scripts": {
"start": "node node_modules/react-native/local-cli/cli.js start",
"test": "jest"
},
"dependencies": {
"react": "16.3.1",
"react-native": "0.55.4",
"react-native-actionsheet": "^2.4.2",
"react-native-communications": "^2.2.1",
"react-native-device-info": "^0.21.5",
"react-native-fbsdk": "^0.7.0",
"react-native-fcm": "^15.0.0",
"react-native-google-maps-services": "^0.5.1",
"react-native-huawei-protected-apps": "^0.1.7",
"react-native-image-crop-picker": "^0.20.1",
"react-native-root-toast": "^1.3.0",
"react-native-vector-icons": "^4.6.0",
"react-navigation": "^2.0.1"
},
"devDependencies": {
"babel-jest": "22.4.3",
"babel-preset-react-native": "4.0.0",
"jest": "22.4.3",
"react-test-renderer": "16.3.1"
},
"jest": {
"preset": "react-native"
}

}

Error log

05-19 01:26:21.529 15124-15142/com.harrybui.simple E/FA: Discarding data. Failed to send app launch
05-19 01:26:21.530 15124-15142/com.harrybui.simple E/FA: Failed to get app instance id
05-19 01:26:21.530 15124-15142/com.harrybui.simple E/FA: Discarding data. Failed to send event to service
05-19 01:26:21.530 15124-15142/com.harrybui.simple E/FA: Failed to send current screen to service
05-19 01:26:24.748 15124-15209/com.harrybui.simple E/ReactNativeJNI: Got JS Exception: Unexpected token '.' (http://<IP_ADDRESS>:8081/index.delta?platform=android&dev=true&minify=false:88796)
05-19 01:26:24.749 15124-15209/com.harrybui.simple E/unknown:ReactNative: Exception in native call from JS
com.facebook.react.devsupport.JSException: Unexpected token '.' (http://<IP_ADDRESS>:8081/index.delta?platform=android&dev=true&minify=false:88796)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:154)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192)
at java.lang.Thread.run(Thread.java:761)
Caused by: com.facebook.jni.CppException: Unexpected token '.' (http://<IP_ADDRESS>:8081/index.delta?platform=android&dev=true&minify=false:88796)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:154)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192)
at java.lang.Thread.run(Thread.java:761)
05-19 01:26:24.751 15124-15209/com.harrybui.simple E/unknown:ReactNative: Exception in native call
java.lang.RuntimeException: Error calling AppRegistry.runApplication
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:154)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192)
at java.lang.Thread.run(Thread.java:761)
Caused by: com.facebook.jni.CppException: Could not get BatchedBridge, make sure your bundle is packaged correctly
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:154)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:192)
at java.lang.Thread.run(Thread.java:761)
05-19 01:26:31.548 15124-15142/com.harrybui.simple E/FA: Discarding data. Failed to send event to service

I run command
adb reverse tcp:8081 tcp:8081 & react-native run-android
then it worked on debug but when build release apk, app crashed

Im getting the same error but on index.android.bundle

same error! How to fix this?

Same error—showstopper. Would love some assistance, please.

I'm fixed this issues
this error of react-native-google-maps-services

change index.js in node_modules/react-native-google-maps-services/lib/index.js
exports.createClient = function(options)
to
export function createClient(options)
using it

import {createClient} from 'react-native-google-maps-services'
var googleMapsClient = createClient({
  key: 'your API key'
});

if you using google-maps-services-js, you can fix as same

Any fix, update, workaround, something that could help prevent this issue?
Thanks!

I encounter the error too. Then I start "Remote JS Debugging" and the error disappear.

Same error here. Anyone solved this?

As I understand it, the root of these sort of problems is explained here.
More specifically when it says (bold is mine):

When using React Native, you're going to be running your JavaScript code in two environments:

In most cases, React Native will use JavaScriptCore, the JavaScript engine that powers Safari. [...]
When using Chrome debugging, all JavaScript code runs within Chrome itself, [...]. Chrome uses V8 as its JavaScript engine.

While both environments are very similar, you may end up hitting some inconsistencies.

So, the confusing part about getting an error if the debugger is closed and not getting it when the debugger is running may be explained by that.
Also consider the syntax error is found by the JavaScript engine itself in the bundle and not by the compiler/bundler in your source code, so that is the reason why the line number mentioned in the error message might not correspond to any of your source files. I think in general these errors are caused by some dependency package not being strictly transpiled ES5 code, so it will run in some environments and not in others.
What I've found useful in such scenarios is generating the bundle manually running something like
react-native bundle \
    --platform android \
    --dev true \
    --entry-file index.js \
    --bundle-output android-debug.bundle \
    --sourcemap-output android-debug.bundle.map

And then in the generated android-debug.bundle file looking at the line number mentioned in the error message (88794 in the OP screenshot). There you should find the offending code.

@pablen more details please
after running this command  it says 'Assets destination folder is not set'

I upgraded "react-native-elements" from "0.19.0" to "1.10" then i had this problem. I had revert back to "0.19.0" then my app works fine. I did as @pablen said, but i still not found the problem.


add image asset for joystick.club (JOY)

added 0x6732E55Ac3ECa734F54C26Bd8DF4eED52Fb79a6E.png image asset to resolve broken image

Sorry didn't see this PR, and this icon has been added already. =)


strict mode

different solution for #2

This has been open for awhile, not sure what it's solving, nobody seems to have complained about this module so far even though the CORS settings are not strict. Closing for now.


Changes the name of the page Author

👷 Deploy Preview for boisterous-yeot-072e28 processing.

Name
Link

🔨 Latest commit
c8473cf021fdc5ab43246ed5b4c90f22724ac5fd

🔍 Latest deploy log
https://app.netlify.com/sites/boisterous-yeot-072e28/deploys/642cb11ac3e1e400081c39e1


How to add images from RSS feed?

I'm currently using the rss feed and I'm populating it via my wordpress blog. The feed content shows up wrapped in the p class social-feed-text, but the image does not. I have added a featured image to my rss using a custom wp function, it's been tested and it works. (tested on http://www.feedbucket.com/ )
Looking at the structure of the way the RSS is setup in jquery.socialfeed.js it looks like an image attachment is there but it doesn't get attached to the social-feed-element div.
                        if (options.show_media && element.mediaGroups ) {                             post.attachment = '<img class="attachment" src="' + element.mediaGroups[0].contents[0].url + '" />';                         }
Is there a custom variable I should be adding somewhere?

hi, i did a Pull request with a new RSS implementation here https://github.com/pavelk2/social-feed/pull/224

@HartLarsson This worked perfectly thanks!
closed

I'm glad you liked the version ;)


Why does it flag default security groups as EC2 Classic resources?

I ran the script, and it picked out one region to give something unusual.
Most of the CSVs are empty, except for Classic_Platform_Status.csv and Classic_SGs.csv ; so I found that Classic_SGs.csv contains a solitary security group named "default" in us-east-1, whereas I have no other resources in that region.
I saw that there is a closed issue (#18 ) where the person requested for more info on how to deal with such reports of a default security group being included in Classic_SGs.csv for no apparent reason.
Could the script be fixed instead to not include these default security groups in Classic_SGs.csv ? I don't understand why it doesn't include the default security groups in other regions, but only this particular region?
I also have a related stackoverflow question about this: https://stackoverflow.com/questions/69787759/ec2-classic-resource-that-cant-be-deleted-now-what?noredirect=1#comment123433839_69787759

Hello, the security groups are more just resources you should be aware of as your migrating, but they are not active resources, and thus are not going to be impacted when disabling classic, only active resources which may use those security groups would be affected.


[UI] Catalog apps items are displayed to big with >6 open ports.

Rancher versions:
rancher/server or rancher/rancher: v2.0.5
Docker version: (docker version,docker info preferred)
Containers: 3
Running: 1
Paused: 0
Stopped: 2
Images: 2
Server Version: 17.03.2-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.0-6-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.911 GiB
Name: SomeName
ID: [....]:[....]:[....]:[....]:Z66R:DK7T:OSMO:CPMD:[....]:[....]:[....]:[....]
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false
Operating system and kernel: (cat /etc/os-release, uname -r preferred)
Kernel Version: 4.9.0-6-amd64
Operating System: Debian GNU/Linux 9 (stretch)
Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)
Bare-metal
Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single Node
Environment Template: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:
Launch Catalog App with more than 6 open ports
Results:
The "ember-view"-container is displayed to big, if there are a lot of ports open on the catalog app.

I spoke with @tfiduccia regarding this issue. She QAd it as much as she could, but we are going to leave it open and sync with @kohlerdominik once the release is out to see if it addresses their specific environment.

Im going to move this to the next milestone since the final validation will happen post release.

@kohlerdominik - We added wrapping to 2.0.7.  Can you please check your helm chart to see if the newest release resolves your issue.

Looks fantastic now! Thanks.


Update installation instructions for newest release

@georgebrock is INSTALL supposed to be committed to the repo?

@mike-burns Yes, we commit it so that we can refer to it in the README, and link to it on GitHub.

Thanks for this. Rebased onto master, and merged as 4c8a7b8bcadb45b9bb04b71437080285f15b69dd


StatusSucceeded is not anymore related to update_status with 100%

Overview
StatusSucceeded is not anymore related to update_status with 100%, which could be set by the user.
Related Issue / Discussion
#171
Additional Information
Contribution Agreement
(as per https://github.com/geopython/pywps/blob/master/CONTRIBUTING.rst#contributions-and-licensing)

[ ] I'd like to contribute [feature X|bugfix Y|docs|something else] to PyWPS. I confirm that my contributions to PyWPS will be compatible with the PyWPS license guidelines at the time of contribution.
[x] I have already previously agreed to the PyWPS Contributions and Licensing Guidelines

Coverage decreased (-0.07%) to 76.524% when pulling a192ee88bbaf7b50fc4004b0f27ab6607014e3da on jonas-eberle:master into 31c7b142ec48c4e38dacdcdacbecea3d9a4b0627 on geopython:master.


MINOR: Enable testUpdateFeaturesWithForwarding

More detailed description of your change
This test was removed in #11667 since UpdateFeatures is not properly handled in KRaft mode, now we can bring it back since UpdateFeatures is properly handled after #12036.
Summary of testing strategy (including rationale)
No
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

ping @mumrah

Looks good to me!

@dengziming , could you rebase this branch to the latest trunk branch? I'd like to check the test result. Thanks.

Let's wait for the test results :)

Failed test is unrelated.
Build / JDK 11 and Scala 2.13 / org.apache.kafka.connect.integration.ExactlyOnceSourceIntegrationTest.testConnectorBoundary


No FDP values for a dataset of 400,000 precursors

Hi,
The FDP calculation at the precursor level for from a proteogenomic search consisting >400,000 peptide precursor is resulting with only zero values. I am not able to figure out the issue here. I tried to do the same with precursors with 0.01 < q-values > e7, which comprises just over 250,000 peptide precursors. Still the resulting FDP is zero for all the peptides.
Could you please tell me why it is so, is there are issue with the input file. However, I have not faced any major errors or warnings.
The peptide_precursor.tsv and entrapment_pep.txt files are available in the below OneDrive link for your reference. Let me know if you need more information.
https://qubstudentcloud-my.sharepoint.com/:u:/g/personal/3058937_ads_qub_ac_uk/ESy8UHLFdyxJpfJuB0PyySEBVO5ybStIWE8t7AzLFzFvtg?e=YhFTx6

Hi Bo,
Here is the command line used for executing the precursor level FDP
>java -jar fdrbench-0.0.1.jar -i peptide_precursor.tsv -fold 1 -pep entrapment_pep.txt -level precursor -o peptide_precursor_FDP.csv -score "score:0"
Are you expecting that the command line or arguments used causing any issue here?
Chinmaya

Hi Bo,
As I tried to execute the FDRBench with smaller dataset, I faced the similar problem.
Here, I am using my python script to change the format of the Spectronaut exported precursors list to FDRBench compatible input format. The python script mainly calculates the score by sorting EG.Cscore and adds this new column to the file.
In the meantime, I also created the same input file by manually sorting the file in excel and submitted that as input.
Surprisingly, the providing excel formatted input file gives the an output with FDP values from FDRBench, whereas the output generated for the python script formatted input file results only with zeros as FDP.
I have attached the input file in both the formats. Does the issue lies with the FDRBench in recognizing python output correctly or is there any issues with the python script I generated?
I have shared everything here for your reference.
https://qubstudentcloud-my.sharepoint.com/:u:/g/personal/3058937_ads_qub_ac_uk/EVvxLwwVWNdBhQPegu7dwM4B7lvxeKk8dleVVHngo4C8Ww?e=RhZoy0
Chinmaya


Proposal approved without the required votes

The proposal Analysis of Two tokens on Neo Economy had 3 votes and was approved. It needed 4.

@lock9 thanks for opening an issue. 👍
This is a valid question, but it seems that the "abstention" mechanism is little or not understood by the majority of people.
Go to our new "Parameters" page: https://grantshares.io/app/parameters
There, read the sections "Default and Minimum Acceptance Rate" and "Default and Minimum Quorum".
Basically, how this thing works is as follows: abstention counts in the quorum, and the minimum acceptance rate is based on ALL casted votes.
In this case, if the proposal had 3 members casting "abstain" and 3 members casting "accept", the proposal would be rejected.
If you don't have any other questions about this specific subject please close the issue. Thanks!

That doesn't make any sense, but I don't care.

@lock9 This system is not something new. We didn't come up with this out of the blue, i.e., we didn't reinvent the wheel. 😄
For example:

Abstentions do not count in tallying the vote negatively or positively; when members abstain, they are in effect attending only to contribute to a quorum.
-- Abstention. (2022, October 6). In Wikipedia. https://en.wikipedia.org/wiki/Abstention

You can read about it in other places.
But, yes, we have some changes to be made on the endorsement part in order to exclude the min. quorum variable. We're still debating about this change, though.
We'll be curious to know your ARGUMENTS about what you wrote:

That doesn't make any sense, but I don't care.

@lock9 so, can you point us out why it doesn't make any sense?

Just for documentation purposes:
@lock9 is confusing concepts and mixing things up.
Indeed, abstention must be contrasted with blank votes. Right.
BUT, there's no way to take abstentions into account without a transaction.
Again, taken from the article:

when members abstain, they are in effect attending only to contribute to a quorum.

In summary: abstentions (as a tx) should not count in the final acceptance BUT should contribute to a quorum. 😄

Not endorsing Rick's attitude here, but I do understand where he is coming from.
A majority vote between 50 people requires 26 votes. If 10 of those voters abstained, the total number of voters is decreased to 40, and the majority required among remaining voters becomes 21. The abstains are still contributing to quorum. They are doing so by lowering the threshold to pass the motion. But their impact on the result is halved: 10 abstains only decreases the pass threshold by 5 votes.
Applying the above to the case in question, we had 9 voting members and two abstains, so the vote result would be 3/7. Since the current mechanism is essentially considering the abstain as a full vote, rather than accounting for its reduced impact, it pushed this proposal over the edge.
I think I would agree with Rick that it's more intuitive for abstention to reduce the size of the voter pool. As is, abstention is no different from a yes vote in terms of its impact on an outcome.
Side note: This proposal was an edge case. With better voter participation, we wouldn't have encountered it so early, so I think addressing that should remain our primary concern.

@EdgeDLT sure, I agree with you and your reasoning. 👍
That's not how things work now in GrantShares given that this governance model was showed and agreed in several meetings.
What we're working on, right now, is to slightly change the dynamic of the endorser/endorsement and remove the necessity for a min. quorum. Then, it's debatable if we should remove the "abstantion" voting type, but I would keep it to demonstrate that a member is "aware" of the proposal -- but simply can't (or don't want to) express an opinion.
We're still working on the concept. More details to come in the coming weeks/end-of-year. 😄

Hello,
I am writing to apologize for my recently displayed aggressive and shameful behavior. Nothing justifies this kind of attitude, even if I strongly disagree with something.
Out of all the communities we have in the ecosystem, AxLabs is probably the most professional. There is attention to detail, good designs, documentation, support, and constant maintenance.
I apologize for offending you for such futile reasons, AxLabs, or anyone else, should have to deal with these messages.


Feature: modularized express routes for reusability, testability, composability and performance

Introducing modularized express routes for reusability, testability, composability and performance.

Must backport these 2 new routes:

https://github.com/FlowiseAI/Flowise/pull/1419/files#diff-8e6dfbbfb522575fe7c568c2de518bf9de351de83c9dbb48eaa865cd54450eb3R185
https://github.com/FlowiseAI/Flowise/pull/1419/files#diff-8e6dfbbfb522575fe7c568c2de518bf9de351de83c9dbb48eaa865cd54450eb3R187

Must backport these 2 new routes:

https://github.com/FlowiseAI/Flowise/pull/1419/files#diff-8e6dfbbfb522575fe7c568c2de518bf9de351de83c9dbb48eaa865cd54450eb3R185
https://github.com/FlowiseAI/Flowise/pull/1419/files#diff-8e6dfbbfb522575fe7c568c2de518bf9de351de83c9dbb48eaa865cd54450eb3R187

also these new routes from Indexing PR:
https://github.com/FlowiseAI/Flowise/pull/1802/files#diff-8e6dfbbfb522575fe7c568c2de518bf9de351de83c9dbb48eaa865cd54450eb3R1399

Replaced by https://github.com/FlowiseAI/Flowise/pull/2030/commits


Fix the type names in defaultConfiguration.json

The types in the defaultConfiguration.json are not the same as the ones in the conway.cddl. Also for some parameters, the type name for some parameters (like unit_interval for parameter 33) seems to be imply some type constraints that do not exist.
This PR fixes that by introducing new type names, without the addition of extra checks, it's pure syntax.

Pre-submit checklist:

Branch

[x] Tests are provided (if possible)
[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[ ] Changelog fragments have been written (if appropriate)
[ ] Relevant tickets are mentioned in commit messages
[ ] Formatting, PNG optimization, etc. are updated

PR

[ ] (For external contributions) Corresponding issue exists and is linked in the description
[x] Targeting master unless this is a cherry-pick backport
[x] Self-reviewed the diff
[x] Useful pull request description
[x] Reviewer requested

Messed up a commit. Will update


AddReference cannot be imported despite pythonnet having been installed

Expected Behavior

pythonnet installation allows one to import clr
Actual Behavior

Can at times not occur (https://www.quantconnect.com/forum/discussion/9054/lean-vagrant-box/p1)
Potential Solution

Add test to see if pythonnet must be reinstalled/different source required for installation
Reproducing the Problem

As per https://stackoverflow.com/questions/56957512/pythonnet-missing-addreference-method, one method would be to make a clr.py file in site-packages. Otherwise, delete site_builder.py from site-packages\clr,
System Information

Checklist

[ x] I have completely filled out this template
[ x] I have confirmed that this issue exists on the current master branch
[ x] I have confirmed that this is not a duplicate issue by searching issues

[x ] I have provided detailed steps to reproduce the issue

Hey @aarjaneiro!
QC has its own fork of pythonNet https://github.com/QuantConnect/pythonnet with some changes to better support our use case. Installing pythonnet/pythonnet will probably cause compatibility issues. We are currently not installing pythonNet in our docker images but rely on the NuGet package pulled by Lean on build, is this not working for you?

@Martin-Molinero
Unfortunately not as per https://www.quantconnect.com/forum/discussion/9054/lean-vagrant-box/p1/comment-25262. In my case,  removing my local ~/anaconda3/lib/python3.7/site-packages/clr/ folder and then reinstalling worked despite having originally installed the Lean version. Via docker, however, I've gotten it working.

Closed by https://github.com/QuantConnect/Lean/pull/4673


Fix MinaCalc linking logic

MinaCalc_x86.lib would still attempt to link on macOS, even though it is a windows only lib. The compiler notices this, and choses not to link it, thought removing the possibility of it happening is better than letting the compiler deal with it.
Intended to be apart of #514.

:+1:


auth: Accept next as POST parameter in POST requests

Merged, thanks @andersk!
@mateuszmandera FYI.  One thing to note is how we handle clicking a link from a bug tracker and then creating an account via clicking to registration from the login page.  I'm pretty sure what happens now is you'll land in the normal welcome-bot tutorial narrow, not whatever next parameter was passed, and that's probably what should happen.


refactor(getItems): support string input for value lookups

🔗 Linked issue

#383
❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[x] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This refactors getItems to support string input for file lookups, as per the feedback provided.
📝 Checklist

[x] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

@pi0 just to make sure before I begin the work, is this what you meant by a refactor?

Oh sorry if i didn't explain well. What I meant was to export a new function from utils.ts with findItems(storage: Storage, matcher: string, opts: { raw?: boolean } = {} signature. This utility is not adding to the core bundle size but can be used to easily do search operation.

Ah, I see, my bad for misunderstanding. I will do so

please feel free to reopen one had a chance or if still interested in adding findItems util 👍🏼


BKR-892 Generalize how beaker determines run_in_parallel option

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/2802/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/2805/

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/2808/

👍


dhcpcd issue when compiled with glibc 2.36

Hi Roy,
OS: Slackware current
glibc: 2.36
kernel : 5.19.1
I have an issue with dhcpcd ( 9.4.1 and the master branch)
Attached: /var/log/messages when I restarted NetworkManager (with dhcpcd 9.99.0)
Let me know if you need anything more
dhcpcd_messages.txt

This is a byproduct of getrandom() moving to a vDSO/vsyscall64. (This is similar to the gettimeofday()/clock_gettime() vDSO/vsyscall64 work of a decade ago, but with tricky fork protections.) More information here<EMAIL_ADDRESS>The upshot is that most getrandom calls wont be real syscalls and will not context switch, and so getrandom() will be much faster on average.
Background/TLDR of the patch: Have you ever wondered what that ld-linux.so library is that you see in your library maps, or why the penultimate page in your process's virtual memory address space is mapped to it? That’s vDSO/vsyscall64: this is a page of memory containing code supplied by the Linux kernel which can be called by you or, more likely, by your favorite libc  (like glibc, musl, uclibc, and friends). When you call clock_gettime() to get the current timestamp (whether to tell the time or to profile some code or whatever), it is very slow to read the realtime clock (RTC), so this little page of memory has code that interpolates once-per-second (or thereabouts) reads of the RTC (which may be disciplined against a reference clock or oscillator etc.) with rdtsc instructions that read the TSC (cycle counter on your handy Intel CPU). The TSC can be read without a syscall, so this reduces the average call time to get the time in nanoseconds to a few nanoseconds instead of the ~microsecond it takes to read the RTC inside the clock_gettime using an actual syscall by eliminating the need to use the syscall if you’re calling it frequently and interpolating using the TSC. This means most calls to clock_gettime now happen in userspace instead of kernel syscalls. The TL;DR of that kernel patch/glibc change as of 2.36 is that they’re doing the same for the getrandom() syscall, but they have this extra pesky constraint: If you fork a process, you really don’t want the two forked processes (which might even be owned by different users, or different containers, or whatever) to get the same random numbers on their next X calls to getrandom() over the next ~second. So, there’s a little bit of extra work that vDSO/vsyscall64 code has to do to make it so the kernel zeroes out the page in memory where that RNG seed is stored when it forks, and to force the new process to have to get a new seed from the kernel.

Hi Roy, Hi Ido,
yes, there seems to be an issue with getrandom().  Find attached some logs i captured.  The 000-build-dhcpcd shows how i built it, the other next two (001 and 005) are captures of the error and finally a normal working client in 010.
To get it work, just a small sed has been used:
  case "$(uname -m)" in         i?86) sed -e '/Deny everything else/i SECCOMP_ALLOW(__NR_getrandom),' -i src/privsep-linux.c               ;;     esac
I should add that the fail did occur on a i686 system, not on a x86_64 (while i'm going to verify that). And i also should mention that the command i used to test was
dhcpcd -B -d -4 eth0
dhcpcd-seccomp-getrandom.zip
.

Some of us (@lfs-book) can reproduce the issue on x86_64, but some cannot.  We are not sure how to "100%" reproduce the issue, but I can tell what's happening here.
dhcpcd building system checks if <stdlib.h> provides arc4random function and its friends.  If they are provided, dhcpcd will use it.  Otherwise, dhcpcd will use an internal shipped version as fallback.
Glibc-2.36 added arc4random into <stdlib.h>, so dhcpcd will use the arc4random-family functions in Glibc.  Currently these functions are simple wrappers around getrandom system call (Glibc developers have considered a pure user-space implementation, but the conclusion was there is no way to determine if the RNG should be reseeded without some information only known by the kernel).  But dhcpcd's seccomp filter does not allow getrandom, causing the crash.
sed -e '/Deny everything else/i SECCOMP_ALLOW(__NR_getrandom),' -i src/privsep-linux.c does the job for both 32-bit x86 and x86_64.

To me use a system call allowlist (rejecting anything you unexpect) is almost always wrong in nature.  We depends on external libraries (libc, at least) and we can't control what system call the library will invoke.  Sometimes libc (and other libraries) invokes a system call in a manner we cannot expect. (For example, glibc invokes sysinfo in qsort implementation to improve performance, did you expect it? :)
If you want to use an allowlist, either (1) program everything yourself, don't use libc and invoke system calls with assembly code; (2) at least, don't kill the program if some system call you cannot expect is invoked, return ENOSYS (via SECCOMP_RET_ERRNO) instead.  Then the libraries (if they are programmed carefully) will manage to work around the issue, just like how they are running on a relatively old kernel.
OTOH, use a denylist for some really dangerous thing (pciconfig_write for example) is mostly OK.

To me use a system call allowlist (rejecting anything you unexpect) is almost always wrong in nature. We depend on external libraries (libc, at least) and we can't control what system call the library will invoke. Sometimes libc (and other libraries) invokes a system call in a manner we cannot expect. (For example, glibc invokes sysinfo in qsort implementation to improve performance, did you expect it? :)
If you want to use an allowlist, either (1) program everything yourself, don't use libc and invoke system calls with assembly code; (2) at least, don't kill the program if some system call you cannot expect is invoked, return ENOSYS (via SECCOMP_RET_ERRNO) instead. Then the libraries (if they are programmed carefully) will manage to work around the issue, just like how they are running on a relatively old kernel.
OTOH, use a denylist for some really dangerous thing (pciconfig_write for example) is mostly OK.

This is a design issue with SECCOMP which I noted here: https://github.com/NetworkConfiguration/dhcpcd/blob/e307ec2c58d6beb0c48d34253c19eac3b9851f07/src/privsep-linux.c#L393
Sadly the capsicum port to Linux stalled.

Thank you Roy

Hi Xi,
I think you have the balance of harms wrong, or aren’t considering the real
risk to security of a denylist approach.
It’s reasonable to assume your language runtime (libc) will remain stable,
and use the same syscalls, and to handle exceptions as they arise. In this
case, about twice a decade. Denylists defeat the purpose of the security
mechanism, because nearly every syscall you miss - including newly
introduced ones across every kernel/kernel version in existence - will be
impossible to enumerate and often present an unreasonably large attack
surface.
It’s super easy to enumerate syscalls we do use - both through static
analysis and at runtime using tools like strace.
On Thu, Aug 25, 2022 at 19:40 Xi Ruoyao @.***> wrote:

To me use a system call allowlist (rejecting anything you unexpect) is
almost always wrong in nature. We depends on external libraries (libc, at
least) and we can't control what system call the library will invoke.
Sometimes libc (and other libraries) invokes a system call in a manner we
cannot expect. (For example, glibc invokes sysinfo in qsort
implementation to improve performance, did you expect it? :)
If you want to use an allowlist, either (1) program everything yourself,
don't use libc and invoke system calls with assembly code; (2) at least,
don't kill the program if some system call you cannot expect is invoked,
return ENOSYS (via SECCOMP_RET_ERRNO) instead. Then the libraries (if
they are programmed carefully) will manage to work around the issue, just
like how they are running on a relatively old kernel.
OTOH, use a denylist for some really dangerous thing (pciconfig_write
for example) is mostly OK.
—
Reply to this email directly, view it on GitHub
https://github.com/NetworkConfiguration/dhcpcd/issues/120#issuecomment-1227980583,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAU4RXI3GXOFZFVMYYPSVDV3AVCTANCNFSM56VVOIBA
.
You are receiving this because you commented.Message ID:
@.***>

On Tue, 2022-10-11 at 00:28 -0700, Ido Rosen wrote:

It’s reasonable to assume your language runtime (libc) will remain stable,
and use the same syscalls

It's not only language runtime, but also other libraries.
We keep using Glibc for 20 years, but not the same version of Glibc.
And "what syscall Glibc uses" is definitely not a part of its public
ABI.

and to handle exceptions as they arise.

Then you should use SECCOMP_RET_ERRNO instead of
SECCOMP_RET_KILL_{PROCESS,THREAD} or SECCOMP_RET_TRAP, to give the
runtime a chance to handle the exceptions.
--
Xi Ruoyao @.***>
School of Aerospace Science and Technology, Xidian University

Then you should use SECCOMP_RET_ERRNO instead of SECCOMP_RET_KILL_{PROCESS,THREAD} or SECCOMP_RET_TRAP, to give the runtime a chance to handle the exceptions.

If you compile dhcpcd with SECCOMP_FILTER_DEBUG then SECCOMP_RET_TRAP is used instead.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/privsep-linux.c#L143
We also install a signal handler to log a suitable diagnostic before exiting.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/privsep-linux.c#L446
If dhcpcd detects a security issue the only correct action is to exit.


Provide Nix expressions

They currently live in https://github.com/hercules-ci/ghcide-nix, however, this has a drawback that they have to be manually updated and thus can't use just any commit from ghcide and get a binary.
Once Nix files are in place here, I recommend setting up CI to provide binaries for each commit:

github actions + cachix.org for serving the binaries
https://hercules-ci.com/ agent running on someone's infrastructure (happy to maintain it myself)

Please excuse my ignorance here, but:

What are these nix expressions for? Is that for people who want to use ghcide on a nixOS machine? For any Haskell project set up to build through nix? Is providing those nix expressions the only way to use ghcide from a Haskell project that uses nix as its build tool?
What, if any, are the benefits to the rest of the ecosystem? (I have no sense of how prevalent nix is as a build tool for Haskell projects.)
What, if any, are the costs to the rest of the ecosystem?
Why do we need to change CI? Is it not possible to create nix-compatible binaries from a "normal" machine? We seem to be able to do it on the daml repo.

Let me try to answer some of @garyverhaegen-da’s questions and hopefully @domenkozar can weigh in on the others:

The nix expressions are for people that use Nix for Haskell development both on nixOS and on other operating systems. You might be able to get away with building ghcide without nix while using nix for Haskell development in some cases but that’s just asking for issues to pop up since ghcide needs to be built against the same GHC version as your project (not necessarily the same binary but there are more constraints than just the version).
Nix is very prevalent as a build tool for Haskell tools. So people will want and create these Nix expressions either way (as shown by the fact that @domenkozar has already created them). The obvious advantage of having these expressions live in this repository is that they don’t get out of sync.
To ensure that they don’t get out of sync, we have to test them in CI. We could do that by just calling nix-build on Azure pipelines similar to how we handle this on the DAML repo.
We probably want to cache Nix stuff in some way for two reasons: 1. It makes our CI jobs faster. 2. It’s nice for external contributors to not have to rebuild the world.

Achieving 1 is easy: We can just use Azure’s cache to cache the nix store.
Achieving 2 is a bit more tricky: There are two options here that I see: 1. Host our own binary cache similar to the DAML repo (probably a bad idea since that might get us back to not being able to run automatic CI jobs for external contributors) 2. Use cachix which is a fairly popular host for Nix caches that is easy to use (I’ve used it myself before) (disclaimer: It’s created and maintained by @domenkozar). 2 will probably still require some auditing since we have to have the credentials for our pushing to Cachix in our CI jobs which is an additional attack vector.

Hercules is a CI service created by @domenkozar that supposedly integrates nicely with Cachix and Nix in general. If we don’t host the infrastructure ourselves, I believe that we probably don’t need new credentials but just a Github webhook so I’m not sure it introduces any additional attack vector. That said (please correct me if I’m wrong here @domenkozar) Hercules is fairly new, much less popular than cachix and I’ve never used it myself which makes me a bit sceptical (but I’m happy to be convinced). It will also never (or at least not in the foreseeable future) be our primary CI service so I don’t think we will profit much from whatever fancy features it has and it will mostly be equivalent to calling nix-build on Azure and pushing to cachix (again please correct me here @domenkozar)

I haven’t given this too much thought so far but atm I’m leaning towards doing nix-build + using Azure’s nix cache at least for now and see if we can use Cachix or host a binary cache ourselves after that.

What are these nix expressions for?

They make up for deterministic installation of ghcide on linux and macos. No matter which environment or distribution someone is using, it's always going to work.
Binary caches (cachix) provide binaries to avoid compilation from source, making the whole installation a matter of downloading ~100MB binaries and unpacking them.
This is convenient if you want ghcide-ghc865, ghcide-ghc864 ... ghcie-ghc841
Nix is just a build tool here, Haskell dependencies are mapped 1-to-1 from stack.yaml plan.

What, if any, are the benefits to the rest of the ecosystem? (I have no sense of how prevalent nix is as a build tool for Haskell projects.)

It's quite prevalent, although I have no numbers to back that off. At most Haskell hackathon there's a group of people hacking on Nix tooling.
The benefit is that it simplifies the installation of ghcide, which is one part of why is editor integration hard in Haskell compared to the rest of the languages.

What, if any, are the costs to the rest of the ecosystem?

I see no other costs rather than maintenance.

I believe that we probably don’t need new credentials but just a Github webhook so I’m not sure it introduces any additional attack vector.

It's using GitHub apps, so you grant access via GitHub to a single repository and tie that to a token which agent uses to run jobs.
No hard feelings if you decide to go a different route, it would be just less maintenance for me having all of this upstream.

Hercules is fairly new, much less popular than cachix and I’ve never used it myself which makes me a bit sceptical (but I’m happy to be convinced)

Both are written in Haskell and other boring technologies, so the confidence is pretty high. So far there were a few downtimes, mostly handled within an hour or two. Cachix is older though, more than 1000 people rely on it. Hercules CI has over 100 users, growing each day.

I'd like to also add that we're going for the commercial success of Nix, so I am biased here.
I don't think you need to do any of the infrastructure if you don't want to. I'd be OK just maintaining Nix expressions myself in ghcide and giving access to our CI to build it.
I used to maintain https://github.com/Infinisil/all-hies for HIE itself, and people really liked the simple installation method.

To clarify, any change of infrastructure, including a move to an external CI or the addition of a webhook, needs to go through an audit by our security team. So I'm very keen on getting as much value as we can without doing that.
From the above, it seems to me that we can achieve almost all we want by simple changes to our existing build process and not introducing any new credentials: having the nix expressions in this repo, building them as part of CI, and keeping a cache of /nix/store at the Azure level all require no sensitive change at all. If I understand correctly that would result in everything working for everyone:

Our CI would guarantee the nix expressions don't get out of date, and
Nix users could therefore rely on those expressions.
The only downside left would be that nix users would need to build those expressions instead of being able to download the binaries. Am I understanding correctly so far?

If the only missing piece after that is the discovery of new commits by Hercules so it can pre-build packages, could it just poll this repo, say once a day? That way we would not need to know about it: no credential, no webhook, no external service we need to know about, and therefore no need to go through a security audit.

Let me summarize the current state: We’ll happily accept the nix expressions in this repo with an Azure-based CI setup but relying on an external service is not something we want to do right now.

keeping a cache of /nix/store at the Azure level

That's the very first thing one would do, but it brings a bunch of problems:

/nix/store/ is ever growing if you don't garbage collect: you can garbage collect before building, but that wastes time
copying whole closure for each build is quite time consuming - CI build times will be slow

Either way it seems like you've made the decision so I won't dwell on this further, let's go step by step.
I'll prepare expressions to be upstreamed here.

The way azure caches work, this shouldn’t ever grow. Downloading the closure should be relatively fast (we have a significantly larger closure on the daml repo and it takes ~2 minutes to download). Uploading is slow but that only happens if the cache key (which will include things like the nix files and the cabal files) which isn’t all that often usually.

Regarding the nix cache, we do something similar for the daml repo, it may be worth taking a look. Essentially, the cache is recreated from scratch every time the files that define it (in this case it would be the set of nix expressions) change, which hopefully doesn't happen too often. I guess this counts as GC, in a very naive way.


hash: fix build failure against gcc-10

On gcc-10 (and gcc-9 -fno-common) build fails as:
gcc  -g -O2 -pthread -pthread -Wall -Werror -pedantic -Wmissing-prototypes \
  -Wmissing-declarations -Wredundant-decls   -o memcached ... -levent
ld: memcached-hash.o:memcached/hash.h:5:
  multiple definition of `hash'; memcached-memcached.o:memcached/hash.h:5: first defined here

gcc-10 will change the default from -fcommon to fno-common:
https://gcc.gnu.org/PR85678.
The error also happens if CFLAGS=-fno-common passed explicitly.
Reported-by: Brian Evans
Bug: https://bugs.gentoo.org/706196

out in 1.6.0!


[Enhancement] Support broker load priority

What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #11120
Problem Summary(Required) ：

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

[FE PR Coverage Check]
:disappointed: fail : 69 / 117 (58.97%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/load/ExportChecker.java
0
2
00.00%
[128, 147]

:large_blue_circle:
com/starrocks/load/loadv2/BulkLoadJob.java
0
1
00.00%
[238]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTaskExecutor.java
15
43
34.88%
[49, 50, 51, 52, 56, 57, 58, 59, 60, 61, 74, 75, 76, 77, 80, 85, 86, 87, 88, 91, 92, 103, 104, 105, 106, 108, 110, 111]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTask.java
6
11
54.55%
[25, 26, 27, 28, 29]

:large_blue_circle:
com/starrocks/common/PriorityFutureTask.java
7
11
63.64%
[18, 26, 32, 39]

:large_blue_circle:
com/starrocks/common/PriorityThreadPoolExecutor.java
13
18
72.22%
[20, 21, 25, 26, 39]

:large_blue_circle:
com/starrocks/common/PriorityRunnable.java
15
18
83.33%
[29, 34, 51]

:large_blue_circle:
com/starrocks/common/ThreadPoolManager.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadJob.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadJob.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadLoadingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/task/LeaderTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/SparkLoadPendingTask.java
1
1
100.00%
[]

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 108 / 188 (57.45%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/execution/AlterLoadExecutor.java
0
3
00.00%
[11, 14, 15]

:large_blue_circle:
com/starrocks/load/loadv2/LoadManager.java
0
18
00.00%
[129, 130, 131, 134, 135, 137, 138, 139, 141, 142, 143, 145, 146, 147, 149, 152, 155, 156]

:large_blue_circle:
com/starrocks/load/ExportChecker.java
0
2
00.00%
[128, 147]

:large_blue_circle:
com/starrocks/load/loadv2/BulkLoadJob.java
0
1
00.00%
[238]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTaskExecutor.java
15
43
34.88%
[49, 50, 51, 52, 56, 57, 58, 59, 60, 61, 74, 75, 76, 77, 80, 85, 86, 87, 88, 91, 92, 103, 104, 105, 106, 108, 110, 111]

:large_blue_circle:
com/starrocks/analysis/LoadStmt.java
3
7
42.86%
[258, 259, 260, 261]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTask.java
6
11
54.55%
[25, 26, 27, 28, 29]

:large_blue_circle:
com/starrocks/load/loadv2/LoadJob.java
3
5
60.00%
[317, 499]

:large_blue_circle:
com/starrocks/common/PriorityFutureTask.java
7
11
63.64%
[18, 26, 32, 39]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadJob.java
8
11
72.73%
[114, 115, 117]

:large_blue_circle:
com/starrocks/common/PriorityThreadPoolExecutor.java
13
18
72.22%
[20, 21, 25, 26, 39]

:large_blue_circle:
com/starrocks/common/PriorityRunnable.java
15
18
83.33%
[29, 34, 51]

:large_blue_circle:
com/starrocks/analysis/AlterLoadStmt.java
27
29
93.10%
[46, 50]

:large_blue_circle:
com/starrocks/common/ThreadPoolManager.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadLoadingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/task/LeaderTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/SparkLoadPendingTask.java
1
1
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 150 / 228 (65.79%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/load/loadv2/LoadManager.java
0
25
00.00%
[131, 132, 133, 136, 137, 139, 140, 141, 143, 144, 145, 147, 148, 149, 151, 154, 157, 158, 301, 302, 303, 304, 305, 308, 309]

:large_blue_circle:
com/starrocks/load/ExportChecker.java
0
2
00.00%
[128, 147]

:large_blue_circle:
com/starrocks/persist/EditLog.java
0
5
00.00%
[779, 780, 781, 1436, 1437]

:large_blue_circle:
com/starrocks/journal/JournalEntity.java
0
3
00.00%
[604, 605, 606]

:large_blue_circle:
com/starrocks/load/loadv2/BulkLoadJob.java
1
6
16.67%
[139, 140, 245, 346, 347]

:large_blue_circle:
com/starrocks/execution/AlterLoadExecutor.java
1
3
33.33%
[14, 15]

:large_blue_circle:
com/starrocks/analysis/LoadStmt.java
3
7
42.86%
[258, 259, 260, 261]

:large_blue_circle:
com/starrocks/load/loadv2/LoadJob.java
3
6
50.00%
[319, 501, 504]

:large_blue_circle:
com/starrocks/common/PriorityFutureTask.java
7
11
63.64%
[18, 26, 32, 39]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadJob.java
11
17
64.71%
[118, 119, 121, 132, 133, 135]

:large_blue_circle:
com/starrocks/common/PriorityThreadPoolExecutor.java
13
18
72.22%
[20, 21, 25, 26, 39]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTask.java
9
11
81.82%
[26, 27]

:large_blue_circle:
com/starrocks/common/PriorityRunnable.java
15
18
83.33%
[29, 34, 51]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTaskExecutor.java
37
43
86.05%
[59, 60, 61, 77, 110, 111]

:large_blue_circle:
com/starrocks/persist/AlterLoadJobOperationLog.java
10
11
90.91%
[28]

:large_blue_circle:
com/starrocks/analysis/AlterLoadStmt.java
27
29
93.10%
[46, 50]

:large_blue_circle:
com/starrocks/common/proc/LoadProcDir.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/common/ThreadPoolManager.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadLoadingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/task/LeaderTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/SparkLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/execution/DataDefinitionExecutorFactory.java
1
1
100.00%
[]

run starrocks_fe_unittest

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 151 / 230 (65.65%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/load/loadv2/LoadManager.java
0
25
00.00%
[131, 132, 133, 136, 137, 139, 140, 141, 143, 144, 145, 147, 148, 149, 151, 154, 157, 158, 301, 302, 303, 304, 305, 308, 309]

:large_blue_circle:
com/starrocks/load/ExportChecker.java
0
2
00.00%
[128, 147]

:large_blue_circle:
com/starrocks/persist/EditLog.java
0
5
00.00%
[775, 776, 777, 1433, 1434]

:large_blue_circle:
com/starrocks/journal/JournalEntity.java
0
3
00.00%
[603, 604, 605]

:large_blue_circle:
com/starrocks/load/loadv2/BulkLoadJob.java
1
6
16.67%
[139, 140, 245, 346, 347]

:large_blue_circle:
com/starrocks/execution/AlterLoadExecutor.java
1
3
33.33%
[14, 15]

:large_blue_circle:
com/starrocks/load/loadv2/LoadJob.java
3
7
42.86%
[319, 501, 504, 708]

:large_blue_circle:
com/starrocks/analysis/LoadStmt.java
3
7
42.86%
[255, 256, 257, 258]

:large_blue_circle:
com/starrocks/common/PriorityFutureTask.java
7
11
63.64%
[18, 26, 32, 39]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadJob.java
11
17
64.71%
[118, 119, 121, 132, 133, 135]

:large_blue_circle:
com/starrocks/common/PriorityThreadPoolExecutor.java
13
18
72.22%
[20, 21, 25, 26, 39]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTask.java
9
11
81.82%
[26, 27]

:large_blue_circle:
com/starrocks/common/PriorityRunnable.java
15
18
83.33%
[29, 34, 51]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTaskExecutor.java
37
43
86.05%
[59, 60, 61, 77, 110, 111]

:large_blue_circle:
com/starrocks/persist/AlterLoadJobOperationLog.java
10
11
90.91%
[28]

:large_blue_circle:
com/starrocks/analysis/AlterLoadStmt.java
27
29
93.10%
[46, 50]

:large_blue_circle:
com/starrocks/common/proc/LoadProcDir.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/common/ThreadPoolManager.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadLoadingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/EtlStatus.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/task/LeaderTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/SparkLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/execution/DataDefinitionExecutorFactory.java
1
1
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 174 / 255 (68.24%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/load/loadv2/LoadManager.java
0
25
00.00%
[131, 132, 133, 136, 137, 139, 140, 141, 143, 144, 145, 147, 148, 149, 151, 154, 157, 158, 301, 302, 303, 304, 305, 308, 309]

:large_blue_circle:
com/starrocks/load/ExportChecker.java
0
2
00.00%
[128, 147]

:large_blue_circle:
com/starrocks/persist/EditLog.java
0
5
00.00%
[774, 777, 778, 1433, 1434]

:large_blue_circle:
com/starrocks/journal/JournalEntity.java
0
3
00.00%
[604, 605, 606]

:large_blue_circle:
com/starrocks/load/loadv2/BulkLoadJob.java
1
6
16.67%
[139, 140, 245, 346, 347]

:large_blue_circle:
com/starrocks/execution/AlterLoadExecutor.java
1
3
33.33%
[14, 15]

:large_blue_circle:
com/starrocks/load/loadv2/LoadJob.java
5
11
45.45%
[322, 504, 507, 690, 691, 714]

:large_blue_circle:
com/starrocks/analysis/LoadStmt.java
3
5
60.00%
[255, 256]

:large_blue_circle:
com/starrocks/common/PriorityFutureTask.java
7
11
63.64%
[18, 26, 32, 39]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadJob.java
11
17
64.71%
[119, 120, 122, 133, 134, 136]

:large_blue_circle:
com/starrocks/common/PriorityThreadPoolExecutor.java
13
18
72.22%
[20, 21, 25, 26, 39]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTask.java
9
11
81.82%
[26, 27]

:large_blue_circle:
com/starrocks/common/PriorityRunnable.java
15
18
83.33%
[29, 34, 51]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTaskExecutor.java
37
43
86.05%
[59, 60, 61, 77, 110, 111]

:large_blue_circle:
com/starrocks/common/util/LoadPriority.java
20
22
90.91%
[8, 44]

:large_blue_circle:
com/starrocks/persist/AlterLoadJobOperationLog.java
10
11
90.91%
[28]

:large_blue_circle:
com/starrocks/analysis/AlterLoadStmt.java
27
29
93.10%
[47, 51]

:large_blue_circle:
com/starrocks/common/proc/LoadProcDir.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/common/ThreadPoolManager.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadLoadingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/task/LeaderTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/SparkLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/execution/DataDefinitionExecutorFactory.java
1
1
100.00%
[]

run starrocks_admit_test

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 173 / 287 (60.28%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/Analyzer.java
0
2
00.00%
[513, 514]

:large_blue_circle:
com/starrocks/sql/parser/AstBuilder.java
0
6
00.00%
[1807, 1808, 1809, 1812, 1813, 1815]

:large_blue_circle:
com/starrocks/sql/ast/AstVisitor.java
0
1
00.00%
[387]

:large_blue_circle:
com/starrocks/load/loadv2/LoadManager.java
0
25
00.00%
[131, 132, 133, 136, 137, 139, 140, 141, 143, 144, 145, 147, 148, 149, 151, 154, 157, 158, 301, 302, 303, 304, 305, 308, 309]

:large_blue_circle:
com/starrocks/sql/analyzer/AlterLoadAnalyzer.java
0
19
00.00%
[17, 19, 20, 24, 25, 26, 27, 28, 31, 32, 33, 34, 36, 37, 38, 39, 40, 41, 42]

:large_blue_circle:
com/starrocks/load/ExportChecker.java
0
2
00.00%
[128, 147]

:large_blue_circle:
com/starrocks/persist/EditLog.java
0
5
00.00%
[777, 778, 779, 1441, 1442]

:large_blue_circle:
com/starrocks/journal/JournalEntity.java
0
3
00.00%
[604, 605, 606]

:large_blue_circle:
com/starrocks/qe/DDLStmtExecutor.java
0
4
00.00%
[368, 369, 370, 371]

:large_blue_circle:
com/starrocks/load/loadv2/LoadJob.java
5
11
45.45%
[322, 504, 507, 690, 691, 714]

:large_blue_circle:
com/starrocks/load/loadv2/BulkLoadJob.java
4
8
50.00%
[140, 141, 346, 348]

:large_blue_circle:
com/starrocks/analysis/LoadStmt.java
3
5
60.00%
[255, 256]

:large_blue_circle:
com/starrocks/common/PriorityFutureTask.java
7
11
63.64%
[18, 26, 32, 39]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadJob.java
11
17
64.71%
[119, 120, 122, 133, 134, 136]

:large_blue_circle:
com/starrocks/common/PriorityThreadPoolExecutor.java
13
18
72.22%
[20, 21, 25, 26, 39]

:large_blue_circle:
com/starrocks/analysis/AlterLoadStmt.java
27
33
81.82%
[47, 51, 52, 55, 96, 101]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTask.java
9
11
81.82%
[26, 27]

:large_blue_circle:
com/starrocks/common/PriorityRunnable.java
15
18
83.33%
[29, 34, 51]

:large_blue_circle:
com/starrocks/task/PriorityLeaderTaskExecutor.java
37
43
86.05%
[59, 60, 61, 77, 110, 111]

:large_blue_circle:
com/starrocks/common/util/LoadPriority.java
20
22
90.91%
[8, 44]

:large_blue_circle:
com/starrocks/persist/AlterLoadJobOperationLog.java
10
11
90.91%
[28]

:large_blue_circle:
com/starrocks/common/proc/LoadProcDir.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/common/ThreadPoolManager.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadLoadingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/BrokerLoadPendingTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/server/GlobalStateMgr.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/task/LeaderTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/LoadTask.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/load/loadv2/SparkLoadPendingTask.java
1
1
100.00%
[]


Curious Case of CLI Command Behavior Across Platforms

Summary
Hello Salesforce CLI Team! 👋
I’ve stumbled upon a rather curious behavior while working with the Salesforce CLI and I’m hoping to get some insights or a workaround from the experts here.
Issue Description:
When executing the following command in a Python subprocess to list authorized orgs in JSON format:
subprocess.run(['sf', 'org', 'list', 'auth', '--json'], stdout=subprocess.PIPE, text=True, shell=True)

I receive the Salesforce CLI help text instead of the expected JSON output. Here’s a snippet of what I get:
The Salesforce CLI

VERSION
  @salesforce/cli/2.42.6 darwin-arm64 node-v20.12.2

USAGE
  $ sf [COMMAND]

TOPICS
  alias            Use the alias commands to manage your aliases.
  analytics        Work with analytics assets.
  ...

However, when I place the entire command within a single string parameter like so:
{
  "status": 0,
  "result": [...]
}

System Information
{
  "architecture": "darwin-arm64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v20.12.2",
  "osVersion": "Darwin 23.5.0",
  "rootPath": "/Users/ea_enel/.local/share/sf/client/2.42.6-2b3c407",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.18 (core)",
    "@oclif/plugin-commands 3.3.4 (core)",
    "@oclif/plugin-help 6.0.22 (core)",
    "@oclif/plugin-not-found 3.1.9 (core)",
    "@oclif/plugin-plugins 5.0.21 (core)",
    "@oclif/plugin-search 1.0.24 (core)",
    "@oclif/plugin-update 4.2.12 (core)",
    "@oclif/plugin-version 2.1.2 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.19 (core)",
    "@oclif/plugin-which 3.1.10 (core)",
    "@salesforce/cli 2.42.6 (core)",
    "apex 3.1.11 (core)",
    "auth 3.6.11 (core)",
    "data 3.3.5 (core)",
    "deploy-retrieve 3.6.14 (core)",
    "info 3.2.8 (core)",
    "limits 3.3.7 (core)",
    "marketplace 1.2.5 (core)",
    "org 4.1.10 (core)",
    "packaging 2.4.4 (core)",
    "schema 3.3.6 (core)",
    "settings 2.2.6 (core)",
    "sobject 1.4.2 (core)",
    "source 3.3.12 (core)",
    "telemetry 3.3.7 (core)",
    "templates 56.2.7 (core)",
    "trust 3.6.11 (core)",
    "user 3.5.8 (core)",
    "sfdx-plugin-source-read 1.2.0 (user) published 219 days ago (Tue Oct 24 2023)"
  ]
}

Hey, I'm not familiar with Python but docs mention this:

The shell argument (which defaults to False) specifies whether to use the shell as the program to execute. If shell is True, it is recommended to pass args as a string rather than as a sequence.

https://docs.python.org/3/library/subprocess.html
closing this as isn't a CLI specific bug.


Introduce createStore function

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/ngneat/elf/blob/master/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?
Store can be created in two steps:
const { state, config } = createState(withProps<AuthProps>({ user: null }));
const authStore = new Store({ state, name: 'auth', config });

This behavior is still there.
Issue Number: N/A
What is the new behavior?

Store can be created in one step:
const store = createStore({ name: 'auth' }, withProps<AuthProps>({ user: null }));

The Elf CLI is updated to generate files using this approach.

READMEs and docs, and demos are updated to use this approach

Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

Also installed and added to dev dependencies 3 packages that were for some reason missing. Without them I wasn't able to run tests.
Not sure why PR shows 7 commits. There should only be one. I'm not a git expert. I double-checked and made sure that only the relevant changes are included.

@DmitryEfimenko please squash the commits

I'm not a git expert and having troubles with this... running command git rebase -i HEAD~2, picking first commit and squashing second commit. But that results in branch diverging. After doing git pull, everything goes back...

I think I figured out the squashing...
Although I'm not sure if you want to me squash the "merge master into dev" commit as well. Let me know

Something is wrong with your git history:

Maybe you can create a new clean branch from master and cherry-pick from yours.

@DmitryEfimenko please check the last version of cli, there can be conflicts.

I'll close this PR and re-create it fresh


OCPBUGS-11493: Update storage vSphere driver validation

We need to be able to switch between LegacyDeprecatedInTreeDriver and "" so this updates the validation to relax it so that we can do so.
I've simplified based on what I believe the intention is, allowing changing to CSIWithMigraitonDriver, but not allowing changing away from it, so once oldSelf is CSIMigration driver, self must be too

CC @jsafrane @dobsonj

/lgtm

/cherry-pick release-4.13


User should have their inputs cached with notification of unsaved data

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/1030
Originally created by @bencodezen on 2019-09-23 19:09:31

When a user exits the modal, there information should be cached
But there should be an indication that these changes have not been applied
Debating whether or not it should prompt you if you try to leave a modal with unsaved changes.
cc @derek-knox

View 9 previous comments from the original issue on GitLab


Adopt latest BIDSPath updates from MNE-BIDS

But the red CI badge tells the opposite! Argh, no idea what's up… did I accidentally increase RAM usage somehow?!

Merging on behalf of @agramfort


Add content for new status and sanction fields

Display the content for TAStatus and TASanction fields.

 Fix "teaching authority other" field


[Feature Request] Express Attribute "undo"

If you're modifying an Express Object and you accidentally delete an Attribute, this can be a real pain if that Express Object already had a lot of Entries and Data. If that Attribute is core to that data, this could lead to data loss, or skew forms, and more.
Can we please get an "undo" ecosystem when working with modifying Express Objects in these and similar fashions?

Yeah I'm still interested in this.

Still interested....

Do I really need to bump this into perpetuity?

It's been bumped because this is an extremely difficult feature to add and would require a complete rearchitecture of how express works.

@aembler I can appreciate that, so how can we add this to a back-burner without having the stalebot anti-bumping? :P


Create alias for marconi-sidechain-exe

create an alias for the marconi-sidechain excutalbe.
The test:
nix build .#marconi-sidechain
cd result/bin
./marconi-sidechain --help

Pre-submit checklist:

Branch

[ ] Tests are provided (if possible)
[ ] Commit sequence broadly makes sense and have useful messages
[ ] Important changes are reflected in changelog.d of the affected packages
[ ] Relevant tickets are mentioned in commit messages

PR

[ ] (For external contributions) Corresponding issue exists and is linked in the description
[ ] Targeting main unless this is a cherry-pick backport
[ ] Self-reviewed the diff
[ ] Useful pull request description
[ ] If relevant, reference the ADR in the PR and reference the PR in the ADR
[ ] Reviewer requested

@koslambrou are you fine with this approach to provide a better experience for sidechain?


[E2E] Add test that covers installer Rancher being installed with CAPI disabled

With #190 we are changing the tests so that Rancher is installed first with the "embedded CAPI" feature flag enabled and then disabling it before installing Rancher Turtles.
We need to have a test that covers this scenario:

Rancher installed with the "embedded CAPI" feature flag disabled from install time
Rancher Turtles installed
Cluster created.

Can we consider this as done after merging #178? If not, what is still missing?


chore(docs): |app-construct| is replaced by stack, should be |app-class| for app

A Stack is a collection of Stack objects, as shown in the following example.
->
An App is a collection of Stack objects, as shown in the following example.

Pull Request Checklist
Please check all boxes, including N/A items:
Testing

[ ] Unit test and/or integration test added
[ ] Toolkit change?: integration tests manually executed (paste output to the PR description)
[ ] Init template change?: coordinated update of integration tests (currently maintained in a private repo).

Documentation

[x] README: README and/or documentation topic updated
[ ] jsdocs: All public APIs documented

Title and description

[x] Change type: Title is prefixed with change type:

fix(module): <title> bug fix (patch)
feat(module): <title> feature/capability (minor)
chore(module): <title>  won't appear in changelog
build(module): <title> won't appear in changelog

[x] Title format: Title uses lower case and doesn't end with a period
[ ] Breaking change?: Last paragraph of description is: BREAKING CHANGE: <describe exactly what changed and how to achieve similar behavior + link to documentation/gist/issue if more details are required>
[ ] References: Indicate issues fixed via: Fixes #xxx or Closes #xxx

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

The user guide repo has moved. I've updated the doc source there and will update the README shortly.


Related frameworks

@alenrajsp, related frameworks are now added to the README file.

@alenrajsp

Thanks.


The --support CLI flag should work also without rule file specified

What would you like to be added:
A more flexible support flag.
Currently to make it work the user is forced to specify at least one rule file with -r too.
Why is this needed:
In some situations the users need only version and system_info field of the return JSON given by the --support flag.

/assign @leodido

/help

@leodido:
This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.