Terminal not responding

I just installed the package on my system. When I open the terminal, it is just blinking. It is not even showing the username & system's name.

install: apm install platformio-ide-terminal

Same here. @eddyekofo94 suggestion didn't work either.

Nevermind. That wasn't to fix but to replace, and it did work...

Same here. Using Linux: Kubuntu.

Looks like this is gaining some traction. Looks like this repo is extremly old. platformio took over the code and published a package themselves. @eddyekofo94 is correct you will need to install that one instead of this one.

Confirming the same issue.
I was able to get platformio-ide-terminal working. I'm on OSX 10.11.6

Same here.

Same here: https://www.dropbox.com/s/yqmsto54k0zpcb6/Screenshot 2017-04-23 16.24.23.png?dl=0

same here

Same, just a blank pane with blinking cursor.

@linusg @dklesev @agersoncgps
It is working perfectly for me, but not this project, install apm install platformio-ide-terminal which is the working version of this project. Thank you


Support for last will & testament (LWT) messages

I couldn't see in the mqtt config that there is a LWT message setup for this addon, is there something to subscribe to that gives the LWT message?
https://mosquitto.org/api/files/mosquitto-h.html#mosquitto_will_set
Thanks!

Hi there @thanksmister!
The broker (that is in the add-on) supports it, it is up to the MQTT client to use it, which is out of scope for the add-on.
The documentation you've linked is about the client API, which will just work with the add-on without any additional configuration.

So what is the call MQTT topic to subscribe to or set in this the add-on?

@thanksmister I don't think I fully understand. The client is allowed to set whatever it likes... That is not a limitation or rule the add-on enforces. The add-on provides a plain simple and open MQTT broker. What goes in and out of it, is not a concern for the add-on, but the clients. They provide data, topics, LWT, QoS, etc.

If you are using the MQTT broker addon, it gets added to HA via config flow, yet the config flow does not allow setting a LWT message for HA (being a client).
I think that's what he's asking to be added, in which case it's a feature request for the HA codebase, not the addon.

@SiliconAvatar yes this is exactly what I was asking because if you manually setup the MQTT broker in HA you have an option to setup birth and LWT for the broker.  See that documentation here https://www.home-assistant.io/docs/mqtt/birth_will/.

Or someone update the config flow to support it over the config flow

@thanksmister - Was this ever added.  I can't find out how to add the birth message either?  How did you solve the problem?

@thanksmister - Was this ever added. I can't find out how to add the birth message either? How did you solve the problem?

No, it was not.  It was considered out of scope I believe.


file "data_0" has nil blob list

Output of restic version
restic 0.8.3 (v0.8.3-148-g2c76e724) compiled with go1.9.4 on linux/amd64
How did you run restic exactly?
./restic -r sftp:user@bla:/foo/bar -p pw check
What backend/server/service did you use to store the repository?
SFTP
Expected behavior
password is correct
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

Actual behavior
using temporary cache in /tmp/restic-check-cache-157786933
password is correct
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
error for tree b75f44fc:
  tree b75f44fc: file "data_0" has nil blob list
Fatal: repository contains errors

Steps to reproduce the behavior
Run the command.
Do you have an idea how to solve the issue?
No. I do not understand the error message.

Hey, thanks for the report. I'm sorry that the error message is confusing, we originally added it to keep track of a small bug which created a slightly different JSON data structure (content: nil instead of content: [] for empty files).
Did you maybe create this repo with a very old version of restic?

Yes, is do.
Do you need any further informations (debug logs etc.)?

Once we have a repair command, the best option is to just let it fix the incomplete blob list.

This seems to be blocking me to upgrade the repo to v2 (#3704). My oldest snapshot is from 2016-11. Still remember one of fd0's early presentations :)
Is there a way to repair it? I don't feel like deleting old snapshots, but i guess i could find out the affected files and remove them from those snapshots?

@clonejo #2876 will fix such snapshots. The current experimental code should work, but I haven't had time to review it so far.


⚠ Fortnite has degraded performance

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

HTTP code: 200
Response time: 1544 ms

Resolved: Fortnite performance has improved in d1dab36.


I have little question about gpu

Thanks for your code, I have learned a lot from it.  But there are some question that  troubles me.
When I run code, I set args.gpu =1,  but I find the program always occupy memory in  gpu0.
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|    0      6721    C   python                                         399MiB |
|    1      6721    C   python                                        7215MiB |
+-----------------------------------------------------------------------------+
I don't know where is the problem, can you solve this?  Thanks a lot.

I update the training code. Now this problem may be solved.


python-cli: add print-cache-dir subcommand

Add a subcommand to the python cli that prints out the cache directory.
This is useful for locating the downloaded packs for extracting
files from them without using the library.
It should be roughly equivalent to:
❯ python -c \
  'import cmsis_pack_manager; print(cmsis_pack_manager.Cache(False, False).data_path)'

Added a test to cover it.

All the code looks great.
I'd appreciate if you could add your copyright to the modified files, below the existing copyrights.

:+1: added it to the file that had copyright notices (the test file did not, let me know if I should add it there too!)


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


model quantified slower than not quantifed on windows x64

Issue Type
Performance
OS
Windows
OS architecture
Other
Programming Language
Python
Framework
TensorFlow, TensorFlowLite
Download URL for tflite file
https://storage.googleapis.com/mediapipe-assets/face_detection_short_range.tflite
https://storage.googleapis.com/mediapipe-assets/face_detection_full_range.tflite
Convert Script
tflite2tensorflow --model_path face_detection_short_range.tflite --flatc_path ../flatc --schema_path ../schema.fbs --output_pb
tflite2tensorflow --model_path face_detection_short_range.tflite --flatc_path ../flatc --schema_path ../schema.fbs --output_no_quant_float32_tflite --output_dynamic_range_quant_tflite --output_weight_quant_tflite --output_float16_quant_tflite --output_integer_quant_tflite
Description
hello, as the title say.  i convert successfully  the model, but the quant model is slower than original float32 model, and integer quant is slower than weight quant on windows x64. Do you know the reason?  looking forward to your replay.
Relevant Log Output
inference time:
original float32  15ms
weight quant 150
integer quant 200

Source code for simple inference testing code
No response

It's too much trouble to answer in detail, so I'll just tell you the conclusion.
It is normal for them to slow down. Explore the Internet and GitHub issues to find the answer. I do not want to give the same answer over and over again.


How can a client write and shutdown TLS 1.3 so that server reads the sent data?

While debugging https://rt.cpan.org/Public/Bug/Display.html?id=125218 and https://github.com/openssl/openssl/issues/5637 I came to a point were either I cannot use OpenSSL properly or there is something fishy in the OpenSSL-1.1.1-pre8.
A client does:
SSL_connect()
SSL_write()
SSL_shutdown()
shutdown(SHUT_RDWR)
A server does:
SSL_accept()
SSL_read()
The code works with OpenSSL-1.1.0h, the server receives all deciphered data without reporting any error:
$ openssl version
OpenSSL 1.1.0h-fips  27 Mar 2018
$ ./a.out
Client
Server
TCP connected.
TCP accepted.
SSL accepted.
SSL connected.
Client SSL_write returned 6
Client write finished.
Client shut down TLS session.
Client shut down TCP.
Server SSL_read returned 6
text
Server SSL_read returned 0
Server thinks a client closed a TLS session
Server read finished.
Server process terminated normally with 0 exit code

If I run the code with OpenSSL-1.1.1-pre8 that uses TLS 1.3, SSL_accept() fails on SIGPIPE:
$ openssl version
OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018
$ ./a.out
Client
TCP connected.
Server
TCP accepted.
SSL connected.
Client SSL_write returned 6
Client write finished.
Client shut down TLS session.
Client shut down TCP.
Server reveived 13 signal
SSL_accept failed:
Server process terminated normally with 1 exit code

Here is the code, certificate in ./cert.pem file  and private key in ./cert.key are not included:
#define _POSIX_C_SOURCE 1
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <signal.h>
#include <errno.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
#include <signal.h>

void handler(int signal) {
    fprintf(stderr, "Server reveived %d signal\n", signal);
}

int main(int argc, char **argv) {
    pid_t server_pid;
    int wstatus;
    int server_socket, client_socket;
    int true = 1;
    struct sockaddr_in6 addr = {
        .sin6_family = AF_INET6,
        .sin6_port = 2000,
        .sin6_flowinfo = 0,
        .sin6_addr = IN6ADDR_LOOPBACK_INIT
    };
    const char message[] = "text\n";
    int processed;
    SSL_CTX *ssl_ctx;
    SSL *ssl;
    int retval;

    server_socket= socket(AF_INET6, SOCK_STREAM, 0);
    if (server_socket < 0) {
        perror("socket failed");
        exit(EXIT_FAILURE);
    }
    if (setsockopt(server_socket, SOL_SOCKET, SO_REUSEADDR, &true, sizeof(true))) {
        perror("setcockopt failed\n");
        exit(EXIT_FAILURE);
    }
    if (bind(server_socket, (const struct sockaddr *)&addr, sizeof(addr))) {
        perror("bind failed");
        exit(EXIT_FAILURE);
    }
    if (listen(server_socket, 1)) {
        perror("liste failed");
        exit(EXIT_FAILURE);
    }

    server_pid = fork();
    if (server_pid < 0) {
        perror("fork failed");
        exit(EXIT_FAILURE);
    } else if (server_pid == 0) {
        /* Server */
        int fd;
        char buffer[1024];
        struct sigaction action;
        sigset_t sigset;

        printf("Server\n");

        sigemptyset(&sigset);
        action.sa_handler = handler;
        action.sa_flags = 0;
        action.sa_mask = sigset;
        sigaction(SIGPIPE, &action, NULL);

        fd = accept(server_socket, NULL, 0);
        if (fd < 0) {
            perror("accept failed");
            exit(EXIT_FAILURE);
        }
        printf("TCP accepted.\n");

        /*if (!OPENSSL_init_ssl(0, NULL)) {
            fprintf(stderr, "OPENSSL_init_ssl failed\n");
            exit(EXIT_FAILURE);
        }*/
        /*OpenSSL_add_ssl_algorithms();*/
        ssl_ctx = SSL_CTX_new(TLS_server_method());
        if (!ssl_ctx) {
            fprintf(stderr, "SSL_CTX_new failed\n");
            exit(EXIT_FAILURE);
        }
        if (1 != SSL_CTX_use_PrivateKey_file(ssl_ctx, "key.pem", SSL_FILETYPE_PEM)) {
            fprintf(stderr, "SSL_CTX_use_PrivatKey_file failed: ");
            ERR_print_errors_fp(stderr);
            exit(EXIT_FAILURE);
        }
        if (1 != SSL_CTX_use_certificate_file(ssl_ctx, "cert.pem", SSL_FILETYPE_PEM)) {
            fprintf(stderr, "SSL_CTX_use_certificate_file failed: ");
            ERR_print_errors_fp(stderr);
            exit(EXIT_FAILURE);
        }
        ssl = SSL_new(ssl_ctx);
        if (!ssl) {
            fprintf(stderr, "SSL_new failed\n");
            exit(EXIT_FAILURE);
        }
        if (!SSL_set_fd(ssl, fd)) {
            fprintf(stderr, "SSL_set_fd failed\n");
            exit(EXIT_FAILURE);
        }
        if (SSL_accept(ssl) <= 0) {
            fprintf(stderr, "SSL_accept failed: ");
            ERR_print_errors_fp(stderr);
            fprintf(stderr, "\n");
            exit(EXIT_FAILURE);
        }
        printf("SSL accepted.\n");

        while (1) {
            processed = SSL_read(ssl, buffer, sizeof(buffer));
            printf("Server SSL_read returned %d\n", processed);
            if (processed > 0) {
                printf("%.*s", (int)processed, buffer);
            } else {
                int ssl_error = SSL_get_error(ssl, processed);
                if (ssl_error == SSL_ERROR_ZERO_RETURN) {
                    printf("Server thinks a client closed a TLS session\n");
                    break;
                }
                if (ssl_error != SSL_ERROR_WANT_READ &&
                        ssl_error != SSL_ERROR_WANT_WRITE) {
                    fprintf(stderr, "server read failed: ssl_error=%d:", ssl_error);
                    ERR_print_errors_fp(stderr);
                    fprintf(stderr, "\n");
                    exit(EXIT_FAILURE);
                }
            }
        };
        printf("Server read finished.\n");

        SSL_free(ssl);
        SSL_CTX_free(ssl_ctx);
        close(fd);
        exit(EXIT_SUCCESS);
    }

    /* Client */
    printf("Client\n");
    client_socket = socket(AF_INET6, SOCK_STREAM, 0);
    if (client_socket < 0) {
        perror("socket failed");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (connect(client_socket, (const struct sockaddr *)&addr, sizeof(addr))) {
        perror("connect failed");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("TCP connected.\n");

    /*if (!OPENSSL_init_ssl(0, NULL)) {
        fprintf(stderr, "OPENSSL_init_ssl failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }*/
    /*OpenSSL_add_ssl_algorithms();*/
    ssl_ctx = SSL_CTX_new(TLS_client_method());
    if (!ssl_ctx) {
        fprintf(stderr, "SSL_CTX_new failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (1 != SSL_CTX_use_PrivateKey_file(ssl_ctx, "key.pem", SSL_FILETYPE_PEM)) {
        fprintf(stderr, "SSL_CTX_use_PrivatKey_file failed: ");
        ERR_print_errors_fp(stderr);
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (1 != SSL_CTX_use_certificate_file(ssl_ctx, "cert.pem", SSL_FILETYPE_PEM)) {
        fprintf(stderr, "SSL_CTX_use_certificate_file failed: ");
        ERR_print_errors_fp(stderr);
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    ssl = SSL_new(ssl_ctx);
    if (!ssl) {
        fprintf(stderr, "SSL_new failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (!SSL_set_fd(ssl, client_socket)) {
        fprintf(stderr, "SSL_set_fd failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (SSL_connect(ssl) <= 0) {
        fprintf(stderr, "SSL_connect failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("SSL connected.\n");

    for (const char *start = message; start - message < sizeof(message);
            start += processed) {
        processed = SSL_write(ssl, start, sizeof(message) - (start - message));
        printf("Client SSL_write returned %d\n", processed);
        if (processed <= 0) {
            int ssl_err = SSL_get_error(ssl, processed);
            if (ssl_err != SSL_ERROR_WANT_READ && ssl_err != SSL_ERROR_WANT_WRITE) {
                fprintf(stderr, "client write failed: ssl_error=%d: ", ssl_err);
                ERR_print_errors_fp(stderr);
                fprintf(stderr, "\n");
                kill(server_pid, SIGTERM);
                exit(EXIT_FAILURE);
            }
            processed = 0;
        }
    };
    printf("Client write finished.\n");

    retval = SSL_shutdown(ssl);
    if (retval < 0) {
        int ssl_err = SSL_get_error(ssl, retval);
        fprintf(stderr, "Client SSL_shutdown failed: ssl_err=%d\n", ssl_err);
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("Client shut down TLS session.\n");

    if (shutdown(client_socket, SHUT_RDWR)) {
        perror("client shutdown failed");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("Client shut down TCP.\n");

    SSL_free(ssl);
    SSL_CTX_free(ssl_ctx);
    if (server_pid == waitpid(server_pid, &wstatus, 0)) {
        if (WIFEXITED(wstatus)){
            printf("Server process terminated normally with %d exit code\n",
                    WEXITSTATUS(wstatus));
        } else if (WIFSIGNALED(wstatus)) {
            printf("Server process terminated with %d signal\n",
                    WTERMSIG(wstatus));
        }
    }
    exit(EXIT_SUCCESS);
}

I suspect shutdown(SHUT_RDWR) is the problem. Client should probably use close only sending TCP direction. But many OpenSSL manuals and articles declare that it's fine for a party to perform a one-side SSL_shutdown and then close the TCP connection completely if the party is not interested in data from the other side.
And actually many codes, e.g Perl Net-SSLeay do not perform SSL_shutdown at all and the server reads the sent data and reports 0 by SSL_read() after client closes the TCP connection. I worry that the new OpenSSL is not compatible enough to support existing code. Is there a way of writing an OpenSSL application that will work with both old and new OpenSSL/TLS version?

This is an interesting problem - perhaps we should add something to the OpenSSL TLSv1.3 wiki page about this:
https://wiki.openssl.org/index.php/TLS1.3
In the TLSv1.3 protocol the server may send some protocol messages after the main handshake is complete. This could in theory also happen in TLSv1.2 (e.g. with a renegotiation) but it happens a lot less frequently. Specifically in TLSv1.3 sessions are not established during the main handshake. Instead, after the main handshake is complete, a server may send some NewSessionTicket messages to the client. The client can then use those tickets to later resume.
In your code the client never attempts to read any application data from the server, and the server never attempts to write any. Nonetheless, after the handshake, the server will automatically attempt to send 2 NewSessionTicket messages. I think what is happening is that the client has already detected the end of the handshake, sent its data, and then closed down the connection. The server meanwhile hasn't finished writing out its tickets and hits the broken pipe.
There are some things that spring to mind that you could do to work around this problem:

Disable automatic sending of tickets from the server. See SSL_CTX_set_num_tickets()/SSL_set_num_tickets():
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_num_tickets.html

This obviously means that you won't ever receive session information, and hence session resumption will not work. But maybe that is ok for you.

Change your application so that the server must write something and the client must read something. OpenSSL will always write its tickets out immediately after the main handshake. By forcing the client to read application data it will then also process any session tickets that were sent.

Do a full two way shutdown. This will ensure any pending protocol messages are dealt with.

Handle the broken pipe signal. In this case the server will be left in a state where it still wants to write out its tickets but it can't. You'd have to swap the write BIO for the server to go to some "/dev/null" style BIO instead and then you should be able to continue.

One further thought on the above is that actually all of options 1, 3 and 4 will mean that session resumption will not work for you (because they all end up discarding or not sending the session tickets in some way). The only option out of the above which enables session resumption is option 2.

Option 5 (if session resumption is important to you): Clients that want to do resumption must be prepared to process post-handshake session tickets at any time - its a fundamental property of TLSv1.3. This could be done by simply calling SSL_read(s, 0) if the read fd becomes readable, and not shutting down until it has got the tickets it wants (or perhaps some timeout has been reached). You can use SSL_CTX_sess_set_new_cb() to detect when a new session has been created.
The more I think about this, the more I think that option 4 is the right answer in the generic case in combination with option 5 if resumption is important.

In general, any remotely nontrivial application should be configuring things to ignore SIGPIPE. It's a goofy workaround for simple UNIX utilities that failed to check the return value of write. The assumption is the utility has no purpose in life but to read and write data from a single pipe and, if the writes are blackholed due to missing error-handling, the process may as well be killed.
Today, programs are much more complex and SIGPIPE remains as a wart that everyone targeting a UNIX-like platform must live with. :-/

It's not clear to me why option 3 wouldn't be able to resume

It's not clear to me why option 3 wouldn't be able to resume

Once we've sent a close_notify we ditch any unexpected handshake messages, so any NewSessionTickets that we may receive are not acted on:
https://github.com/openssl/openssl/blob/345bee916ac5ad28dd269afc24c27fe234c4045b/ssl/record/rec_layer_s3.c#L1558-L1593

I'm wondering if we could do something in the library to make option 4 easier, i.e. basically if we're writing out a NewSessionTicket and get an EPIPE error back then ignore that error and carry as if the operation succeeded. Then all the application has to do is ignore SIGPIPE (which as @davidben suggests it probably should do anyway). Do we think the whole server that only reads/client that only writes scenario is common enough to warrant that?

Thank you for the explanation. Comments to the options:
(1) I tried disabling sending tickets with SSL_set_num_tickets() and it works for me. Great.
(4) I was thinking how to implement ignoring SIGPIPE. Do I understand correctly that after failing SSL_accept() with SSL_ERROR_SYSCALL and EPIPE errno, I should change BIO and retry the SSL_accept() and expect a success? How could I distinguish handshake failure and ticket sending failure because of the EPIPE? Probably by the second EPIPE failure. This work around sounds clumsy.
(2) Changing an application protocol is probably a no-go. I don't have any real use case except the Net-SSLeay tests now. Maybe a syslog over TLS could be an example.
(5) Waiting for tickets in the client before shutting down sounds good. With the shutdown did you mean SSL_shutdown()? Yet I did not tried to implement it.
(3) I tried to implement a full two-way shutdown and while it works wit the old OpenSSL, the prerelease does not work as expected when a client performs a dummy SSL_read() between first and second SSL_shutdown() as recommend by SSL_shutdown(3) manual. The dummy SSL_read() returns 0, but SSL_get_error() reports SSL_ERROR_SYSCALL (with 0 errno) instead of SSL_ERROR_ZERO_RETURN. Is this a know OpenSSL bug? If it does not bother you, here is the program output:
$ ./a.out
Client
Server
TCP connected.
TCP accepted.
SSL connected.
Client SSL_write returned 6
Client write finished.
Client shut down TLS session.
Client SSL_read returned 0
Client read failed: ssl_error=5 errno=Success:
SSL accepted.
Server SSL_read returned 6
text
Server SSL_read returned 0
Server thinks a client closed a TLS session
Server read finished.
Server shut down a TLS session.
Server thinks a client shut down the TLS session.

And the corresponding code:
#define _POSIX_C_SOURCE 1
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <signal.h>
#include <errno.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
#include <signal.h>
#include <string.h>

void handler(int signal) {
    fprintf(stderr, "Server reveived %d signal\n", signal);
}

int main(int argc, char **argv) {
    pid_t server_pid;
    int wstatus;
    int server_socket, client_socket;
    int true = 1;
    struct sockaddr_in6 addr = {
        .sin6_family = AF_INET6,
        .sin6_port = 2000,
        .sin6_flowinfo = 0,
        .sin6_addr = IN6ADDR_LOOPBACK_INIT
    };
    const char message[] = "text\n";
    char buffer[1024];
    int processed;
    SSL_CTX *ssl_ctx;
    SSL *ssl;
    int retval;

    server_socket= socket(AF_INET6, SOCK_STREAM, 0);
    if (server_socket < 0) {
        perror("socket failed");
        exit(EXIT_FAILURE);
    }
    if (setsockopt(server_socket, SOL_SOCKET, SO_REUSEADDR, &true, sizeof(true))) {
        perror("setcockopt failed\n");
        exit(EXIT_FAILURE);
    }
    if (bind(server_socket, (const struct sockaddr *)&addr, sizeof(addr))) {
        perror("bind failed");
        exit(EXIT_FAILURE);
    }
    if (listen(server_socket, 1)) {
        perror("liste failed");
        exit(EXIT_FAILURE);
    }

    server_pid = fork();
    if (server_pid < 0) {
        perror("fork failed");
        exit(EXIT_FAILURE);
    } else if (server_pid == 0) {
        /* Server */
        int fd;
        struct sigaction action;
        sigset_t sigset;

        printf("Server\n");

        sigemptyset(&sigset);
        action.sa_handler = handler;
        action.sa_flags = 0;
        action.sa_mask = sigset;
        sigaction(SIGPIPE, &action, NULL);

        fd = accept(server_socket, NULL, 0);
        if (fd < 0) {
            perror("accept failed");
            exit(EXIT_FAILURE);
        }
        printf("TCP accepted.\n");

        /*if (!OPENSSL_init_ssl(0, NULL)) {
            fprintf(stderr, "OPENSSL_init_ssl failed\n");
            exit(EXIT_FAILURE);
        }*/
        /*OpenSSL_add_ssl_algorithms();*/
        ssl_ctx = SSL_CTX_new(TLS_server_method());
        if (!ssl_ctx) {
            fprintf(stderr, "SSL_CTX_new failed\n");
            exit(EXIT_FAILURE);
        }
        if (1 != SSL_CTX_use_PrivateKey_file(ssl_ctx, "key.pem", SSL_FILETYPE_PEM)) {
            fprintf(stderr, "SSL_CTX_use_PrivatKey_file failed: ");
            ERR_print_errors_fp(stderr);
            exit(EXIT_FAILURE);
        }
        if (1 != SSL_CTX_use_certificate_file(ssl_ctx, "cert.pem", SSL_FILETYPE_PEM)) {
            fprintf(stderr, "SSL_CTX_use_certificate_file failed: ");
            ERR_print_errors_fp(stderr);
            exit(EXIT_FAILURE);
        }
        ssl = SSL_new(ssl_ctx);
        if (!ssl) {
            fprintf(stderr, "SSL_new failed\n");
            exit(EXIT_FAILURE);
        }
        if (!SSL_set_fd(ssl, fd)) {
            fprintf(stderr, "SSL_set_fd failed\n");
            exit(EXIT_FAILURE);
        }
#if OPENSSL_VERSION_NUMBER >= 0x1010100fL
        /* TLS 1.3 server sends session tickets after a handhake as part of
         * the SSL_accept(). If a client finishes all its job before server
         * sends the tickets, SSL_accept() fails with EPIPE errno. Since we
         * are not interested in a session resumption, we can not to send the
         * tickets. */
        /*if (1 != SSL_set_num_tickets(ssl, 0)) {
            fprintf(stderr, "SSL_set_num_tickets failed\n");
            exit(EXIT_FAILURE);
        }
        Or we can perform two-way shutdown. Client must call SSL_read() before
        the final SSL_shutdown(). */
#endif
        retval = SSL_accept(ssl);
        if (retval  <= 0) {
            fprintf(stderr, "SSL_accept failed ssl_err=%d errno=%s: ",
                    SSL_get_error(ssl, retval), strerror(errno));
            ERR_print_errors_fp(stderr);
            fprintf(stderr, "\n");
            exit(EXIT_FAILURE);
        }
        printf("SSL accepted.\n");

        while (1) {
            processed = SSL_read(ssl, buffer, sizeof(buffer));
            printf("Server SSL_read returned %d\n", processed);
            if (processed > 0) {
                printf("%.*s", (int)processed, buffer);
            } else {
                int ssl_error = SSL_get_error(ssl, processed);
                if (ssl_error == SSL_ERROR_ZERO_RETURN) {
                    printf("Server thinks a client closed a TLS session\n");
                    break;
                }
                if (ssl_error != SSL_ERROR_WANT_READ &&
                        ssl_error != SSL_ERROR_WANT_WRITE) {
                    fprintf(stderr, "server read failed: ssl_error=%d:", ssl_error);
                    ERR_print_errors_fp(stderr);
                    fprintf(stderr, "\n");
                    exit(EXIT_FAILURE);
                }
            }
        };
        printf("Server read finished.\n");

        retval = SSL_shutdown(ssl);
        if (retval < 0) {
            int ssl_err = SSL_get_error(ssl, retval);
            fprintf(stderr, "Server SSL_shutdown failed: ssl_err=%d\n", ssl_err);
            kill(server_pid, SIGTERM);
            exit(EXIT_FAILURE);
        }
        printf("Server shut down a TLS session.\n");

        if (retval != 1) {
            retval = SSL_shutdown(ssl);
            if (retval != 1) {
                int ssl_err = SSL_get_error(ssl, retval);
                fprintf(stderr,
                        "Waiting for client shutdown using SSL_shutdown failed: "
                        "ssl_err=%d\n", ssl_err);
                kill(server_pid, SIGTERM);
                exit(EXIT_FAILURE);
            }
        }
        printf("Server thinks a client shut down the TLS session.\n");

        SSL_free(ssl);
        SSL_CTX_free(ssl_ctx);
        close(fd);
        exit(EXIT_SUCCESS);
    }

    /* Client */
    printf("Client\n");
    client_socket = socket(AF_INET6, SOCK_STREAM, 0);
    if (client_socket < 0) {
        perror("socket failed");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (connect(client_socket, (const struct sockaddr *)&addr, sizeof(addr))) {
        perror("connect failed");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("TCP connected.\n");

    /*if (!OPENSSL_init_ssl(0, NULL)) {
        fprintf(stderr, "OPENSSL_init_ssl failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }*/
    /*OpenSSL_add_ssl_algorithms();*/
    ssl_ctx = SSL_CTX_new(TLS_client_method());
    if (!ssl_ctx) {
        fprintf(stderr, "SSL_CTX_new failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (1 != SSL_CTX_use_PrivateKey_file(ssl_ctx, "key.pem", SSL_FILETYPE_PEM)) {
        fprintf(stderr, "SSL_CTX_use_PrivatKey_file failed: ");
        ERR_print_errors_fp(stderr);
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (1 != SSL_CTX_use_certificate_file(ssl_ctx, "cert.pem", SSL_FILETYPE_PEM)) {
        fprintf(stderr, "SSL_CTX_use_certificate_file failed: ");
        ERR_print_errors_fp(stderr);
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    ssl = SSL_new(ssl_ctx);
    if (!ssl) {
        fprintf(stderr, "SSL_new failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (!SSL_set_fd(ssl, client_socket)) {
        fprintf(stderr, "SSL_set_fd failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    if (SSL_connect(ssl) <= 0) {
        fprintf(stderr, "SSL_connect failed\n");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("SSL connected.\n");

    for (const char *start = message; start - message < sizeof(message);
            start += processed) {
        processed = SSL_write(ssl, start, sizeof(message) - (start - message));
        printf("Client SSL_write returned %d\n", processed);
        if (processed <= 0) {
            int ssl_err = SSL_get_error(ssl, processed);
            if (ssl_err != SSL_ERROR_WANT_READ && ssl_err != SSL_ERROR_WANT_WRITE) {
                fprintf(stderr, "client write failed: ssl_error=%d: ", ssl_err);
                ERR_print_errors_fp(stderr);
                fprintf(stderr, "\n");
                kill(server_pid, SIGTERM);
                exit(EXIT_FAILURE);
            }
            processed = 0;
        }
    };
    printf("Client write finished.\n");

    retval = SSL_shutdown(ssl);
    if (retval < 0) {
        int ssl_err = SSL_get_error(ssl, retval);
        fprintf(stderr, "Client SSL_shutdown failed: ssl_err=%d\n", ssl_err);
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("Client shut down TLS session.\n");

    if (retval != 1) {
        /* Consume all server's data to access the server's shutdown */
        while (1) {
            processed = SSL_read(ssl, buffer, sizeof(buffer));
            printf("Client SSL_read returned %d\n", processed);
            if (processed <= 0) {
                int ssl_error = SSL_get_error(ssl, processed);
                if (ssl_error == SSL_ERROR_ZERO_RETURN) {
                    printf("Client thinks a server finished sending data\n");
                    break;
                }
                if (ssl_error != SSL_ERROR_WANT_READ &&
                        ssl_error != SSL_ERROR_WANT_WRITE) {
                    fprintf(stderr, "Client read failed: ssl_error=%d errno=%s: ",
                            ssl_error, strerror(errno));
                    ERR_print_errors_fp(stderr);
                    fprintf(stderr, "\n");
                    exit(EXIT_FAILURE);
                }
            }
        };

        retval = SSL_shutdown(ssl);
        if (retval != 1) {
            int ssl_err = SSL_get_error(ssl, retval);
            fprintf(stderr,
                    "Waiting for server shutdown using SSL_shutdown failed: "
                    "ssl_err=%d\n", ssl_err);
            kill(server_pid, SIGTERM);
            exit(EXIT_FAILURE);
        }
    }
    printf("Client thinks a server shut down the TLS session.\n");

    if (shutdown(client_socket, SHUT_RDWR)) {
        perror("client shutdown failed");
        kill(server_pid, SIGTERM);
        exit(EXIT_FAILURE);
    }
    printf("Client shut down TCP.\n");

    SSL_free(ssl);
    SSL_CTX_free(ssl_ctx);
    if (server_pid == waitpid(server_pid, &wstatus, 0)) {
        if (WIFEXITED(wstatus)){
            printf("Server process terminated normally with %d exit code\n",
                    WEXITSTATUS(wstatus));
        } else if (WIFSIGNALED(wstatus)) {
            printf("Server process terminated with %d signal\n",
                    WTERMSIG(wstatus));
        }
    }
    exit(EXIT_SUCCESS);
}

Have you tried this with the latest version from master? I can reproduce the problem using -pre8, but not using master.

I conducted my test with pre8 only. Now I checked the master and I confirm the two-way shutdown works as expected with it. It was fixed with 93f528f36 commit as issue #6262.

I have to wonder how correct the SSL_shutdown() manpage is when it says
According to the TLS standard, it is acceptable for an application to only send its
shutdown alert and then close the underlying connection without waiting for the peer's
response

Should that at least add something about only in the case you're sure it's not going to send you data back? Or should we just remove that?
(I guess I should at least look up where in the RFC it says such a thing.)

RFC 5246:

If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation must receive the responding
close_notify alert before indicating to the application layer that
the TLS connection has ended.  If the application protocol will not
transfer any additional data, but will only close the underlying
transport connection, then the implementation MAY choose to close the
transport without waiting for the responding close_notify.  No part
of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when
connections are opened or closed.

RFC 8446 has a shorter version of that text that seems to omit the "MAY" clause, I suppose because it's implicit from the condition on the MUST clause.
close_notify is just an EOF. How your application protocol wants to deal with EOF depends on your application protocol. (Personally I think the second mode of SSL_shutdown shouldn't exist at all and the caller should just read to EOF if it wants to get the other EOF. But it's a bit late for that one.)

I'll think about how to improve the SSL_shutdown manpage even
more to at least make it more clear when it's safe to close the
connection without doing a two way shutdown.
It's already rewritten to suggest to use SSL_read() for the 2nd
part, I guess I can also make it more explict that this second
mode is not needed if SSL_read() was used.

On Mon, Aug 13, 2018 at 07:24:02PM +0000, mattcaswell wrote:

@ppisar perhaps you could try out the patch in #6944?

The commit fixes one-way SSL_shutdown() followed by full TCP shutdown
scenario. Then the server can read all the data the client sent before.
If OpenSSL default BIO used send(..., MSG_NOSIGNAL) instead of write(),
applications would not have to deal with SIGPIPE signal. The only drawback is
that send() needs a descriptor of socket type. It would not work on other
types of descriptors. Although I cannot image why somebody used OpenSSL on top
of non-sockets.

The wiki currently also says:
An OpenSSL client will only process received sessions when they attempt to read application data. During the read if a session ticket message is encountered then it will be automatically processed. A consequence of this is that if a client application never attempts to read data from the server then it will never receive a session and hence resumption will not be possible. For that reason, if session resumption is required, then it is recommended that clients always perform at least one read between establishing and shutting down a connection.
I doubt this is currently documented in the documentation. And I actually prefer that shutdown handles this instead.

Thank you for the fix. I confirm it fixes SSL_accepting() a half-closed TCP connection.

Sorry I'm a bit of a newbie here.  I think this patch mentioned maybe doesn't help fix things for those of us that use a BIO, is that right?
In my head the difficulty is this: sometimes we don't control the client, only the server, so we can't "always enforce" a two way shutdown.  It's mentioned as optional anyway.
So if you're building a more "generic" transportation library, things get a bit funky.  When a user upgrades to openssl v1.1 suddenly (if their transport protocol doesn't include the client reading anything from the server, which is common in unit tests) things can start crashing.  But it's only "sometimes" because depending on how the timing ends up, maybe the socket has already been closed, maybe it hasn't, when the server sends its post handshake session ticket.  So you get flakey "broken pipe" messages.  In essence every library that uses OpenSSL suddenly now might have flakey unit tests.   The workarounds mentioned above do work (note to self, had to set the ticket num on the context before creating the SSL object).  It's confusing.  How can we know when SSL_Accept fails, if it's due to a "graceful" client closed the connection without reading, vs. non-graceful?  How to know that we can turn around and still call SSL_Read, sometimes, after an SSL_Accept just failed?
Kind of a fault of the spec...

After SSL_accept() failed, you can never call SSL_read().
So are you saying that there are still EPIPEs that we don't ignore?
Or that the EPIPE is seen a custom BIO, that the BIO returns some
error, and that we don't ignore that?

Yeah it's in a "scripting-ish" language (crystal) so the EPIPE from within the BIO causes it to raise an exception all the way out through SSL_Accept.
I did have a thought similar to #7948 maybe it could write tickets "with the first write" or configurably do so, or something like that?  Just an idea.  Thanks!


AdminConsole: /admin works for all ports?

Sachin Garg wrote:
I also verified that if i add  in  with port and basic auth then it works for that particular port but if hit comes from some other port with url as /admin then also it goes to admin console.
Below is my settings:

URl should work like http://localhost:8009/admin
but it is also working for http://localhost:8080/admin (without asking for username/password)
Should be backported to 4.0.X branch also.

this is not the case.
the web:servletTransport ignores the "port" attribute, as ports are configured within the web server configuration.


Winston colors don't work with docker

If you run winston in container (in my case boot2docker OSX), colors get lost.
This doesn't happen with debug npm library e.g.

I believe it is because it is not a tty.

One can run a container with a -t -> Allocate a *pseudo*-TTY. That may be the issue.

Having the same frustration running with forever.
# -c Allows me to monitor the logs in terminal, rather than having Forever move them to a file.
forever -vw -c node test.js

Output is not a TTY and this disables the color. I'd like the option to overrule this behavior, but I'm not sure if Winston is the one breaking this, or if it's something directly related to the console.
Also, piping into less -R doesn't show the colors, though I feel it should.

...and fixed
passing --color=always to my program fixes this issue. The issue is not with Winston, but with Marak/colors.
That being said, Winston could enable the option with
var colors = require("colors");
if(somethingSaysIShouldColor)
    colors.enabled = true;

If I write a program and manually set require("colors").enabled = true, then it enables the colors for my (non-TTY) program, but not for included programs like Winston.
enabled option found here

thanks @tarwich
:+1:

Fixed in #751. Released in<EMAIL_ADDRESS>


Update CI workflow matrix for VFX-CY2022.

Signed-off-by: Christina Tempelaar-Lietz<EMAIL_ADDRESS>

This matrix contains all the builds we discussed except Linux no-python builds (was getting errors) and Windows debug build (still need to try it).

Just realized the issue with the failing Linux no-python builds may have to do with not sending the same flags when the "Example" project is built. It's late so I'll try that later this week and add those builds in a separate commit.


feature/fluent-plugin-grok-parser

Q
A

Bug fix?
no

New feature?
yes

API breaks?
no

Deprecations?
no

Related tickets
https://github.com/banzaicloud/logging-operator/issues/877

License
Apache 2.0

What's in this PR?

Added support for https://github.com/fluent/fluent-plugin-grok-parser.
Updated:

parser.go
CRDs
docker image
helm charts

Checklist

[x] Code meets the Developer Guide
[x] User guide and development docs updated (if needed)
[x] Related Helm chart(s) updated (if needed)

@petergvizd Thanks for the contribution, could you please accept the cla?

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


Issue fixed.

Pull Request Merged resolving the issue #24 by @JanitaRiyaz. Thanks for your contributions.


Option to restrict generated lib line width

This MR adds the lib_max_width option to nbdev. This option constrains the generated lib to specific line width.
When running some lint on the nbdev generated library sometimes the __all__ function it's too big. This MR avoids lint warnings by adding the lib_max_width option to restrict the size of __all__ lines.

What linter are you using?  Can you set your linter to ignore __all__ lines ?
For the rest of the generated code, if you are worried about width, you can use the black_formatting=True option in settings.ini that will format your code according to black.
Perhaps that could solve your issues?

@hamelsmu sorry for the late reply. I'm using flake8, I couldn't find a way to ignore the __all__ lines but the black_formatting=True worked. Thanks!


Typo fix Update README.md

Description
The command provided for adding a path to ~/.zshrc uses the -n flag with echo:
echo -n 'export PATH=$HOME/bin:$PATH' >> ~/.zshrc

The -n flag suppresses the newline, which can cause the appended line to merge with the last line in ~/.zshrc. This may lead to configuration errors, especially if the file does not end with a newline.
Fix:
The corrected command removes the -n flag:
echo 'export PATH=$HOME/bin:$PATH' >> ~/.zshrc

This ensures proper appending of the line, preventing potential issues with shell configuration.
Importance:
This fix is crucial for ensuring that users setting up LaTeX on Mac systems follow accurate and reliable instructions. Incorrect configurations can lead to debugging challenges, particularly for users unfamiliar with shell scripting or environment setup.
Changes:

Updated the relevant command in the documentation to remove the -n flag from echo.

Testing:
Tested the corrected command on macOS with Zsh to verify that it appends the path configuration properly to ~/.zshrc without breaking existing configurations.
Please review and merge to improve the accuracy of the setup guide. 😊
Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have run yarn style without getting any errors
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

cc @vplasencia


mouse pointer disappears

I have a problem where my mouse pointer keeps disappearing.
I have a M1 Pro MacBookPro with Monterey 12.2.1, Yabai version 4.0.0
When I stop the Yabai service I have zero issues with the mouse pointer disappearing. But when I start the yabai service, I see the mouse disappear for 1 second then come back for roughly 7 seconds. This cycle repeats 4 or 5 times. When the mouse is gone, moving the mouse doesn’t help, but it will come back after that 1 second period. And I mentioned that it repeats 4 or 5 times. It will then stop as long as I don't touch the mouse. As soon as I do, I get another 4 or 5 repeats of the on/off cycle.

and of course, after posting this, I started Yabai again and not having the issue, but I am confident it will start again soon.....ugh. these problems are the frustrating ones.

yabai does not touch the visibility of the cursor; this is some other software you are running. In macOS cursor visibility is a global setting.

当然，在发布这个之后，我再次启动了 Yabai 并且没有遇到问题，但我相信它很快就会再次启动......呃。这些问题令人沮丧。
Dude, I have exactly the same problem you have, when I turn on the focus_follows_mouse then the same problem will appear.hat's not going to happen when it's off.Have you found a suitable solution？

Dude, I have exactly the same problem you have, when I turn on the focus_follows_mouse then the same problem will appear.hat's not going to happen when it's off.Have you found a suitable solution？

I have the same issue. As soon as I stop yabai, the issue is gone.
However I have a lead/idea: on macos the cursor disappears when typing in an input (eg this textarea) - has been this way for as long as I can remember. I could imagine that yabai is somehow triggering that behaviour.

您好，这里是杜炳霖，您的邮件我已经收到了，我会尽早阅读后给您回复。如果事出紧急，请联系电话18944525557。

I'm facing the same issue on two machines. I'm suspecting manage=off layer=above rules.

Is it possible that you were running Bartender with Yabai?
https://www.macbartender.com
Stopping Bartender made the problem (supposedly) go away.

Just came here because I've been experiencing the same invisible cursor problem.  The cursor is only missing when going over certain windows and those 'certain windows' are different each time this happens.  I noticed today that restarting yabai restores the cursor visibility.
@rubas  I do have Bartender installed.  I haven't tried restarting Bartender to fix the issue, but restarting Yabai fixes the problem.

@albertsj1 Since I stopped using Bartender, I had no issues any more.

Thanks @rubas .  I honestly haven't noticed the problem in a couple of months now, but I have an even worse problem now with the new Yabai release when using layer=above and manage=off that causes the window to be blurred.  I just checked and using bartender doesn't seem to be causing the blur issue I'm now seeing.


also make (-am) dependencies when running mvn

maven does not build dependencies (libraries) automatically for projects identified by the -pl switch. The option -am fixes that.

As I said in the issue page, this option well force and not use NX cache. I published the version 2.3.0 to force executing the command on the root folder even you use the app folder for that.

Obsolete, and it would be the wrong approach anyway, as I've realized.


Routing help needed

Hi,
Any idea what kind of routing should be made in scenario like this:
openg5s core running in <IP_ADDRESS>/16
eupf running in completely different pc <IP_ADDRESS>/16 (build from source), same pc has also secondary ips <IP_ADDRESS>-<IP_ADDRESS>
iperf3 servers running in the same pc as eupf (<IP_ADDRESS>).
UE and GNB are real ones, UE attach and PDN setup is OK.
With UE I can ping <IP_ADDRESS> but I can't see any ICMP packets with wireshark/tcpdump in <IP_ADDRESS> pc, I can't understand why...
Ping to <IP_ADDRESS> or any other IP won't work, I can see ICMP coming from UE in this case, replies are not working.
Iperf3 to <IP_ADDRESS> is not working either, I can see UE trying connection in wireshark but no answer from server.
UE IPs are from <IP_ADDRESS>/24.
GNB IP <IP_ADDRESS>/16
I would like to not have any dedicated data network gateway, just use the same PC where eupf is running. I don't need any outside connection just ping/iperf3 from my own PC.
Thanks
Edit:
How to get ICMP reply back to GNB as it seems like the PC(<IP_ADDRESS>) is asking who has <UE_ip> via ARP?
If  "ip route add <IP_ADDRESS>/24 via <IP_ADDRESS> dev enp1s0" is set then I can see <IP_ADDRESS> replying to ICMP and it's going to GNB but UE will not see the reply.

Hi @Sabreu,

With UE I can ping <IP_ADDRESS> but I can't see any ICMP packets with wireshark/tcpdump in <IP_ADDRESS> pc, I can't understand why...

eUPF is based on xdp ebpf program. All packets interface xdp program attached to are processed earlier than tcpdump can catch them(except packets passing to kernel explicitly by xdp program).
eUPF by design can't forward packets to the same host where it works. This is because it's not possible to inject N6(downlink) packets from host to N3 tunnel via XDP.
In order to test iperf you have to deploy iperf server at least on a separate network interface within the same host (or on sepatare host).

If "ip route add <IP_ADDRESS>/24 via <IP_ADDRESS> dev enp1s0" is set then I can see <IP_ADDRESS> replying to ICMP and it's going to GNB but UE will not see the reply.

It was a bug in eUPF until v0.5.2. eUPF didn't add gtp extension header with QCI to gtp packet. Some gNB ignored such response packets from eUPF. Please check that you used eUPF v0.5.2 for your tests.
-- BR, Alex

@pirog-spb
Thanks a lot! yes that was the part we were missing (we were thinking that yesterday but I thought we could route it some other way easier).
With 14900K 5Gbps (UDP) seems easy effort for eupf 👍
One thing seems odd to me, TCP DL (UE point of view) is only a few hundred kbps but TCP UL is working fine. Any idea what could cause that?
Thanks

One thing seems odd to me, TCP DL (UE point of view) is only a few hundred kbps but TCP UL is working fine. Any idea what could cause that? With open5gs upf we have not seen this kind of issue.

Could you share more details?
Common issue with iperf on veth interfaces is a wrong csum in DL packets. The solution is to disable checksum offloading on iperf network interface. Still not sure that it is relevant in your case but why not.

@pirog-spb
Thanks a lot again, it was checksum offloading. TCP working nicely now 👍


.NET 7: OpenAPI for minimal APIs

Article can mostly feature sample code written in https://github.com/dotnet/AspNetCore.Docs.Samples/issues/79
OpenAPI improvements for minimal APIs

Looks like it's already done in OpenAPI support in minimal APIs - ASP.NET Core but we should verify there isn't anything new to add.


Line breaks and tabs not working

Hello!
Very promising component. I've just started experimenting with it and I noticed that line breaks and tabs are not supported with \n and \t within the value property.
<a-entity troika-text="value: Hello\nWorld!;"></a-entity>

I noticed it was in the documentation, so was hoping it would function as expected.
Should this be currently supported?
Thanks!

Oh, that's very interesting. The documentation is mostly copied from the underlying JS component, which does indeed support \n and \t because that is how you represent newlines and tabs in JavaScript. But since AFrame markup isn't JavaScript I suppose that wouldn't work.
Does it work if you use literal newlines and tabs in your markup? Or with the appropriate HTML entities for those characters?

To answer my own question: Yes, literal newline and tab characters within the markup do appear to work (* see below). Using HTML entities does not -- it seems to break the parsing -- but I think that's related to how AFrame parses attribute values.

(*) There appears to be another issue that makes newlines wrap on top of each other; this looks like a problem with how default lineHeight is applied, and I'll push a fix for that asap.

I've pushed an update to the docs that clarifies using literal newline/tab characters in the HTML markup. I've also fixed the lineHeight default issue. Please let me know if you continue having issues with it.
And thank you for testing and providing feedback! I'm a fan of AFrame but don't use it in my day job so I haven't had much opportunity to dogfood this component. I appreciate help identifying ways to make it stronger. 😄

Thanks for the feedback, @lojjic ! And sorry for the delayed response.
If it's at all helpful, A-Frame provides an API for parsing component properties through the schema: https://aframe.io/docs/1.0.0/core/component.html#custom-property-type
Being that the A-Frame text component handles the \n and \t characters as expected, that could possibly be a useful reference for implementing within your component.
If it's not something you think you'll get around to, I may tinker a bit with it in the future. I really think using Troika for text has quite a few advantages over A-Frame's core text component, however now all of them are yet implemented in this component. I think the clipRect would be a game-changer, but that's obviously unrelated to this issue.
Anyway, thanks!

Being that the A-Frame text component handles the \n and \t characters as expected

Oh! I didn't realize that. Well if the core text component does it, then there's no reason I shouldn't be able to. Thanks for the link, I'll take a look at that and how the core text component handles it and try to match.
(Update: well I looked at the source and they just do a regex replace in the component. Easy enough! 😆)
Thanks for the note about clipRect, I opened #10 for that. Not sure why I didn't expose it before.


Allow docker.yml action to run within developer fork.

Type of change
Select the type of your PR

Bugfix

Description
The docker.yml github hub flow action should only run when properly configured.   Makes its execution conditional and document what a developer would need to do to use the action in their own fork.
This change moves the QUAY_USER from secret to variable, so the workflows execution can be made conditional on it.
It also factored out a second variable QUAY_ORG.
Why: The github action was failing when run in my fork ending with an error message.  This created distracting emails.
buildx failed with: ERROR: failed to solve: failed to push quay.io/kroxylicious/kroxylicious-developer:0.3.0-SNAPSHOT: unexpected status from POST request to https://quay.io/v2/kroxylicious/kroxylicious-developer/blobs/uploads/: 401 UNAUTHORIZED

Additional Context
Why are you making this pull request?
Checklist
Please go through this checklist and make sure all applicable tasks have been done

[ ] Write tests
[ ] Make sure all tests pass
[ ] Review performance test results. Ensure that any degradations to performance numbers are understood and justified.
[ ] Make sure all Sonar-Lint warnings are addressed or are justifiably ignored.
[ ] Update documentation
[ ] Reference relevant issue(s) and close them after merging
[ ] For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

LGTM, assuming one has QUAY_USERNAME defined in the fork.
Worth adding that to the dev_guide?

Yes, I think that's useful.
I should make a further change to the action to follow this pattern, so that the action only runs if the required secrets are present.  This would mean that the action doesn't break fail on the developer's fork.    WDYT?
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-secrets

If already updated kroxylicious to have a variable QUAY_USER.  Once this PR is merged, I'll remove the secret as it will then be redundant.


how to parse transactions

I'm currently working on a sol back-end wallet project. I'm familiar with eth series. I know that a TX contains from, to and amount.
However, I found that there is no explicit amount field in Sol's API. Instead, it is divided into postBalances and preBalances.
so,do I need to build postbalances, prebalances and accountkeys into a data struct and calculate the amount? I count found how to parse instructions.data.
Can you give me some advice?

Transactions on solana are made of one or more instructions.

Each instruction specifies a set of accounts, and data encoded as a binary blob.

That binary blob can be anything and is entirely depended on how the program works and what it expects.

In the case of SOL transfers from one wallet to another, the system program is used.

You cans see here an example of how to send SOL here: https://github.com/gagliardetto/solana-go#transfer-sol-from-one-wallet-to-another-wallet

How to decode a raw transaction into its elemental instructions? See here: https://github.com/gagliardetto/solana-go#transfer-sol-from-one-wallet-to-another-wallet

The preBalances and postBalances (and preTokenBalances, postTokenBalances) are metadata that's added after the instruction has been executed.

Wow, thank you for replying to me so seriously. Based on your reply, I learned some relevant knowledge points, but I'm sorry I encountered new problems again.
Suppose I have a Solana account. When I want to receive a token transfer, I must first create an associated account. Does that mean that the transferor must do this for the receiver? From the perspective of programming, do I have to judge whether this address is a token address? Then it depends on whether I want to create an associated account or not?
We look forward to your valuable reply

I'm no expert on this topic (and you're better off asking/searching that question in the solana documentation, discord, or even better on solana stackoverflow).
The Sollet solana wallet is opensource, and you can see the code implementation of this and other dynamics: https://github.com/project-serum/spl-token-wallet
They are fairly easily portable to solana-go (often).

From my limited knowledge on the topic, yes the sender must create the associated-token-account for the recipient if the associated-token-account doesn't exist.
What is an "associated token account"? It's an account derived from the owner of the parent wallet (in your case the recipient) and the mint of the token.
Something like this: (wallet + mint) => associated_token_account (because it's an inextricably associated token account with the wallet it's for.)
Knowing the wallet and the mint, you can find the atok account.
Knowing the atok account, you can find the owner wallet and the mint.
AFAIK anyone can create an associate token account for anyone else, but the owner is always the wallet it was created for.
The --allow unfunded recipient --fund recipient flags (I think) are there because if the atok account doesn't exist, you need to create it. To create an account on solana, you need to fund it with enough SOL so that it can pay rent and won't get deleted (evicted).

Anyway, you're better off going to look into the documentation and the source code:

https://spl.solana.com/associated-token-account
https://github.com/solana-labs/solana-program-library/blob/master/associated-token-account/program/src/instruction.rs

You need an atok for storing and transfering for anything that's a token.

Thank you for your serious reply. With your help, I have a new understanding of Solana access transaction. Thank you again


Set all fields to null on 'reset' command in formflow

Tested this with the formflowbot locally without issue, this code only runs when the "reset" command is given by a user and only resets steps marked as 'field' within a form, this results in the desired functionality for "reset" where all fields are reprompted to the user from the start.
Previously when a 'reset' command was issued the bot would reset the formState but leave the internal state alone, meaning that the values entered into it would still persist. This was meant for them to act as default values for the form, but when the first field was reprompted and an input was entered the other states would evaluate to "completed" due to the "skipstep" function. This fix avoids that by just setting all fields back to null (their original value) when reset is issued.

Any updates on when or whether this will be merged?

Closing this PR because the code for this repository has been moved to https://github.com/Microsoft/BotBuilder-V3  If you think this PR is still relevant, please re-submit on the new repository.


use default party button

"Use Default Party" button was added to the first text field in the SendForm component. Clicking the "User Default Party" triggers the onAdminClick event handler to populate the userAdmin's party ID in the text field.

This PR accidentally picked up a ton of build files. I'm closing it and we'll submit a separate clean PR for this change.


add import/export feature for configuration settings

enable importing/exporting of graph viewport and configuration settings

low priority do later

done


Make pushgateway systemd service start at install

Sorry for the delay and thanks for contribution! :+1:


Separate repo for web app?

Should the web app really live with the SDK? My only concern (that currently comes to mind) would be versioning - that a version bump in the app may infer to others a version bump in the SDK, that may then require changes/action.
This would be the fastapi layer and above.

We've decided that having them in the same repo is more than sufficient, especially for now, if not for the entire lifespan of the project whilst under the SSEC.


[WIP] An applet for controlling a quad-SPI (QSPI/QPI) bus

Remaining work:

[x] wait for upstream issues to be resolved in amaranth 0.5.1

https://github.com/amaranth-lang/amaranth/issues/1418
https://github.com/amaranth-lang/amaranth/issues/1405
https://github.com/amaranth-lang/amaranth/issues/1417
https://github.com/amaranth-lang/amaranth/issues/1414
https://github.com/amaranth-lang/amaranth/pull/1448

[ ] address FIXMEs

[ ] # FIXME: should this be 2 or 3? the latency differs between i[0] and i[1] (IOStream)
[x] # FIXME: needs new name and location (Downscaler)
[x] # FIXME: i_stream/o_stream or fast/slow? [io]_stream has opposite meaning of IOStream (Downscaler)

[x] add local SimulationPort to make IOStream tests pass
[x] put IOStream into its own file under glasgow.gateware?
[x] add chunking to all commands
[x] with iface.select()?
[x] support for lowering SCK frequency
[x] support for setting SCK frequency from CLI
[x] support for delays
[x] support for synchronization
[x] kill or replace iface.transfer
[x] some default interact implementation, like for spi-controller?
[x] order pins as sck, ioN, cs (for convenience of multiple cs)
[x] commit tests to repo
[x] reduce redundancy in get/put/swap/dummy stream transfer implementations
[x] port memory-25x to this applet (even without adding new commands)

[x] deprecate and remove hold_ss first, maybe? https://github.com/GlasgowEmbedded/glasgow/pull/626
[x] memory-25x does not drive the bus when CS# is deasserted

happens inherently for IOx, but was enabled explicitly for SCK

memory-25x makes IO2/IO3 optional

for now IO2/IO3 become mandatory

This is ready for test and review now!


Support cocoapod import

Many RN projects are handling their dependencies through Podfile in order to skip a lot of the manual integrations steps.
This is almost enabled by every IOS RN library out there.
Would be great to be able to add one to bugsnag-react-native as well.
Had something like this in mind. Haven't got it up and running yet thought as I'm not too knowledgeable what should be imported in kscrash either?
Another alternative is to make the library use cocoapods as well instead of vendoring. But that requires all RN projects to use cocoapods which might not be wishful.
require "json"
package = JSON.parse(File.read('package.json'))

Pod::Spec.new do |s|
  s.name          = package['name']
  s.version       = package['version']
  s.summary       = package['description']
  s.author        = "Bugsnag"
  s.license       = package['license']
  s.requires_arc  = true
  s.homepage      = "https://github.com/bugsnag/bugsnag-react-native"
  s.source        = { :git => 'https://github.com/bugsnag/bugsnag-react-native.git' }
  s.platform      = :ios, '6.0'
  s.libraries     = 'z'
  s.source_files  =
    "cocoa/vendor/kscrash/Source/KSCrash/**/*.{h,m}",
    "cocoa/vendor/bugsnag-cocoa/Source/*.{h,m}",
    "cocoa/*.{h,m}"

end

Thanks for the report, @ptomasroos. Currently, the installation process doesn’t require any manual steps in Xcode or vendoring. The required files are bundled into the project (including the bugsnag-cocoa library and the required subspec of KSCrash). So installation like so should provide everything you need to get started:

npm install bugsnag-react-native --save
react-native link

Initially we handled iOS installation through either CocoaPods or vendoring, but unfortunately this led to more confusion rather than less since most users approaching React Native are not as familiar with CocoaPods and the iOS ecosystem. Though with that said, I may take another look at this process at another time if the current process proves prohibitive. There is already pods for bugsnag-cocoa and KSCrash, so it would be a matter of:

Packaging source files BugsnagReactNative.{h,m}
Adding a resource for Bugsnag.js
Linking against the React Native headers

Take our app for instance
85% av all rn are being imported through podfiles rather than manual linking.
Looking at some facts
package name:                           downloads last month on npm
react-native-code-push                  30,514
react-native-device-info                30,378
react-native-fbsdk                      16,616
react-native-fcm                        9,013
react-native-google-analytics-bridge    6,108
react-native-image-picker               23,933
react-native-linear-gradient            25,536

bugsnag-react-native                    2,585

Plus we're a paying customer of yours. I think it would be fair to provide a podspec. I dont say we need to go all the way to declare your dependencies through podfiles but at least make sure we who want to use podfiles to manage your builds do it by having a podspec?

85% av all rn are being imported through podfiles rather than manual linking.

Interesting. I think we are having a bit of confusion over what "manual linking" means. I was referring to requiring any action in Xcode after installation. Did you mean something else?

Is there a big problem just having a podspec? It would allow people to choose.
Well rnpm adds manual rows to the project file in terms of header search path, special linking.
When you have multiple targets this gets to be a manual process to add this in build spyware but when using pods all of this stuff is already handled. Again a much superior technology.

Is there a big problem just having a podspec? It would allow people to choose.

Well, it is always an issue of better understanding the problem, and ensuring we can support people effectively when they have questions. There is a large amount of experience diversity when it comes to React Native projects in particular, where we have people coming from iOS, Android, or client-side JavaScript backgrounds, and an approach to handling that is to ensure there is a “golden path” when it comes to using the library. Thus far, the most reliable approach has been to minimize Xcode usage and the number of commands run. That is why I am hesitant to add (and officially support) CocoaPods installation separately, as it as a dimension to the process, documentation, and types of ways integration can go wrong.

When you have multiple targets this gets to be a manual process to add this in build spyware but when using pods all of this stuff is already handled.

That makes sense. Thus far, react-native link has not proven particularly robust when handling multiple targets. I’ve made a draft of what a podspec would need to contain to include the dependencies, though it would need further testing. Perhaps you could give it a try: https://github.com/bugsnag/bugsnag-react-native/commit/a097d836c7df0117c525126712bf2032b7f5bf27 ?

Thanks @kattrali Will test it today!

@kattrali just tested https://github.com/bugsnag/bugsnag-react-native/commit/a097d836c7df0117c525126712bf2032b7f5bf27. Working fine. Thanks.

Awesome, thanks @skv-headless.

Thanks for the work to get podspec working @kattrali !


Add remaining matrix copy and transposition routines

Description
Some matrix copy and transposition routines were added in #227. This PR adds the remaining routines from the spec, including non-batch and group-batch interfaces.
Checklist
All Submissions

[x] Do all unit tests pass locally? Log: test.txt
[x] Have you formatted the code using clang-format?

New interfaces

[x] Have you provided motivation for adding a new feature as part of RFC and
it was accepted? spec #420
[x] What version of oneAPI spec the interface is targeted? (1.2 provisional rev1)

New features

[x] Have you provided motivation for adding a new feature?
[x] Have you added relevant tests? (all new interfaces have unit tests)

@mkrainiuk @vmalia Can we get a couple reviews for this when you get a chance? BLAS team has reviewed and approved.

@dnhsieh-intel Can someone look at this please? We have approval from BLAS.

I have one quick question: did you test it with other GPUs and backends except Intel GPU with Intel oneMKL?

I have one quick question: did you test it with other GPUs and backends except Intel GPU with Intel oneMKL?

No, since these are MKL-specific extensions it should throw a not implemented exception for other backends. Should I test that such exceptions are thrown as expected?

Can I get another approval since Brian's approval wasn't "official"? I don't think a thorough review is required since Brian actually reviewed, I just need the button to turn green...

I have one quick question: did you test it with other GPUs and backends except Intel GPU with Intel oneMKL?

No, since these are MKL-specific extensions it should throw a not implemented exception for other backends. Should I test that such exceptions are thrown as expected?

I see, in this case I think it's fine, since the unimplemented exception is the same as in the existing tests.


luci-proto-sstp errror:Network device is not present and connection is not established.

luci-proto-sstp
Add new interface with name VPNSSTP
SSTP server                            sstp.test.com
PAP/CHAP Username             test
PAP/CHAP password              test
connection is not established with an error:Network device is not present and no messages in system log.
If  replace the domain name (sstp.test.com) with the ip address (<IP_ADDRESS>) then there is no error and connection is not established. If you add --cert-warn --tls-ext to the Extra sstpc options field (Tab Advanced settings), then there is still no connection.
Log:
Thu Jul  7 11:19:19 2022 user.notice URL-DEBUG: hotplug (iface): action='ifdown' interface='VPNSSTP'
Thu Jul  7 11:20:20 2022 daemon.notice netifd: Interface 'VPNSSTP' is setting up now
Thu Jul  7 11:20:21 2022 daemon.notice netifd: VPNSSTP (7483): Command failed: Unknown error
Thu Jul  7 11:20:21 2022 local0.notice sstpc[7548]: Resolved <IP_ADDRESS> to <IP_ADDRESS>
Thu Jul  7 11:20:23 2022 local0.notice sstpc[7548]: Connected to <IP_ADDRESS>
Thu Jul  7 11:20:31 2022 daemon.notice netifd: VPNSSTP (7483): Command failed: Unknown error
Thu Jul  7 11:20:46 2022 local0.debug sstpc[7548]: Unrecoverable SSL error 0
Thu Jul  7 11:20:46 2022 local0.debug sstpc[7548]: HTTP handshake with server failed
Thu Jul  7 11:20:46 2022 daemon.notice netifd: VPNSSTP (7548): **Error: HTTP handshake with server failed, (-1)
Thu Jul  7 11:20:46 2022 daemon.notice netifd: Interface 'VPNSSTP' is now down
If run sstpc --cert-warn --tls-ext --user test --password test sstp.test.com --log-level 3, then everything works fine, but no data in luci.
Additional Information:
OpenWrt version information from system /etc/openwrt_release
ISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='21.02.0-rc3'
DISTRIB_TARGET='ramips/mt7621'

Usually "Network device is not present" means, that there is no route to reach your server. probably, you should tick default route on your wan connection or manually add route to your routing table

I think this is not a LuCI issue.
Please have a look at the sstpc proto.
There you can see how the netifd calls sstpc.
You can try to replay the behavior of netifd and find out which argument is interrupting the call.

@enaess: What do you think about it?


Currently ExpenseItem's name under the same Claim needs to be unique, is this the behaviour we want?

Hey guys,
Currently ExpenseItem's name under the same Claim needs to be unique.
That means you can not have two ExpenseItems with the same name inside one claim.
Is this the behaviour we want?

I dont think it really matters

I changed the code so it doesnt have to be.


Reducing the log level for github commit to info

The logger by default attempts to fetch the commit id from kodata.
When that fails log a message with info rather than warning, to
avoid creating spurious warning message when starting applications.
Fixes #505
Signed-off-by: Andrea Frittoli<EMAIL_ADDRESS>

/retest

I think this is a good first step! That should not be a warning for sure.
In the long run I hope someone will address https://github.com/knative/pkg/issues/441 - libs should opt into logging instead of always doing it and not letting the user control when it happens.

/assign @mdemirhan


#221 export types of Form components

@TheHadiAhmadi why do we need this?

For all components we have this export, except Form components.

CustomFormInput.svelte
<script lang="ts">
  import type {FormInputProps} from 'yesvelte'
  type $$Props = FormInputProps & {
     customProp: boolean
  }
  ....
  export let customProp: boolean = true;
</script>

<FormInput {...$$restPorps} {customProp}/>

@TheHadiAhmadi if we want to export types, we should apply this for ALL types, not just for Form types, shouldn't we?

@pournasserian yes it would be useful, I taught we are exporting types of all components. I'll update this PR and will edit other index.ts files too

Also alternative way is:
<script Lang="ts">
import type {ComponentProps} from 'svelte'
import {Button} from 'yesvelte'

type $$Props = ComponentProps<Button> & {
.....
}
</script>
....

@pournasserian what do you think, should we export component types?


Is there a way to implement default value for PDFTextField?

I am trying to implement something like setText, but to set the default value for a text field. Something like setDefaultValue. Is there a way to implement this?
For context, I need to set the default value for text fields. The default value will be available for backend systems that try to fill in the user values. But when you print the pdf these values will not be printed and the user is free to write on the printed pdf.

I don't think this is possible with any tool/library. Are you able to achieve something similar with Acrobat or other PDF tools/libraries? If so, let me know and I can look into this further.


Add message about API not being available yet.

A small message stating that google-cloud-speech isn't released yet.
See #2515.

LGTM.  You need to add reverting it to your "release speech" checklist somewhere. ;)

@tseaver thanks! I added it here https://github.com/GoogleCloudPlatform/google-cloud-python/issues/2522

@daspecster You should also remove the RST docs from the build (you could just delete them and put them back, you'll need to temporarily ignore the modules in the verify_included_modules.py file as well.

So you would opt for not having the warning but just removing the docs until the release?

I (stupidly) assumed you updated the README, not the RST file. My bad.
I'd say it'd be better not to have the docs show up before release (especially in our /stable/ docs) but it's your call.

Makes sense, I think this is good to hash out moving forward as well. As new services are added it would be good to make it clear for users.


geoseries events added

What does this PR do?

Added the geoseries event details!
Added @AayushChand1 name on the poster contribution

Consideration
N/A
How to test?
will be available after publish in a github page.

I will resolve this conflict after filling all the required details.


Spacing the sections to full screen, i.e, about hackclub, hackclub rait, vision.

Is your feature request related to a problem? Please describe.
It would look great if the sections are of the resolution of full screen, after making it full screen we'll need to make the text centralized. Also a slight transition delay of 500ms in the hover effect of navigation bar would look beautiful. One more change I can suggest is that on the home page "HackClub RAIT Initiative for students by students" can come with a transition of fade down, it'd look beautiful. Also on the title bar of home screen it is written "Home", it'd be better if we change it to "HackClub RAIT"
Are you participating under any open-source program?
Yes, Hacktober Fest.

@HardikSJain Assigning this issue to you. Happy coding!


Add Incubed as network provider option

Hi Brave Team,
Slock.it just released the first stable version of its blockchain client, IN3. Incubed, unlike Infura connects to the Ethereum Blockchain via an INcentivized Node Network which incentivises and distributes the trust on remote nodes while still keeping the bandwidth and storage requirements low. According to our understanding Brave's CryptoWallet uses Infura as a network provider. While, Infura has its advantages it demands a high amount of trust. We at Slock.it want to change this by providing IN3 as an option into Brave's CryptoWallet through this pull request.
To know how it works, try it, or even run a node, check our documentation.
Functionality

Users of CryptoWallet would just have turn the Use In3 switch on under the Advanced tab of Settings (Settings -> Advanced -> Use In3).
CryptoWallet will automatically change the provider to the network the user is currently using.
In case the network is local, custom or one not supported by incubed, the user will still be connected to it until a supported network is selected on the menu.

Changes

New dependency for IN3's rpc middleware. eth-json-rpc-in3
New module Incubed network adapter
Added 'enable Incubed network' toggle button under Settings -> Advanced
Added a provider display in the network menu
Hid unavailable networks on the network menu when incubed is enabled.
Added tests for ui and modules.

Questions

This repository's CONTRIBUTING.md files says that all PR's must be submitted against the develop branch. Since you do not have a develop branch we have created a the PR against the master branch. Did we get that right?
The repository's CHANGELOG says Current Develop Branch. Shouldn't that be Current Master Branch? Let us know so that we can append the important changes to the CHANGELOG
Are there any suggestions from your side?

Incubed is a game changer! It is basically Casper for RPC, with portable code that runs on microcontrollers and a backend that can be attached to any running client. This is proper BUIDLR mindset, remove centralisation from every corner.

Hi @chirag-parmar - thanks for submitting this and all of the hard work you've put in to it. It's certainly a neat idea, but a couple of things:
ethereum-remote-client exists as an up-to-date fork of MetaMask/metamask-extension as such, you noticed we don't modify any core files, such as in the app/ or ui/ directory. Rather, we contain everything within in brave/ and having a patching system which ensures MetaMask base files are neatly overridden. This is to avoid painful upstream rebases.
I would like to suggest that you take this code, and open it up as a feature request in MetaMask/metamask-extension - then if it is merged in, Brave Crypto Wallets will be able to pull it in the next upstream rebase. This is our work flow for contributing large customizations to ethereum-remote-client, I patch upstream semi-frequently. Let me know if you have any questions. Thanks! :)

Also, per the above, CONTRIBUTING.MD refers to MetaMask’s contributor guidelines.

Hi @ryanml, apologies for the late reply. Metamask had declined our pull request before we submitted this one. Metamask's team fails to understand the value proposition of the IN3 client. I do not know of any other client that solves the trust problems of a remote client and bandwidth problems of a light client at the same time.
At slock.it we are trying to push the community to use better alternatives to remote clients. This is because we understand the risks that come with it, especially for a wallet application. Is there absolutely no other way we can integrate the IN3 client into brave? Maybe some script wizardry. This is just one of the ideas. If we can collaborate on this I am sure we can come up with a smart solution to this problem.
That being said if you still insist that a pull request in metamask-extension is the only way we can integrate this into brave then I'll go ahead and close this pull request.

hey @chirag-parmar, just closing the loop here -- we appreciate the pull request, but we've decided not to move forward without Incubed as a network provider option in Crypto Wallets.
we are focusing all of our resources on improving Crypto Wallets as a native UX in Brave, and bringing this PR inline with our new direction isn't in the cards in the near-term.
I'm closing this PR, since we don't intend to merge it, and it looks like there hasn't been a response to this PR since May in any case


Compatibility with software on RHEL 7.9

Hi,
We're attempting to install the interface, tried both the release 1.3.0-rc.1 and building from source. We've different issues with each.
The build from source fails as C++17 is needed but not present. Is anyone aware of a way to satisfy this requirement on RHEL 7.9?
FYI The install from release runs ok but loading arrowkdb.q fails as libarrow.so.900 can't be found, which is fair enough.
Versions:
RHEL 7.9
CMake 3.26.0
apache-arrow-release.noarch 0:10.0.1-1.el7
gcc-c++-4.8.5-44.el7.x86_64

We have arrow 10 instead of 9 as there were a lot of dependencies required for 9.
Install from release:
[user@server arrowkdb ]# ./install.sh
Detected System
* OS: linux-gnu
* TYPE: x86_64
* MACHINE TYPE: x86_64-redhat-linux-gnu
Copying q script to /home/user/kdb/ ...
Copying shared lib to /home/user/kdb/l64/ ...
Install complete
[user@server arrowkdb ]# q arrowkdb.q
KDB+ 3.5 2017.10.11 Copyright (C) 1993-2017 Kx Systems
l64/ 1(4)core 128774MB user server NONEXPIRE #XXXXX

'libarrow.so.900: cannot open shared object file: No such file or directory
  [2]  /home/user/kdb/arrowkdb.q:5: dt.na:`arrowkdb 2:(`null;1);
                                                         ^
  [0]  (<load>)

  )

Build from source:
[user@server build ]# cmake ..
-- The CXX compiler identification is GNU 4.8.5
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Generator : Unix Makefiles
-- Build Tool : /usr/bin/gmake
-- C API :
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
CMake Warning at /usr/lib64/cmake/Arrow/FindSnappyAlt.cmake:29 (find_package):
  By not providing "FindSnappy.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Snappy", but
  CMake did not find one.

  Could not find a package configuration file provided by "Snappy" with any
  of the following names:

    SnappyConfig.cmake
    snappy-config.cmake

  Add the installation prefix of "Snappy" to CMAKE_PREFIX_PATH or set
  "Snappy_DIR" to a directory containing one of the above files.  If "Snappy"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /usr/local/share/cmake-3.26/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
  /usr/lib64/cmake/Arrow/ArrowConfig.cmake:115 (find_dependency)
  CMakeLists.txt:28 (find_package)

-- Found SnappyAlt: /usr/lib64/libsnappy.so
-- Checking for modules 'libbrotlicommon;libbrotlienc;libbrotlidec'
--   Found libbrotlicommon, version 1.0.9
--   Found libbrotlienc, version 1.0.9
--   Found libbrotlidec, version 1.0.9
-- Found Brotli: /usr/lib64/libbrotlicommon.so
-- Found OpenSSL: /usr/lib64/libcrypto.so (found version "1.0.2k")
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.7")
CMake Warning at /usr/lib64/cmake/Arrow/Findlz4Alt.cmake:29 (find_package):
  By not providing "Findlz4.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "lz4", but
  CMake did not find one.

  Could not find a package configuration file provided by "lz4" with any of
  the following names:

    lz4Config.cmake
    lz4-config.cmake

  Add the installation prefix of "lz4" to CMAKE_PREFIX_PATH or set "lz4_DIR"
  to a directory containing one of the above files.  If "lz4" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  /usr/local/share/cmake-3.26/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
  /usr/lib64/cmake/Arrow/ArrowConfig.cmake:115 (find_dependency)
  CMakeLists.txt:28 (find_package)

-- Checking for module 'liblz4'
--   Found liblz4, version 1.8.3
-- Found lz4Alt: /usr/lib64/liblz4.so
CMake Warning at /usr/lib64/cmake/Arrow/FindzstdAlt.cmake:29 (find_package):
  By not providing "Findzstd.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "zstd", but
  CMake did not find one.

  Could not find a package configuration file provided by "zstd" with any of
  the following names:

    zstdConfig.cmake
    zstd-config.cmake

  Add the installation prefix of "zstd" to CMAKE_PREFIX_PATH or set
  "zstd_DIR" to a directory containing one of the above files.  If "zstd"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /usr/local/share/cmake-3.26/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
  /usr/lib64/cmake/Arrow/ArrowConfig.cmake:115 (find_dependency)
  CMakeLists.txt:28 (find_package)

-- Checking for module 'libzstd'
--   Found libzstd, version 1.5.5
-- Found zstdAlt: /usr/lib64/libzstd.so
-- Zstandard library: /usr/lib64/libzstd.so
-- Zstandard include directory: /usr/include
-- Found BZip2: /usr/lib64/libbz2.so (found version "1.0.6")
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
-- Arrow version: 10.0.1
-- Found the Arrow shared library: /usr/lib64/libarrow.so.1000.1.0
-- Found the Arrow import library: ARROW_IMPORT_LIB-NOTFOUND
-- Found the Arrow static library: /usr/lib64/libarrow.a
-- Configuring done (3.8s)
CMake Error in CMakeLists.txt:
  Target "arrowkdb" requires the language dialect "CXX17" .  But the current
  compiler "GNU" does not support this, or CMake does not know the flags to
  enable it.

-- Generating done (0.0s)
CMake Generate step failed.  Build files cannot be regenerated correctly.

You need to install libarrow 9.0 or earlier
https://github.com/KxSystems/arrowkdb#linux
libarrow 10.0 is built with c++17 which forces arrowkdb to also use c++17
If you have libarrow 9.0 or earlier then arrowkdb will build with c++14
(atlhough the prebuilt package will only work with libarrow 9.0 - if you install an earlier version you'll have to build arrowkdb from source)
If you must use libarrow 10 then you need to install a later gcc toolchain in RHEL 7 which supports C++17 and build arrowkdb from source

Hi @nmcdonnell-kx, that makes sense. Up to now we hadn't installed libarrow 9.0 is it had a lot of dependencies (see below). We will see again if we can install it. In any case we now have an EC2 which we will use it in instead
Resolving Dependencies
--> Running transaction check
---> Package libarrow.x86_64 0:9.0.0-8.el9 will be installed
--> Processing Dependency: libc.so.6(GLIBC_2.32)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
...
--> Processing Dependency: libc.so.6(GLIBC_2.33)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libc.so.6(GLIBC_2.34)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libgcc_s.so.1(GCC_7.0.0)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libm.so.6(GLIBC_2.27)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libm.so.6(GLIBC_2.29)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.22)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.26)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.29)(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Processing Dependency: libre2.so.9()(64bit) for package: libarrow-9.0.0-8.el9.x86_64
--> Finished Dependency Resolution
Error: Package: libarrow-9.0.0-8.el9.x86_64 (/libarrow-9.0.0-8.el9.x86_64)
           Requires: libre2.so.9()(64bit)
Error: Package: libarrow-9.0.0-8.el9.x86_64 (/libarrow-9.0.0-8.el9.x86_64)
           Requires: libc.so.6(GLIBC_2.34)(64bit)
Error: Package: libarrow-9.0.0-8.el9.x86_64 (/libarrow-9.0.0-8.el9.x86_64)
           Requires: libc.so.6(GLIBC_2.33)(64bit)
Error: Package: libarrow-9.0.0-8.el9.x86_64 (/libarrow-9.0.0-8.el9.x86_64)
           Requires: libgcc_s.so.1(GCC_7.0.0)(64bit)
Error: Package: libarrow-9.0.0-8.el9.x86_64 (/libarrow-9.0.0-8.el9.x86_64)
           Requires: libm.so.6(GLIBC_2.29)(64bit)
Error: Package: libarrow-9.0.0-8.el9.x86_64 (/libarrow-9.0.0-8.el9.x86_64)
           Requires: libm.so.6(GLIBC_2.27)(64bit)

Yeah, we deliberately targetted libarrow 9.0 because it was the last libarrow version which didn't require c++17 and therefore runs on older linux distros such as RHEL 7.
That being said, if you build arrowkdb from source (such that the libarrow.so.x versions match) you should be able to use an earlier libarrow version (I think anything after libarrow 3.0 would work - but I've not tested this)
I'd suggest trying libarrow 5.0 to see if there are less dependency problems.

@nmcdonnell-kx would you be able to delete this issue? It contains some details about hostnames etc that should not be on the public internet


🌃 Command for checking an individual player

Command for checking individual player stats, can be moderated with reactions.

-- Info
ID
Name
IP
Admin
VIP
RP
Lastlogged in
Registrered
VIP daedline

-- Stats
Gender
Skin
zCoins
Fishes
Blood
Thirst
Hunger
emprature
Humanity
Headshots
Deaths
Humans Killed
Bandits killed
Heroes killed
Zombies killed
Alivetime
Score
airdrop takes
position
is infected
is bleeding
is leg broken

-- Achievments
achivement list

-- Inventory
Backpack
Suicepack
Items (name / amount)

-- equipments
Head
Face
Torso
Hand
Tool (Toolammo)

-- holster
weapon / ammo

-- World
storage tents
structures

This will be more optimized when the offline bot is implemented.


Enhance the draft info output

Is your feature request related to a problem? Please describe.
It would be really nice if the info command could provide enough information to build an experience like that of the Azure Portal:

In the above, selection of a language version allows consumers to infer both runtime and builder images, as well as a default port.
Mention what platform you want to support the new feature
All
Describe the solution you'd like
Currently, Draft outputs this (to take Java as an example):
    {
      "name": "java",
      "displayName": "Java",
      "variableExampleValues": {
        "BUILDERVERSION": [
          "3-jdk-11"
        ],
        "VERSION": [
          "8-jre",
          "11-jre",
          "17-jre",
          "19-jre"
        ]
      }

But an Azure Portal-like experience would require something like this:
{
    "name": "java",
    "displayName": "Java",
    "defaultPort": 8080,
    "versions": [
        {
            "name": "Java 8",
            "imageVersion": "8-jre",
            "builderVersion": "3-eclipse-temurin-8"
        },
        {
            "name": "Java 11",
            "imageVersion": "11-jre",
            "builderVersion": "3-eclipse-temurin-11"
        },
        {
            "name": "Java 17",
            "imageVersion": "17-jre",
            "builderVersion": "3-eclipse-temurin-17"
        },
        {
            "name": "Java 19",
            "imageVersion": "19-jre",
            "builderVersion": "3-eclipse-temurin-19"
        },
    ]
}

I.e. in addition to the current output, it would also allow consumers to extract:

A display name for each of the versions
An image version for each of the versions
A builder version for each of the versions (if required in the Dockerfile)
A default port for the language
A more comprehensive selection of versions (e.g. for go, the info command outputs 1.16..1.19, yet the Portal displays 1.15..1.20)

Describe alternatives you've considered
As a consumer of Draft, I can maintain my own JSON mapping of languages to versions and ports, just as the Portal has to.
Additional context
I understand that maintaining a list of available versions (and associated images for each) is a maintenance overhead, but if Draft doesn't do that then consuming tools all have to, meaning it's hard to keep them in sync.

I'm trying to piece together the original intent of the variableExampleValues property from #164 and #165, and I think a key comment is this, that "users are free to use languages beyond just what the CLI would pre-populate" (I assume that refers to language versions and build/runtime images).
That might suggest that what I'm asking for here is both infeasible, and actually too restrictive for users. I'm guessing the thinking behind the original feature is that it supports a UI for consuming tools in which users are presented with free-text fields for language/image versions, but with some examples/presets to aid them. Am I interpreting that correctly?

If the ask for a reasonably comprehensive list of details for each language version is not feasible or sensible, an alternative thing that would be really useful would be builderImage and runtimeImage for each language. So, taking Java as an example:
{
    "name": "java",
    "displayName": "Java",
    "defaultPort": 8080,
    "builderImage": "maven",
    "runtimeImage": "eclipse-temurin",
}

That way, consuming applications can present some kind of UX that informs users what image they need to enter a tag/version for (e.g. maven), or potentially retrieve tags dynamically to allow user selection.

Thanks @peterbom, I have ack'd this request.

thank you for including such a thorough description of the request, and i can see how including a display title while grouping the builder version would make it easier to best keep the options synchronized
i wonder where it would be best to store the display name within the draft.yaml as it looks like this:
language: java
displayName: Java
nameOverrides:
  - path: "dockerignore"
    prefix: "."
variables:
  - name: "PORT"
    description: "the port exposed in the application"
    type: int
  - name: "BUILDERVERSION"
    description: "the version of maven used during the builder stage to generate the executable"
    exampleValues: ["3-eclipse-temurin-11", "3-eclipse-temurin-17", "3-eclipse-temurin-21", "3 (jdk-21)"]
  - name: "VERSION"
    description: "the java version used by the application"
    exampleValues: ["11-jre","17-jre","19-jre","21-jre"]
variableDefaults:
  - name: "BUILDERVERSION"
    value: "3"
  - name: "VERSION"
    value: "21-jre"
  - name: "PORT"
    value: "80"

potentially adding an "exampleLabels" field or making exampleValues take a list of objects with value and label fields could solve this?

the "exampleLabels" approach would maintain backward compatibility, but make potentially jagged array configurations that would have to be validated externally, instead the "example object" approach would group it more naturally, but then you can have a label on both the VERSION and BUILDERVERSION either way

something like
type Example struct {
         Value string
         Label string
}
type BuilderVar struct {
	Name             string   `yaml:"name"`
	Description      string   `yaml:"description"`
	VarType          string   `yaml:"type"`
	ExampleValues    []Example `yaml:"exampleValues"`
	IsPromptDisabled bool     `yaml:"disablePrompt"`
}

since the BUILDERVERSION and VERSION are not intrinsically linked in the current config