Phase 0 Wire Protocol

Follow-on to #593.
This specification describes Ethereum 2.0's networking wire protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL", NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Use of libp2p
This protocol uses the libp2p networking stack. libp2p provides a composable wrapper around common networking primitives, including:

Transport.
Encryption.
Stream multiplexing.

Clients MUST be compliant with the corresponding libp2p specification whenever libp2p specific protocols are mentioned. This document will link to those specifications when applicable.
Client Identity
Identification
Upon first startup, clients MUST generate an RSA key pair in order to identify the client on the network. The SHA-256 multihash of the public key is the clients's Peer ID, which is used to look up the client in libp2p's peer book and allows a client's identity to remain constant across network changes.
Addressing
Clients on the Ethereum 2.0 network are identified bymultiaddrs. multiaddrs are self-describing network addresses that include the client's location on the network, the transport protocols it supports, and its peer ID. For example, the human-readable multiaddr for a client located at example.com, available via TCP on port 8080, and with peer ID QmUWmZnpZb6xFryNDeNU7KcJ1Af5oHy7fB9npU67sseEjR would look like this:
/dns4/example.com/tcp/8080/p2p/QmUWmZnpZb6xFryNDeNU7KcJ1Af5oHy7fB9npU67sseEjR

We refer to the /dns4/example.com part as the 'lookup protocol', the /tcp/8080 part as the networking protocol, and the /p2p/<peer ID> part as the 'identity protocol.'
Clients MAY use either dns4 or ip4 lookup protocols. Clients MUST set the identity protocol to /tcp followed by a port of their choosing. It is RECOMMENDED to use the default port of 9000. Clients MUST set the identity protocol to /p2p/ followed by their peer ID.
Relevant libp2p Specifications

multiaddr
multihash
peer-id

Transport
Clients communicate with one another over a TCP stream. Through that TCP stream, clients receive messages either as a result of a 1-1 RPC request/response between peers or via pubsub broadcasts.
Weak-Subjectivity Period
Some of the message types below depend on a calculated value called the 'weak subjectivity period' to be processed correctly. The weak subjectivity period is a function of the size of the validator set at the last finalized epoch. The goal of the weak-subjectivity period is to define the maximum number of validator set changes a client can tolerate before requiring out-of-band information to resync.
The definition of this function will be added to the 0-beacon-chain specification in the coming days.
Messaging
All ETH 2.0 messages conform to the following structure:
+--------------------------+
|       protocol path      |
+--------------------------+
|      compression ID      |
+--------------------------+
|                          |
|    compressed body       |
|    (SSZ encoded)         |
|                          |
+--------------------------+

The protocol path is a human-readable prefix that identifies the message's contents. It is compliant with the libp2p multistream specification. For example, the protocol path for libp2p's internal ping message is /p2p/ping/1.0.0. All protocol paths include a version for future upgradeability. In practice, client implementors will not have to manually prepend the protocol path since libp2p implements this as part of the libp2p library.
The compression ID is a single-byte sigil that denotes which compression algorithm is used to compress the message body. Currently, the following compression algorithms are supported:

ID 0x00: no compression
ID 0x01: Snappy compression

We suggest starting with Snappy because of its high throughput (~250MB/s without needing assembler), permissive license, and availability in a variety of different languages.
Finally, the compressed body is the SSZ-encoded message body after being compressed by the algorithm denoted by the compression ID.
Relevant Specifications

multistream
SSZ

Messages
The schema of message bodies is notated like this:
(
    field_name_1: type
    field_name_2: type
)

SSZ serialization is field-order dependent. Therefore, fields MUST be  encoded and decoded according to the order described in this document. The encoded values of each field are concatenated to form the final encoded message body. Embedded structs are serialized as Containers unless otherwise noted.
All ETH 2.0 RPC messages prefix their protocol path with /eth/serenity.
Handshake
Hello
Protocol Path: /eth/serenity/hello/1.0.0
Body:
(
    network_id: uint8
    latest_finalized_root: bytes32
    latest_finalized_epoch: uint64
    best_root: bytes32
    best_slot: uint64
)

Clients exchange hello messages upon connection, forming a two-phase handshake. The first message the initiating client sends MUST be the hello message. In response, the receiving client MUST respond with its own hello message.
Clients SHOULD immediately disconnect from one another following the handshake above under the following conditions:

If network_id belongs to a different chain, since the client definitionally cannot sync with this client.
If the time between each peer's latest_finalized_epoch exceeds the weak-subjectivity period, since syncing with this client would be unsafe.
If the latest_finalized_root shared by the peer is not in the client's chain at the expected epoch. For example, if Peer 1 in the diagram below has (root, epoch) of (A, 5) and Peer 2 has (B, 3), Peer 1 would disconnect because it knows that B is not the root in their chain at epoch 3:

              Root A

              +---+
              |xxx|  +----+ Epoch 5
              +-+-+
                ^
                |
              +-+-+
              |   |  +----+ Epoch 4
              +-+-+
Root B          ^
                |
+---+         +-+-+
|xxx+<---+--->+   |  +----+ Epoch 3
+---+    |    +---+
         |
       +-+-+
       |   |  +-----------+ Epoch 2
       +-+-+
         ^
         |
       +-+-+
       |   |  +-----------+ Epoch 1
       +---+

Once the handshake completes, the client with the higher latest_finalized_epoch or best_slot (if the clients have equal latest_finalized_epochs) SHOULD send beacon block roots to its counterparty via beacon_block_roots.
RPC
These protocols represent RPC-like request/response interactions between two clients. Clients send serialized request objects to streams at the protocol paths described below, and wait for a response. If no response is received within a reasonable amount of time, clients MAY disconnect.
Beacon Block Roots
Protocol Path: /eth/serenity/rpc/beacon_block_roots/1.0.0
Body:
# BlockRootSlot
(
    block_root: HashTreeRoot
    slot: uint64
)

(
    roots: []BlockRootSlot
)

Send a list of block roots and slots to the peer.
Beacon Block Headers
Protocol Path: /eth/serenity/rpc/beacon_block_headers/1.0.0
Request Body
(
    start_root: HashTreeRoot
    start_slot: uint64
    max_headers: uint64
    skip_slots: uint64
)

Response Body:
# Eth1Data
(
    deposit_root: bytes32
    block_hash: bytes32
)

# BlockHeader
(
    slot: uint64
    parent_root: bytes32
    state_root: bytes32
    randao_reveal: bytes96
    eth1_data: Eth1Data
    body_root: HashTreeRoot
    signature: bytes96
)

(
    headers: []BlockHeader
)

Requests beacon block headers from the peer starting from (start_root, start_slot). The response MUST contain fewer than max_headers headers. skip_slots defines the maximum number of slots to skip between blocks. For example, requesting blocks starting at slots 2 a skip_slots value of 2 would return the blocks at [2, 4, 6, 8, 10]. In cases where a slot is undefined for a given slot number, the closest previous block MUST be returned returned. For example, if slot 4 were undefined in the previous example, the returned array would contain [2, 3, 6, 8, 10]. If slot three were further undefined, the array would contain [2, 6, 8, 10] - i.e., duplicate blocks MUST be collapsed.
The function of the skip_slots parameter helps facilitate light client sync - for example, in #459 - and allows clients to balance the peers from whom they request headers. Client could, for instance, request every 10th block from a set of peers where each per has a different starting block in order to populate block data.
Beacon Block Bodies
Protocol Path: /eth/serenity/rpc/beacon_block_bodies/1.0.0
Request Body:
(
    block_roots: []HashTreeRoot
)

Requests the block_bodies associated with the provided block_roots from the peer. Responses MUST return block_roots in the order provided in the request. If the receiver does not have a particular block_root, it must return a zero-value block_body (i.e., a zero-filled bytes32).
Response Body:
For type definitions of the below objects, see the 0-beacon-chain specification.
# BlockRoot
(
    proposer_slashings: []ProposerSlashing
    attester_slashings: []AttesterSlashing
    attestations: []Attestation
    deposits: []Deposit
    voluntary_exits: []VoluntaryExit
    transfers: []Transfer
)

(
    block_roots: BlockRoot[]
)

Beacon Chain State
Note: This section is preliminary, pending the definition of the data structures to be transferred over the wire during fast sync operations.
Protocol Path: /eth/serenity/rpc/beacon_chain_state/1.0.0
Request Body:
(
    hashes: []HashTreeRoot
)

Requests contain the hashes of Merkle tree nodes that when merkelized yield the block's state_root.
Response Body: TBD
The response will contain the values that, when hashed, yield the hashes inside the request body.
Broadcast
These protocols represent 'topics' that clients can subscribe to via GossipSub.
Beacon Blocks
The response bodies of each topic below map to the response bodies of the Beacon RPC methods above. Note that since broadcasts have no concept of a request, any limitations to the RPC response bodies do not apply to broadcast messages.
Topics:

beacon/block_roots
beacon/block_headers
beacon/block_bodies

Voluntary Exits
Topic: beacon/exits
Body:
See the 0-beacon-chain spec for the definition of the VoluntaryExit type.
(
    exit: VoluntaryExit
)

Transfers
Topic: beacon/transfer
Body:
See the 0-beacon-chain spec for the definition of the Transfer type.
(
    transfer: Transfer
)

Clients MUST ignore transfer messages if transfer.slot < current_slot - GRACE_PERIOD, where GRACE_PERIOD is an integer that represents the number of slots that a remote peer is allowed to drift from current_slot in order to take potential network time differences into account.
Shard Attestations
Topics: shard-{number}, where number is an integer in [0, SHARD_SUBNET_COUNT), and beacon/attestations.
The Attestation object below includes fully serialized AttestationData in its data field. See the 0-beacon-chain for the definition of the Attestation type.
Body:
(
    attestations: []Attestation
)

Only aggregate attestations are broadcast to the beacon/attestations topic.
Clients SHOULD NOT send attestations for shards that the recipient is not interested in. Clients receiving uninteresting attestations MAY disconnect from senders.
Relevant Specifications

gossipsub

Client Synchronization
When a client joins the network, or has otherwise fallen behind the latest_finalized_root or latest_finalized_epoch, the client MUST perform a sync in order to catch up with the head of the chain. This specification defines two sync methods:

Standard: Used when clients already have state at latest_finalized_root or latest_finalized_epoch. In a standard sync, clients process per-block state transitions until they reach the head of the chain.
Fast: Used when clients do not have state at latest_finalized_root or latest_finalized_epoch. In a fast sync, clients use RPC methods to download nodes in the state tree for a given state_root via the /eth/serenity/rpc/beacon_chain_state/1.0.0 endpoint. The basic algorithm is as follows:

Peer 1 and Peer 2 connect. Peer 1 has (C, 1) and Peer 2 has (A, 5). Peer 1 validates that this new head is within the weak subjectivity period.
If the head is within the weak subjectivity period, Peer 2 checks the validity of the new chain by verifying that all children point to valid parent roots.
Peer 2 then takes the state root of (A, 5) and sends /eth/serenity/rpc/beacon_chain_state/1.0.0 requests recursively to its peers in order to build its SSZ BeaconState.

Note that nodes MUST perform a fast sync if they do not have state at their starting finalized root. For example, if Peer 1 in the example above did not have the state at (C, 1), Peer 1 would have to perform a fast sync because it would have no base state to compute transitions from.
Open Questions
Encryption
This specification does not currently define an encrypted transport mechanism because the set of libp2p-native encryption libraries is limited. libp2p currently supports an encryption scheme called SecIO, which is a variant of TLSv1.3 that uses a peer's public key for authentication rather than a certificate authority. While SecIO is available for public use, it has not been audited and is going to be deprecated when TLSv1.3 ships.
Another potential solution would be to support an encryption scheme such as Noise. The Lightning Network team has successfully deployed Noise in production to secure inter-node communications.
Granularity of Topics
This specification defines granular GossipSub topics - i.e., beacon/block_headers vs. simply beacon. The goal of using granular topics is to simplify client development by defining a single payload type for each topic. For example, beacon/block_headers will only ever contain block headers, so clients know the content type of without needing to read the message body itself. This may have drawbacks. For example, having too many topics may hinder peer discovery speed. If this is the case, this specification will be updated to use less granular topics.
Block Structure Changes
The structure of blocks may change due to #649. Changes that affect this specification will be incorporated here once the PR is merged.

Great writeup!
A few notes:
There has been discussions on whether to use RLP for discovery and SSZ for messages.
There has also been some discussion on using QUIC instead of UDP for discovery and TCP for all peer communication. By using QUIC, we no longer need a 3-way handshake as in TCP and we get built-in encryption. The main issue is that it hasn't been implemented in all programming languages.

If the time between each peer's latest_finalized_epoch exceeds the weak-subjectivity period, since syncing with this client would be unsafe.

What do we mean by this? Note that especially in cases where the validator set is very small, it is absolutely possible for the latest finalized block to be more than a weak subjectivity period behind the current block.

3\. If the `latest_finalized_root` shared by the peer is not in the client's chain at the expected epoch. For example, if Peer 1 in the diagram below has `(root, epoch)` of `(A, 5)` and Peer 2 has `(B, 3)`, Peer 1 would disconnect because it knows that `B` is not the root in their chain at epoch 3:

This feels backward. It's not the peer's latest finalized root that should be checked against the client head, it's the peer's head that should be checked against the client's latest finalized root. As an example of how the current approach is insufficient, consider the case where the client head is H with a latest finalized root R with parent P, and a peer says hello with a chain going through some different child R' of P that doesn't finalize any blocks. The peer's latest finalized root would be some ancestor of P; so this is clearly invalid from the point of view of the client, but it would still be accepted.

Only aggregate attestations are broadcast to the beacon/attestations topic.

Is there a need for this particular wire protocol spec to specify where unaggregated attestations get sent?

There has been discussions on whether to use RLP for discovery and SSZ for messages.

As the inventor of RLP, I'm inclined to prefer SSZ (or SOS if we end up replacing SSZ with SOS or something similar) :laughing:
The "simplicity over efficiency" desideratum would imply that we should ideally only use one algorithm per task (in this case the task being "serialization"), even if they have slightly different tradeoffs. I see the overhead of a few extra zero bytes in SSZ being tiny relative to the absolute size of the objects that would be transferred, so the gains wouldn't be large.

What do we mean by this? Note that especially in cases where the validator set is very small, it is absolutely possible for the latest finalized block to be more than a weak subjectivity period behind the current block.

The point here is to make clear that you may think you are safe to sync but realize on the wire that you don't have recent enough information to safely sync. I suppose this information can (and maybe should) be known before you even contact peers.  In this case, maybe this is not a wire protocol note, but a client implementer safety note that goes in another doc.

This feels backward

The peer with the lower finalized epoch (peer-1) cannot immediately tell just by shaking hands with the peer with the higher finalized epoch (peer-2) if the peer-1's finalized epoch is in peer-2's chain or not. Peer-2 on the other hand can easily check if peer-1's finalized epoch is in their chain. If not, no use in sending blocks to them because to sync peer-2's blocks, peer-1 would have to revert.
I'm not sure if what we currently have in (3) is backward, but it is does not sufficiently cover all the cases in which two chains might be out of sync wrt finality

Is there a need for this particular wire protocol spec to specify where unaggregated attestations get sent?

Not 100% sure. The expectation is that single signer attestations are sent to the shard subnet. Only rarely would a single signer attestation be broadcast to the beacon net as a "best effort" aggregation.

The "simplicity over efficiency" desideratum would imply that we should ideally only use one algorithm per task

+1

Not 100% sure. The expectation is that single signer attestations are sent to the shard subnet. Only rarely would a single signer attestation be broadcast to the beacon net as a "best effort" aggregation.

Agree! So do we need a "shard subnet wire protocol" section?

Re-raising this issue, but is there any particular reason why beacon_block_roots is built in as a part of hello instead of being exposed as its own RPC request? It improves the modularity of hello and passes the onus of getting up to date to the peer that is behind. Under the above proposal, if a peer is behind and conducts several hello exchanges with its peers (perhaps due to being offline temporarily) would receive beacon block roots several times. This obviously represents sevral redundant messages. Furthermore, in the above protocol, the only means of obtaining beacon block roots is via new hello exchanges.

Nice writeup! This is quite a big document, so maybe opening a PR would allow for easier review (not sure what the best place for this would be though). I'll try giving some feedback anyway:

SSZ/SOS vs RLP debate

I'm leaning towards RLP for message encoding. Not because of efficiency, but because with SSZ we at all times need to know the exact message type that we're expecting. RLP is more flexible in that regard which would make it easier to support versioning, multiple possible response message types, and using the same gossip topic for multiple object types. Also, if we go with RLP at the discovery level anyway, then using it at the "content" level would be more consistent (but this is a different debate I guess).

Message format

I think whenever we send objects that are defined in the spec, we should put them in the message either as a (list of) SSZ blob(s) (if we go with non-SSZ as message format) or as a container field (for SSZ messages). Right now, it seems like we're redefining some object types (e.g. block header and block body).

Handshake

network id: It seems like we don't actually use this to distinguish between networks, but rather between chains. Replacing it with something like "hard fork choices" would make this more explicit: It would contain slot or epoch and block hash pairs for relevant blocks (genesis and all hard forks, or at least the latest one)

Shall we add the latest justified head as well? If I'm not making a mistake, the last finalized epoch will be 1.5 epochs or ~10 minutes old on average, even in optimal conditions, and adding the justified epoch should be quite cheap.

Shall we rename best to head to follow the terminology of the spec and be more neutral?

Disconnect

Maybe we should have an explicit "Disconnect" message. This would enable peers to do some clean ups and also stop responding to any potential outstanding requests.

Request/Responses

We should add a request_id to each request/response message. This way handling replies gets much easier and also allows for parallel requests.

Beacon Block Roots

I think the corresponding request is missing, no? We can probably just use the same format as we do for requesting beacon block headers.

Beacon Block Headers

The request contains both slot and root. Why? The slot seems to be redundant so I think removing it is better for simplicity.

Scope

I think we should try to keep this as simple as possible for now and don't specify any fast or light sync etc.

Protocol paths

I think we should add beacon/shard to the protocol path, i.e.
/eth/serenity/rpc/beacon_block_roots/1.0.0 --> /eth/serenity/beacon/rpc/beacon_block_roots/1.0.0

Agree! So do we need a "shard subnet wire protocol" section?

The "Shard Attestations" section includes both shard and beacon topics as valid topics to broadcast on. It just makes the note that only aggregated are expected to be passed to the beacon topic. Is this what you mean? We can pull these things out so they are more clearly distinct.

Re-raising this point, but is there any particular reason why beacon_block_roots is built in as a part of hello instead of being exposed as its own RPC request?

This is similar to how block hashes are exchanged on the ethereum 1.0 wire protocol. The expectation is that you are only gathering information to "catch up" when initially finding peers and that beyond that you generally stay synced by listening to broadcasts on the wire. If you get a recent block and don't have it's parent, you can ask for it's parent via the root embedded in the block and walk the chain back until you find a common ancestor. If fallen way out of sync, you can reconnect to peers to get a list of roots.
I see the potential utility of what you describe but am not sure needing to request the list after initial hello is generally necessary. I'd like to look into how geth handles this and will ask a couple of 1.0 sync masters about it today.

Also, if we are going to make topics plural, please can we make beacon/transfer plural too.

👍

Nice writeup! This is quite a big document, so maybe opening a PR would allow for easier review (not sure what the best place for this would be though). I'll try giving some feedback anyway:

Will open up a PR after these initial comments. Thanks!

Right now, it seems like we're redefining some object types (e.g. block header and block body).

The current format of BlockHeader here is just the BeaconBlock with the body served as a hash root. I hear you on making the formats just easily reference the SSZ objects for clarity. We have a couple of header/body changes coming in #649 (firm separation between header/body) and then will clean up accordingly.

network id: It seems like we don't actually use this to distinguish between networks, but rather between chains.

Interesting. In the 1.0 protocol we use it for both distinguishing between entirely different chains (mainnet vs ropsten vs ..) as well as forks within a single chain. and contentious forks become different networks. I see there could be some use in coming up with a succinct format to describe forks independent of base "network". Nick Johnson had an interesting proposal on twitter. Something like this might be worth pursuing.

If I'm not making a mistake, the last finalized epoch will be 1.5 epochs or ~10 minutes old on average, even in optimal conditions, and adding the justified epoch should be quite cheap.

The latest_finalized_epoch/root is to see if the two chains are irrevocably disjoint and to serve somewhat as a "check-pointing" mechanism. The lastest justified is not set in stone. What use case do you see here? Also note, that a newly syncing peer would probably just have a latest finalized epoch/root.

Shall we rename best to head to follow the terminology of the spec and be more neutral?

agreed

Maybe we should have an explicit "Disconnect" message. This would enable peers to do some clean ups and also stop responding to any potential outstanding requests.

Seems reasonable. Could also signal a "why" if you had a particular reason

I think we should try to keep this as simple as possible for now and don't specify any fast or light sync etc.

A method to sync state is necessary in the weakly subjective chain. Clients are expected to show up with some recent finalized root and peers are not expected to serve blocks since genesis in perpetuity.  The term is more aptly described here as "State Sync" rather than "fast" as it's primary use is to provide a recent state to a client. Also note that the state size is bound ~600MB even in the worst case and so should actually be fast.
gotta run. I'll get to your other few things in a bit, and will make some edits accordingly.

After a review (I will study/contemplate this later in more depth) of this lovely piece of work,  I just want to raise a couple of questions, which most likely arise out of my own lack of understanding:

If nodes are discovered using ENRs, the information on the node is already available. This means that clients will be identified by ENR, and if libp2p multiaddr is used or not is an implementation detail, not a protocol requirement, (right?)
Similarly, compression type could be omitted from the message as the default should be the 'highest' supported by the sending node supported by the recipient.
Encoding (SSZ) could similarly be optional/variable.
Protocol path could be compressed out as the info is in the ENR. A byte/nibble should be sufficient. Why compress the message body and make the protocol path human readable?
Eth-current uses Network ID and Chain ID.

On wire encoding is it fair to say that for participation in the existing network, RLP is necessary as a software component for the medium term future regardless?

The latest_finalized_epoch/root is to see if the two chains are irrevocably disjoint and to serve somewhat as a "check-pointing" mechanism. The lastest justified is not set in stone. What use case do you see here? Also note, that a newly syncing peer would probably just have a latest finalized epoch/root.

I assumed both finalized epoch and head are just used to select the best peer to connect to and sync from. The justified epoch would just be an additional piece of information to do this a little better. Maybe in practice the head is already enough though, so this might not be necessary.

Interesting. In the 1.0 protocol we use it for both distinguishing between entirely different chains (mainnet vs ropsten vs ..) as well as forks within a single chain. and contentious forks become different networks. I see there could be some use in coming up with a succinct format to describe forks independent of base "network". Nick Johnson had an interesting proposal on twitter. Something like this might be worth pursuing.

Yes, in Eth1.0 there's kind of a one to one relationship between networks and forks. But in Eth2.0, we have at least the beacon network and multiple (shard) subnetworks for the same (beacon) chain, and if we count the various topics as one network each we get even more. So I think we should differentiate the terms a bit more cleanly.

Similarly, compression type could be omitted from the message as the default should be the 'highest' supported by the sending node supported by the recipient.

I think/hope libp2p handles this for us already so nothing we should worry about.

Encoding (SSZ) could similarly be optional/variable.

I strongly think we should agree on some encoding scheme and require it. Otherwise different clients won't be able to talk to each other and the network will cluster by implementation.

Protocol path could be compressed out as the info is in the ENR. A byte/nibble should be sufficient. Why compress the message body and make the protocol path human readable?

I think that's also in libp2p's domain.
cc @raulk

Upon first startup, clients MUST generate an RSA key pair in order to identify the client on the network. The SHA-256 multihash of the public key is the clients's Peer ID...

This shouldn't be in this specification because it is handled by lower layers of the stack.

From what I understand, beacon_block_headers goes forwards in time, starting at a low slot number and building towards higher slot numbers.
What's often happens in distributed systems is that stuff gets lost along the way, for a variety of reasons. Thus, what would be useful is an ancestor request, such that when you receive a block or attestation whose parent is unknown, you can quickly recover and establish if this is a good block or not.
What you need:

a finalized block serving as anchor - here you can go back to genesis or whatever block you already know is finalized - tail is a useful name, if the other end is called head.
a request to get ancestor blocks - strictly, one at a time is sufficient, but it quickly becomes obvious that it's nice to get a range as well.

When you receive a block, you need to check that you have a path back to a tail block you know about - if you don't, it's either a block that's not part of the chain (spam?), or you're missing links. To find out, you have to try downloading the missing block headers, using slot time to establish a horizon to tell one situation from the other.
This kind of request is very flexible, because it allows you to join the network, start listening to broadcast chatter and discover what the most popular heads are (assuming broadcast network is namespaced / separate for every chain - it's fairly low cost to add a network id to every broadcast, which will greatly help debugging, if nothing else)
The approach is nice for a few different reasons:

cheap to implement - all data is already in the blocks, so there's no need for clients to build special indices to support basic functionality
same flow for sync and repair - whether you lost a block because connectivity was cut or are joining with a fresh state, the same request is used to fill in the gaps
the method is sufficient for a correctly functioning network - on top, you can add certain well-placed optimizations to speed things up (like the hello message to discover heads)
you can join the network and start listening to broadcasts - no special requests necessary for sync

What you do as a client is to divide blocks into two: resolved and unresolved. Resolved blocks are those that you have established a path to a finalized state (that you know through other means) to. Unresolved are all the others:

blocks from different chains, malicious blocks etc.. will never establish path
blocks where you're missing links - will establish path

The request would look something like:
(
    head_root: HashTreeRoot
    ancestor_slots: uint64
)

Basically, a start-pointer+length kind of request, but going backwards in time (this is already an optimization over getting blocks one at a time then getting their parents recursively, which also works - this is incidentally the same as the git dumb remote sync protocol).
This request can return block headers or roots as is appropriate (headers seems natural, because you want to use the response to verify that one of the blocks resolves to a known chain state)
One problem with the approach is that when you receive an unknown block, you have to use network resources to find out if it's valid or not (the block might be signed by a validator that's not in your validator set, because the latest finalized block you know about does not yet contain it ). This can be mitigated by:

using heuristics to score blocks and use resources accordingly (is it well-formed? is it signed by a known validator? does slot time make sense? etc)
make sure that answers are ordered from low slot number to high, so you can quickly discard bad information - potentially with pagination (ie you have to be prepared to handle a partial response)

The forward-direction request is slightly problematic in that it also needs to decide if it should branch out on all children or simply follow what the responding client considers to be the canonical chain at the time. Ancestor request does not have this issue.

skip_slots: uint64

what's the use case for skipping slots at uniform intervals?

fwiw we just landed a simple implementation of the application layer requests in this protocol in Nimbus: https://github.com/status-im/nim-beacon-chain/pull/117 (the PR description is a bit off, it refers to an earlier attempt that we subsequently rewrote), and will be playing around with it for the initial sync.
A detail is that we're running it over devp2p right now for convenience, but should be integrating with a libp2p transport soon:ish.
One thing of note is that when you're a proposer, you want to include attestations from as many shards as possible, right? Effectively, this means that that if attestation broadcasts are split up by shards, you end up having to listen to all of them anyway, under the naive attestation broadcast protocol where everyone just broadcasts their self-signed attestation.

Only aggregate attestations are broadcast to the beacon/attestations topic.

What's lacking for this is a responsible entity that does the aggregation and broadcasts it here - also, what's aggregate in this context? 2/3 votes? all? and who does the aggregation.. so many questions :) Pegasys' aggregation looks promising, but until we have that, in the implementation we're broadcasting everything everywhere - obviously, this will not do for 4 million validators!

Effectively, this means that that if attestation broadcasts are split up by shards, you end up having to listen to all of them anyway, under the naive attestation broadcast protocol where everyone just broadcasts their self-signed attestation.

The expectation is to have some subset of committee broadcast best-effort aggregates picked up from the shard subnet to the beacon (say last N of committee). These validators are already connected to the subnet for creating the attestation and are incentivized to have their attestations included in the beacon chain so are a natural pick. A proposer of a beacon chain block is not expected to sync to a bunch of different subnets to pick up and aggregate attestations. Adding this to honest validator guide shortly.

Pegasys' aggregation looks promising

Agreed. Glad to have it in our back pocket, but want to get some nodes on testnets before we decide to go with a more sophisticated setup. Note that even with a more structured aggregatation scheme, we need some sort of expected behavior defining what gets passed to the beacon net.

what's the use case for skipping slots at uniform intervals?

To distribute the load of requests across peers, and to also be able to provide a "skip" subset to light clients.
Still digesting the rest of your post.

These validators are already connected to the subnet for creating the attestation and are incentivized to have their attestations included in the beacon chain so are a natural pick.

but do they have an interest for others to be rewarded also? minimally no, right? since reward depends on total active validator balance, it's better for me if someone else loses balance? there's the social good argument of course that validators might remember who excluded them and reciprocate etc..

but do they have an interest for others to be rewarded also? minimally no, right? since reward depends on total active validator balance, it's better for me if someone else loses balance? there's the social good argument of course that validators might remember who excluded them and reciprocate etc..

validators lose money if they aren't successfully crosslinking or finalizing. The best thing I can do as an individual is maximize participation of my committee and validators as a whole. If I happen to have some huge majority of validation, my optimal strategy might change to censorship.

How would state sync work in the case of skipped slots ? Lets say a node A joins the network so has no saved state locally and will have to perform a fast sync.  Node B has the latest finalized root/epoch , A is at (RA,1) and B is at (RB,5).
What happens when the slots before finalization were skipped slots in epoch 5 ? Node A downloads the whole state from its peers and will have the same finalized state as Node B. However now Node A has to catch up to the current head of the network and starts requesting for blocks after the latest finalized epoch.
Lets say due to network issues slots are skipped before finalization, every block that Node A import's now will point to a parent that the node cannot validate as the parent is not saved and that block will end up being thrown away despite being a valid block. This would end up with sync permanently stalling as it would never be able to reach the current head

@nisdas Skipped slots don't matter, all A need is blocks and they can still get them even if some slots in between are empty. A would just ask for all blocks from their last known slot to the current slot and B would reply with all non-skipped ones. I guess this may become slightly more inefficient if A tries to request from multiple Bs (as they don't know which blocks have been skipped, so the load won't be distributed equally), but that seems not very significant.

I've included updates to this spec here: https://github.com/ethereum/eth2.0-specs/pull/763. Closing this in favor of the PR.

@jannikluhn The issue isnt requesting skipped slots. Its how we perform fast sync while requesting for the beacon state initially. This is what I was thinking of
 Block Proposed +-----------+ Slot 94 ( Current Head)
         ^
         |
         ^
         |
         ^
         |
 Block Proposed +-----------+ Slot 66
         ^
         |
   Slot Skipped +-----------+ Slot 65
         ^
         |
   Slot Skipped +-----------+ Slot 64 ( Epoch Transition & State is finalized)
         ^
         |
   Slot Skipped +-----------+ Slot 63
         ^
         |
   Slot Skipped +-----------+ Slot 62
         ^
         |
   Slot Skipped +-----------+ Slot 61
         ^
         |
    Block Proposed +-----------+ Slot 60

If a new node joins the network they will start sync by requesting the finalized state at slot 64( epoch 1). Then in order to sync till the current head at slot 94, it will request blocks from (65,94). So when the node receives the response containing the blocks in this range, it will process the block at slot 66 (since 65 was skipped). But when we process this block into state transition function, it will be rejected since we do not have the previous chain head which is actually the block at slot 60. We also will need to save the parent block(slot 60) in state sync in order for sync to work.

Ah, I think I get what you mean now. The state does contain the latest block header though, so this should deal with it, right?

Ahh , yes that would solve it. This is a bug on our end since we generate the previous block root from our locally saved block instead of using the one kept in state. Thanks !


Code cleanup and optimization for /init api call [Improve Latency]

Version where bug was found:
e.g "5.0.11"
Describe the bug
We observed a few possibilities of optimizations in /init api call. We need to remove extra network calls to reduce latency
Expected behavior
We should see an improvement in the latency.

Code Review: @VivekFitkariwala

QA on this: The response object from the /init call doesn't seem to be what code comments are assuming it is.
  // if reinit call is made with any of the below fields not included in the call,     // then we will fetch the stored values of the field and return them in the response     // for consistent init response with 3 fields ['userId', 'group', 'workingGroup']
Suggests (to me) that the response object will contain, for instance, the value from the "workingGroup" even when the request object only has "id" and "group". This is not the case. I looks like we're (incorrectly) depending on the save() method to return the entire row,  which it does not.


nixos/no-x-libs: fix infinite recursion with ffmpeg

Description of changes
Regression from #211834
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Not too familiar with no-x-libs but why does that result in an infinite recursion? ffmpeg_4-minimal is defined as ffmpeg_4.override { ffmpegVariant = "headless"; }.
If that fixes it, go for it but I really don't understand why it's necessary.

Not too familiar with no-x-libs but why does that result in an infinite recursion? ffmpeg_4-minimal is defined as ffmpeg_4.override { ffmpegVariant = "headless"; }.
If that fixes it, go for it but I really don't understand why it's necessary.

The overlay overrides ffmpeg_4 so ffmpeg_4-minimal is overriding the override here
This is why overrides in all-packages.nix should be avoided

Shouldn't the proper fix be to use final/self rather than prev/super then?
But I can see where you're coming from and sort of agree with the caveat that we still need to inherit Darwin frameworks and I don't like the idea of duplicating that code for every ffmpeg "invocation".

Would using final interfere with other overlays?

Not sure. How can I test that without evaluating a whole NixOS system?

Not sure. How can I test that without evaluating a whole NixOS system?

its just a normal overlay so it can be tested like normal

Shouldn't the proper fix be to use final/self rather than prev/super then?

that would be a double infinite recursion :P

See this discussion https://github.com/NixOS/nixpkgs/pull/204287#discussion_r1038935853

So, do I need to do anything here or can we merge this?


when-cli: init at 0.4.0

Description of changes
Add a when-cli, a CLI tool for converting between timezones.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Added mainProgram and fixed formatting.


LaTeX Error: Option clash for package inputenc

I am in the process of installing manimlib. Everything works except LaTex commands (such as TexMobject calls). Upon calling
python3 -m manim test1.py Shapes -pl
for the simple scene:
class Shapes(Scene): 	def construct(self): 		text = TextMobject("hello") 		self.play(Write(text))
I get the following error:
Exception: Latex error converting to dvi. See log output above or the log file:
The log file is as follows:
2b721902e4189ef0.log
The most important line is:
! LaTeX Error: Option clash for package inputenc.
Any ideas on how to solve this? Thanks so much.

Running python3 -m manim test1.py Shapes -pl (as you do) will create a .tex file with a cryptic name (probably 2b721902e4189ef0 in your case)  in manim/manimlib/files/Tex (the Tex folder is created by manim). Can we see it? Have you tried to run it in a LaTeX editor? Is your LaTeX installation up to date?

Thanks so much for getting back to me. It does generate the .tex file. Here it is:
`\documentclass[preview]{standalone}
\usepackage[english]{babel}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{dsfont}
\usepackage{setspace}
\usepackage{tipa}
\usepackage{relsize}
\usepackage{textcomp}
\usepackage{mathrsfs}
\usepackage{calligra}
\usepackage{wasysym}
\usepackage{ragged2e}
\usepackage{physics}
\usepackage{xcolor}
\usepackage{textcomp}
\usepackage{microtype}
% \DisableLigatures{encoding = *, family = * }
\usepackage[UTF8]{ctex}
\usepackage[hangul]{kotex}
\usepackage[utf8x]{inputenc}
\linespread{1}
\begin{document}
\centering hello
\end{document}`
Running this in a LaTex editor gives the same exact error: LaTeX Error: Option clash for package inputenc.
I have run brew cask install mactex and I believe it is up to date.

Finally, I've figured this out. There were issues in my tex_file_writing.py file that I had to fix. Thanks for your help!


Sign in problem

I can’t seem to login using the link you gave me, it comes up with the error ‘ERR_SSL_VERSION_OR_CIPHER_MISMATCH’ (From Ella @ Hendel).

We should confirm what link is actually being used?  Also the usual...

Browser type and version
Operating system
Screen shot

or suggest trying the unsecured version at http://unsecured.insight.blackradley.com/

Did we get any further information on this one?


API/metrics for pipeline health check

Summary
In terms of the health status of a pipeline, there's nothing to indicate it directly. It would be good to have a health check page or API giving the health status, to make monitoring and alerting easier.
The API/metrics should give a response including:

Pipeline overall status
Which vertex or component has what an issue if not healthy.

This API should still be working even if the pipeline is unhealthy, daemon service might be a good place to host this.

Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

Assign to me.


[US] Virtual Model Definition

As an application user, I want to have a virtual model definition, so that I can dynamically have access to my tables and columns when trying to use my database

MoSCoW
Risk
Story Points

Must-have
Low
2 SP

Acceptance Criteria

The virtual model successfully displays the tables and columns of the database.

Risks

The VMD displays the wrong information to the application user
The REST API does not function as intended, and the VMD can't display the tables

Tasks

[x] Setup the PostgREST API container
[x] Make React components in the frontend to act as the VMD
[x] Make API calls in the VMD directory to fetch the table and column information
[x]  Arrange the information in a specific data structure (Array for tables, maybe JSON object for tables + columns)

https://github.com/WillTrem/UInnovate/assets/78221579/4eefceec-7301-4601-ae3b-66b2f34a237c

This looks good.


Error retrieving list of subscriptions

When attempting to retrieve a list of subscriptions with azure_mgmt_subscription::operations::subscriptions::Client::list(), I receive the following error:
 Deserialize(Error("missing field 'nextLink'", line: 1, column: 1670)
It appears that this is due to SubscriptionListResult::next_link being non-optional, yet Azure isn't returning a nextLink field because there aren't enough subscriptions to need to page.
I'd try to pull together a PR, but I don't have the time to figure out the auto-rust magic.

I'd try to pull together a PR, but I don't have the time to figure out the auto-rust magic.

Thanks @polivbr. Pull requests that should what the generated code should look like are very useful. You can also use the fixed branches directly using a git dependency in Cargo.toml. This is probably going to be a spec bug, which I can report.

Fixed by #672.


Add [IF EXISTS] support to account management SQL

What type of PR is this：

[ ] bug
[ ] feature
[x] enhancement
[ ] others

Which issues of this PR fixes ：

Fixes #4524
Problem Summary(Required) ：

Add IF EXISTS support to following statements:
CREATE [IF NOT EXISTS] USER
CREATE [IF NOT EXISTS] ROLE
DROP [IF EXISTS] USER
DROP [IF EXISTS] ROLE
ALTER [IF EXISTS] USER

Implementation detail:
Add ignoreIfExists param to XXinternal.
Initially I tried to reuse the errOnNonExist params (e.g. setPasswordInternal), but even if the errOnNonExist is set false (e.g. mysql/priviledge/WhiteList.java:addUserPrivEntriesByResovledIPs), the related property is set, which is not correct in our case. Is this the desired behavior? So in alterUser, I make a special check before setPasswordInternal. This is kind of ugly. Any suggestions are welcomed.
P.S. I'm willing to fix the document but I can't find where to go.

 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.

Hi, first of all thank you for submitting your code for StarRocks. This is a very useful feature. But there is a problem at present. All the new functions of our grammar class need to be supported in the form of antlr4 in the new Parser, and the old cup will no longer be maintained in the future. So this function needs to rewrite the grammar file to the form of antlr4.
Here are two PRs that have been merged for your reference
https://github.com/StarRocks/starrocks/pull/4500
https://github.com/StarRocks/starrocks/pull/4262

Analyzer also no longer supports the code form of the old version. The new Analyzer entry is in starrocks/fe/fe-core/src/main/java/com/starrocks/sql/analyzer/

Oh thanks! I'll check the similar PRs and adapt to the new parser.

oops... When searching related issue, I just find that there's an ongoing geek camp issue #4046 seems much silimar to this PR. If the mentioned issue is about refactoring new parser and analyzer to support CREATE/DROP/ALTER USER/ROLE and is already assgined, I may leave this PR as a reference and wait for it.
@HangyuanLiu @xuzifu666

If you are not particularly urgent about this feature, you can wait for that PR development to complete before continuing your work.If you need this function very much, you can develop ROLE and USER related functions, and GRANT related functions will be developed by @xuzifu666

@HangyuanLiu @xuzifu666 I'm not in a hurry so please take your time.


fix: Rollback: wrong modification of state.LastHeightValidatorsChanged while rollback at a special height

closes: #2137 #1074
Description
Rollback at a specific height causes the node to fail to start. This is caused by the error code:
https://github.com/cometbft/cometbft/blob/635d0b596c7300c98caa57e7aab26a7a4579ab97/internal/state/rollback.go#L71
According to the definition of the State struct as below
https://github.com/cometbft/cometbft/blob/635d0b596c7300c98caa57e7aab26a7a4579ab97/internal/state/state.go#L63
LastHeightValidatorsChanged satisfy the following condition under any circumstances
1 <= state.LastHeightValidatorsChanged <= state.LastBlockHeight + 1 + 1
this condition can also be confirmed by looking at the code in func (store dbStore) save(state State, key []byte) error
https://github.com/cometbft/cometbft/blob/635d0b596c7300c98caa57e7aab26a7a4579ab97/internal/state/store.go#L229
state.LastHeightValidatorsChanged is with nextHeight + 1(state.LastBlockHeight + 1 + 1) corresponds.
When we rollback from block height state.LastHeightValidatorsChanged - 1 to height state.LastHeightValidatorsChanged - 2, newState.LastHeightValidatorsChanged would be wrong to modified into the state.LastHeightValidatorsChanged - 1
Issue
Let me give an example to describe the issue:
example

... => [block 242 (5validators)]  ==state1(5validators)==> [block 243 (5validators)]  ==state2(4validators)==> [block 244 (4validators)]   => ...

Assume that the current height of the block is 243, current state is state2 and state2.LastHeightValidatorsChanged == 244, validatorSet changed to 4 validators in the block 244 and state2

Rollback to block 242 and state1, the target rollbackHeight == 242

Since the error code, https://github.com/cometbft/cometbft/blob/635d0b596c7300c98caa57e7aab26a7a4579ab97/internal/state/rollback.go#L71
state1.LastHeightValidatorsChanged was changed to 243 incorrectly and it should be 244

After rollbacked to block 242, node could not start properly

Solution
See code for details.
PR checklist

[x] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[x] Updated relevant documentation (docs/ or spec/) and code comments
[x] Title follows the Conventional Commits spec

Thanks for the contribution @cosinlink, we'll have a look and review this soon.

Thanks @cosinlink ❤
Could you add a changelog entry .changelog/unreleased/bug-fixes/2136-fix-rollback.md?

ok, I will add a changelog

@Mergify backport v0.37.x


Operator Helm Chart is published within Helm Hub / Artifact Hub

Describe the feature request
It would be nice if Operator Helm Chart would be published somewhere like the Helm Hub or the Artifact Hub in order to ease installation/search.
https://hub.helm.sh/
https://artifacthub.io/
Note that I volunteer to do it for the Helm Hub if needed and accepted.
Describe alternatives you've considered
[ ] Configuration Infrastructure
[ ] Docs
[x] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience
[ ] Developer Infrastructure
Additional context

Please!
Also, I tried to install it with HelmOperator with git option like this
# istio-operator-release
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: istio-operator
spec:
  releaseName: istio-operator
  forceUpgrade: false
  chart:
    git: https://github.com/istio/istio.git
    ref: 1.7.4
    path: manifests/charts/istio-operator

but your repo wight 706MB, it is too much!
It doesn’t work :(


SFTP

I cannot find documentation on how to set SFTP certificate.
I tried manual and then it asks for an IIS (web not ftp) site.  I did not understand that part.
Thanks

sftp is not the same as ftps. If you have an ftp iis site, you can generate a cert for it, but the validation plugin needs a web server to  get Let's Encrypt to generate your certificate (You could also use the dns validation method)
Just to clarify:

the validation plugin is what generate the certificate
then the store plugin will choose where to put the cert
finally the installation plugin will apply the cert to your ftp binding.

thanks


Add "Pause on idle"?

Hey, thanks for creating this! ♥
How difficult do you think to have a "Pause on idle" option? I want to test how long I can record with this so I'll activate it all the time. But I don't want to have those "idle" frames recorded which will make it difficult for me when I review. Something like:

Pause recording if screen is locked, user is logged out, or machine is sleeping. Auto resume if unlocked, etc.
Pause recording if no mouse activity in 5 minutes. Auto resume (and reset the timer) if there's mouse activity.

My Swift knowledge is very limited but I can dig. Although, if you have pointer, it'd be great!

Pausing Recording on Logoout
It has been a while since I tested this, but I think everything is based on presentation time stamps. So, if you are logged out, your presentation time stamp is not increasing. Therefore, you should not be contributing to an increased bitcount.

Determining new information per frame
Determining whether or not a frame contains new information should not be too bad. There is something called dirty rects which is given by ScreenCaptureKit and contains an array of rectangles that have changed on the screen every frame.
Documentation on Dirty Rects
Checking if the length of the dirty rects list is zero would be all that is required to not save these frames.
This could be as simple as adding a check in the appendBuffer function in the file Recordable.swift


Incorrect API version mapping for MGMT_STORAGE for the 2017-03-09-profile

Description
API version mapping for MGMT_STORAGE for the 2017-03-09-profile  is incorrect.
it needs to be changed to 2016-01-01
page https://github.com/Azure/azure-cli/blob/master/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L77

CC: @viananth


Is error handling for "_ = _refresher.TryRefreshAsync();" needed?

_ = _refresher.TryRefreshAsync(); is to refresh configuration without waiting, as the document mentioned https://learn.microsoft.com/en-us/azure/azure-app-configuration/enable-dynamic-configuration-aspnet-core?tabs=core6x#request-driven-configuration-refresh, the operation will not block or slow down the incoming request that triggered the refresh. This is great,
but may I double confirm as a consumer, do I need to take care of the error handling? Will the unwaited task lead to any unobserved exceptions?

Hi @lissdy, calling TryRefreshAsync without waiting does not require additional error handling on your behalf. Any exceptions thrown during refresh are handled by this method.


Moved fields and mappers to advanced section in ILM article

Status
Ready
Related Issues
fixes: https://github.com/demisto/etc/issues/33430
Description
Created an advanced section and moved "fields and mappers" under that.

@idovandijk you have conflicts. Please merge from master.


Update recipe

Closes https://github.com/conda-forge/x264-feedstock/pull/7

Pin perl to the currently used version <IP_ADDRESS>.
Use 2-space indentation in meta.yaml.
Re-render with conda-smithy 2.2.2.
Package the license file.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


hare-bootstrap: fix consul leader check

With bash set -o pipefail, the following construction
may give a false negative status result:
cmd | grep -q something

if the cmd returns multiple lines.
The reason is that the grep command with -q option
finishes immediately as soon as it finds something.
But in case of multiple lines output from cmd, the
latter might fail killed by SIGPIPE. So the resulting
status of the whole command will be 141 instead of 0.
This is exactly what happens sometimes when we check
the status of internal Consul leader on bootstrap.
On slow virtual machines (like arm64 in QEMU) the
check in the loop might take a lot of time returning
false negative result until it happens that the grep
process is not finished yet before the cmd process
finishes outputting into the pipe.
Solution: use the following construction instead:
grep -q something <<< $(cmd)

@andriytk, does this mean that before the cmd puts data in the pipe, grep tries to read from it and fails?

@andriytk, does this mean that before the cmd puts data in the pipe, grep tries to read from it and fails?

@mssawant no, not exactly. Grep does read the data and finds the match. And as soon as finds it, it finishes (because of -q option). But cmd is not finished yet. It still has some data to put into the pipe. But the pipe is not available any more (because the grep process has finished already). So the cmd is killed by SIGPIPE signal. As a result, the overall command status fails (because bash was set -o pipefail, so the resulting status is the status of the 1st failed cmd in the pipe).

Thanks @knekrasov. Added. Please, take a look if it's clear enough.


No addons installed when Prometheus is not installed

When creating a KIT Control Plane and Data Plane without Prometheus installed, the KIT Controller is unable to install any addons due to reconcile errors for Pod Monitors.
2022-06-21T18:50:47.853Z	ERROR	controller.control-plane	Reconciler error	{"reconciler group": "kit.k8s.sh", "reconciler kind": "ControlPlane", "name": "kit-guest-cluster", "namespace": "kit", "error": "reconciling resource, control plane reconciling, ensuring podmonitor for kit-guest-cluster-apiserver, getting object when creating , name kit-guest-cluster-apiserver, no matches for kind \"PodMonitor\" in version \"monitoring.coreos.com/v1\""}

This results in an unhealthy dataplane as kubeproxy and coredns are never installed

Handle the error here
By checking the error like this and ignoring the error.


error handling

Many activities don't have error handling, which may be helpful for diagnosing problems getting started. For example, a token refresh is just assumed to have worked, so if it failed then the next attempt to use the graph API will get a 4xx status code.

Added handling of failed request for access token (e.g., because the refresh token has expired). There are surely other errors to be handled, will address those as they come up.


_pickle.UnpicklingError: A load persistent id instruction was encountered, but no persistent_load function was specified.

Hi. I am running into the following error. I am wondering if you can help me.
Traceback (most recent call last):
  File "[path]/AIR-ASVspoof/dataset.py", line 53, in __getitem__
    feat_mat = pickle.load(feature_handle)
_pickle.UnpicklingError: A load persistent id instruction was encountered,
but no persistent_load function was specified.

Thanks

It seems that the data you are trying to load with pickle has a different data structure. Please refer to https://stackoverflow.com/questions/25151206/python-cpickle-load-fails-with-unpicklingerror
Did you run my reload.py?
Also, please check the version of pickle and numpy you are using. I am not sure if version difference will cause issues.

I have not, that might be it. I will try that and update here.

Thank you, issue resolved; it was due to reload.py not running


bug when rendering empty Box

first of all am a big fan
great work i've been working with gestelt since  v 1.47.0
now im use  version 11.20.0
when i render an box  hold a value  needs some check   or render based on prop
like
                {process.process &&
                  process.process.score &&
                  process.process.score == 1 && <Text>33%</Text>}

it brings back a ZERO   0
i dont have a time to track the bug  but its not from my code clearly
cause this pattern  happen every time  i try in an empty component
thanks again for the great work <3

@hazem-a1 could this be related to https://stackoverflow.com/questions/53048037/react-showing-0-instead-of-nothing-with-short-circuit-conditional-component ?
I would try Boolean(process.score && process.process.score == 1) && <Text>33%</Text> to confirm


Update to Java8 181 b13

Update Java8 version.

the latest as of 12/31/18 is now:
ENV UPDATE 192
ENV BUILD 12
ENV SIG 750e1c8617c5452694857ad95c3ee230


Math: Add Queries on Number of Points Inside a Circle in Python

https://leetcode.com/problems/queries-on-number-of-points-inside-a-circle/

Hey @akgmage Assign it to me

Hey @akgmage this question is completed
Please, Close this issue


Small minor adjustments to DG for standardization

Codecov Report

Merging #271 (3ffd6ce) into master (f18d8a9) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #271   +/-   ##
=========================================
  Coverage     60.32%   60.32%
  Complexity      796      796
=========================================
  Files           125      125
  Lines          2926     2926
  Branches        294      294
=========================================
  Hits           1765     1765
  Misses         1029     1029
  Partials        132      132

Continue to review full report at Codecov.

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


Add getActiveProcesses function to baker

Codecov Report

Merging #153 into master will decrease coverage by 0.24%.
The diff coverage is 77.77%.

@@            Coverage Diff             @@
##           master     #153      +/-   ##
==========================================
- Coverage   85.03%   84.79%   -0.25%
==========================================
  Files         112      112
  Lines        2720     2736      +16
  Branches      132      135       +3
==========================================
+ Hits         2313     2320       +7
- Misses        407      416       +9

Impacted Files
Coverage Δ

...ala/com/ing/baker/runtime/core/BakerResponse.scala
84.37% <ø> (+2.55%)
:arrow_up:

...ker/runtime/actor/process_index/ProcessIndex.scala
83.76% <0%> (-0.73%)
:arrow_down:

.../baker/runtime/actor/LocalBakerActorProvider.scala
100% <100%> (ø)
:arrow_up:

.../main/scala/com/ing/baker/runtime/core/Baker.scala
81.45% <68.42%> (-2.72%)
:arrow_down:

...aker/runtime/actor/ClusterBakerActorProvider.scala
81.13% <80%> (-6.97%)
:arrow_down:

Continue to review full report at Codecov.

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


Activity bar top: buttons shift when activity clock appears on one

For example, if Git SCM performs periodic fetch all icons to the right of the SCM one get shifted right momentarily.
Perhaps spin the SCM icon to denote in-progress activity, instead of adding a clock to the right of it.

/duplicate
https://github.com/microsoft/vscode/issues/195130

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Lower version requirement in go.mod to Go 1.16

Users should be able to use older toolchain versions to bootstrap newer distributions. This change lowers the version requirement for the host compiler to Go 1.16.

I'm not sure about this. In fact I think we should increase it to go1.19 since the code in this repo, as it stands, is incompatible with any older version of Go.


Fix contract changes

made geared field optional
removed deprecated fields: gear_details and cranes_ton_capacity
added dev container

@ktsitsikas-signal
I added the .devcontainer intentionally to aid future development and it does not have an effect on build and production.
If you believe it's not beneficial I will remove it

@LevBlaivasSignal clear, good to stay


Test on Windows

If works OK, then add corresponding information on README file.

PyYAML installation fails with the following error, the rest seems ok:
  creating build\temp.win-amd64-2.7\Release
  checking if libyaml is compilable
  error: [Error 2] The system cannot find the file specified

  ----------------------------------------
  Failed building wheel for pyyaml
  Running setup.py clean for pyyaml
Failed to build pyyaml
Installing collected packages: pyyaml
  Running setup.py install for pyyaml ... error
    Complete output from command c:\users\dzhoshkun\ws\endocal-venv-py2\scripts\python.exe -u -c "import setuptools, tokenize;__file__='c:\\users\\dzhosh~1\\appdata\\local\\temp\\pip-build-m5rgvk\\pyyaml\\setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record c:\users\dzhosh~1\appdata\local\temp\pip-u63gud-record\install-record.txt --single-version-externally-managed --compile --install-headers c:\users\dzhoshkun\ws\endocal-venv-py2\include\site\python2.7\pyyaml:
    running install
    running build
    running build_py
    creating build
    creating build\lib.win-amd64-2.7
    creating build\lib.win-amd64-2.7\yaml
    copying lib\yaml\composer.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\constructor.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\cyaml.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\dumper.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\emitter.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\error.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\events.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\loader.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\nodes.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\parser.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\reader.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\representer.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\resolver.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\scanner.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\serializer.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\tokens.py -> build\lib.win-amd64-2.7\yaml
    copying lib\yaml\__init__.py -> build\lib.win-amd64-2.7\yaml
    running build_ext
    creating build\temp.win-amd64-2.7
    creating build\temp.win-amd64-2.7\Release
    checking if libyaml is compilable
    error: [Error 2] The system cannot find the file specified

    ----------------------------------------
Command "c:\users\dzhoshkun\ws\endocal-venv-py2\scripts\python.exe -u -c "import setuptools, tokenize;__file__='c:\\users\\dzhosh~1\\appdata\\local\\temp\\pip-build-m5rgvk\\pyyaml\\setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record c:\users\dzhosh~1\appdata\local\temp\pip-u63gud-record\install-record.txt --single-version-externally-managed --compile --install-headers c:\users\dzhoshkun\ws\endocal-venv-py2\include\site\python2.7\pyyaml" failed with error code 1 in c:\users\dzhosh~1\appdata\local\temp\pip-build-m5rgvk\pyyaml\

(endocal-venv-py2) C:\Users\dzhoshkun\ws\endocal-venv-py2>

16.7.28rc12 mentioned in #20 works on Windows, after fixing the PyYAML issue mentioned above.

The above PyYAML issue is already addressed in the troubleshooting file. As of the master branch right now (8 August 08:02 am), endocal works on Windows with Python 2. Currently can't install with Python 3 as py2 is engraved in the filename of the wheel, which makes the package unacceptable to Python 3. Will check within #3 whether Windows works.


Put this App on F-Droid

I would love to see this app added to the F-Droid repository. Considering it is on github, that should be fairly easy as explained here:
https://f-droid.org/manual/fdroid.html#Importing-Applications
I always search on F-Droid first when I need an app and try to use FOSS wherever possible. More people would find it if it were uploaded there. Also, this would make the project easier to install for people with non-stock ROMs without the Play Store.

+1

+1

+1


Live sample

it would be nice to see a live example of custom elements/webcomponents with RoboJS. I understand the technique well but don't know how can we use in real life.

Hi, as soon as possible I will write a live example, thanks for the advice

Hi,
I created a quick demo on http://marcog83.github.io/RoboJS/
It simulate a bunch of modules loaded from server (on the left), and a page where to place them (on the right).
Hope it can be useful.

Oh, wonderful. Thank you so much.


[FEATURE REQ] Add support for extracting multiple configuration keys for a single secret

Library or service name.
What library or service is this request related to?
Azure.Extensions.AspNetCore.Configuration.Secrets
Is your feature request related to a problem? Please describe.
What feature would you like to get added? What problem is it solving?
We have a legacy code base that has configuration files that look like so:
{
  "service-one" : {
       "baseUrl": "https://contoso.com/api1"
       "clientId": "some-id",
       "clientSecret" : "AKeyVaultSecretName"
  },
  "service-two" : {
       "baseUrl": "https://contoso.com/api2"
       "clientId": "some-id",
       "clientSecret" : "AKeyVaultSecretName"
  }
}

Currently we have custom configuration loader and we are trying to move to aspnet core with minimal changes to our infrastructure provisioning code. It would be convenient to have KeyVaultSecretManager support GetKeys in addition to GetKey. I have working implementation that I hope we can get merged.

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Duplicate of https://github.com/Azure/azure-sdk-for-net/issues/11943


Add timing offsets to range data.

SLAM quality can be improved by applying the transformation most correct in time to each point in range data. For good performance, we do not want to pass each point individually timed through the pipeline, but instead pass range data where each point can have a time offset.
Initial implementation:

Add a 4th component to range data representing a time offset in seconds, similar to #571.
Handle this data in voxel filtering and accumulation in the local trajectory builders.

Later it might make sense to also change accumulation to be based on time instead of number of range data, or to change the local trajectory builder to take time offsets into account during scan matching (without the need for an unwarping step beforehand). Also, the origin might be interpreted to be at time offset zero, and transformed accordingly for improved quality ray casting.

So when a laser scan comes in you offset backwards from that message's time stamp, right? Would you use the scan_time parameter in the ROS message to determine that window? That would be helpful. Maybe if it's zero or doesn't exist, you could make an assumption that scans take period * 0.5 time up to 50ms or something.

This issue is not directly related to ROS, but about adding support for per-point timing to the Cartographer library. One way to make use of it in Cartographer ROS can be seen in googlecartographer/cartographer_ros#526: Using time_increment.


feature/Awais/added_colNameSplitter_prop_to_display_column_name_with_…

this componant did not allow the spaces in column name so i added a prop to to split column name ob the base of any character and replace that using with space.
this feature only apply changes to display names of columns,not there actual keys.
now we can read column names more clearly on small screen devices where column names will not overlap.
new prop:
colNameSplitter
prop type:
single character string
example: (props passed)
data[{the_first_column : 'value'}]
colNames : ["the_first_column"]
colNameSplitter : {"_"}
output column name will be:
THE
FIRST
COLUMN
(behaves like wrap property of css)

i resolved issue #6 in this PR.

Thanks @AwaisBinKaleem for this PR. I reviewed, But I done this work within 2 lines.

So, I think there's no need to merge this pull request. What you think? @AwaisBinKaleem

ok thanks.
that would be good method if u already did that.
i am new to programming so i just did that for my learning.
it was my first ever try to fork a project on GitHub.
just let me notify when this new feature will be released to use.

You did it very well Excellent, I saw. Don't worry I will merge your pull request too because it's your first time. I will notify you.


how to avoid short names?

Hi,
Assuming I'm trying to parse the next expression:
DEBUG=* node --harmony --expose-gc  app.js --domain=domain_name

With this configuration:
var r = Parsec.parse(process.argv).options('domain',{default:defaultDomain}).
                options('env',{default:defaultEnv});

As result, I get the next:
{ domain: 'default_domain',
  options: [Function],
  d: 'default_domain',
  env: 'local',
  e: 'local' }

I do not want the short keys to be present there. How can I avoid it?
btw, I do not want the options key to be present there as well, but it's not so important.
Regards,

Looks like this approach would help:
var parsecObject = Parsec.parse(process.argv)
                .options(['domain'], {default: defaultDomain}).
                options(['env'], {default: defaultEnv});

1
DEBUG="*" node --harmony --expose-gc  examples/index.js --domain=domain_name

Result:
{
  domain: 'domain_name',
  options: [Function],
  d: 'domain_name',
  env: 'defaultEnv',
  e: 'defaultEnv'
}

I do not want the short keys to be present there. How can I avoid it?

Right. You don't need the short keys, because you want to always use the more readable long option version if there is one. This however is usually irrelevant, because the long option is there anyway, so I don't see how the short option could be interfering with your use case. I can't just force remove the short options, because there could be a use case for them as well. As you probably noticed already, the default behavior is => "string" injects s and string in the returned object.
If you want to get only the long option, you can pass an array like you yourself suggested. Another idea could be to add an option to parse, for example:
Parsec.parse(process.argv, {  shortLess: true })...
2

I do not want the options key to be present there as well, but it's not so important.

I see what you mean. This one was a tough call for me too, but without this Parsec would be too limited IMO. I don't think there is a straightforward way to purge options since the options method returns an object with an options method itself. Perhaps, making options appear first and having parse come at the end could be an alternative, but the composition would change significantly.
Parsec
  .options("")
  .options("")
  .parse(process.argv)

Not a big deal really and it should not be too hard to implement. This way we could get rid of options without trouble.

Thanks for the answers.
I think the shortname issue should be optional, because for me the shortname from my longname has no logic, because at the beggining I've "ordered" only to parse the longname one :)
Indeed all of my issues were solved for now. Thanks for the library.
The options was solved like (using https://lodash.com/):
this.cliConfig = _.omit(parsec,'options');

Regards,

I see what you mean now.
It's very common to have the short option as the first letter of the long option, hence the current behavior. For extraordinary use cases, the solution is still pretty simple, .options(["option"]).
If I change the composition to
Parsec
  .options("")
  .options("")
  .parse(process.argv)

we don't need lodash only for this, but can I ask you one thing, why do you need to omit the options property? Are you perhaps handling an option named options in your program?

Closing this.
@PavelPolyakov Feel free to post your comments anytime. :+1:


Selection of Data sources

Select appropriate data sources.
Two sources are required

Source for crime data
Source for "disorder" data
Source for ZIPCode Regions
Source for Street Names

Chose Sources as decribed in project-plan.md


Can I use this source for iOS?

Is it possible to make an iOS app with this source, or this is only for macOS?
Thank You!

I believe that somewhere in documentation or readme that it's only for
macOS because of some protocols used.
On Sun, Apr 8, 2018 at 1:42 AM danylokiz<EMAIL_ADDRESS>wrote:

Is it possible to make an iOS app with this source, or this is only for
macOS?
Thank You!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/beltex/SystemKit/issues/29, or mute the thread
https://github.com/notifications/unsubscribe-auth/AMToSUloVBOkfdAgZ3xfd-vf85gQ8LLYks5tmc1agaJpZM4TLcx1
.

--
Daniel Stagnaro


Can't input more than 9999 MEGA to send

I tested some other tokens without proper token metadata, but they didn't have this issue. Also tokens with metadata don't have the same issue either.
This token does have some of the metadata showing such as token Name/ticker but not the logo. I think this may be caused by some issue with the metadata: checking with Rafael here: https://github.com/hirosystems/token-metadata-api/issues/140#issuecomment-1872254404

Looks like the interface is expecting (or defaults to 6 decimals) whereas the token has 2 decimals as displayed correctly in the lower right corner:

Rafael has updated the metadata but that didn't fix the issue in Leather, there is no change, I am not sure what is causing this.
Metadata looks not to different from other tokens
https://api.hiro.so/metadata/v1/ft/SP3D6PV2ACBPEKYJTCMH7HEN02KP87QSP8KTEH335.mega
Most other tokens have 6 or 8 decimals, mega has 2.
cached image looks accessable: https://ipfs.io/ipfs/Qmdgks1HjYZQhF4sTnkoeh7naic7J3G5aHQk91Uq25RwmF

@alter-eggo is this issue also resolved by https://github.com/leather-wallet/extension/pull/5048?


Set visibility: hidden on dummy scrollbars if native ones are invisible

Fixes #14661
This prevents the cursor from unexpectedly changing when approaching the bottom/right corner of the editor with the mouse, even when no scrollbar is being shown.
/cc: @nathansobo @ungb @50Wliu @Ben3eeE

I did a very quick test of this and it looks like it fixes the issue. One thing I noticed is that the cursor changes to a pointer before you can use the scroll bar.

Of course. Visibility hidden. Why am I not thinking of obvious stuff lately?


Improve performance of ItemScheme

Searching in, and appending to Item and ItemScheme has poor Performance due to the use of list instead of dict or set. In v0.9, ItemSchemes were DictLike instances with item id as dict keys. As certain codelists are very Long (I've seen more than 50k items), poor Performance is a concern. My first Suggestion would  be to borough some of the v0.9 Code while keeping the useful parent-child relationship.

Can you give an example of a specific case where this takes too long?

Sorry. I can't as I don't know what you mean by too long. I've just
found a number of minor Code Quality issues in model.ItemScheme which
Impact Performance and stability. E.g.:

Long lists are ill-suited for linear searching
Attribute Access should be simplified by using getattribute as
it is called only upon AttributeError
drop recursive search in contains as children are always
contained in the same ItemScheme as its parents. This may even yield
inconsistent results when contains is called by more complex
iterators, e.g. when an item is child to multiple parents.

Btw: Are you Aware of any practical example of hierarchical Code lists?
Moreover, I think ItemScheme and its subclasses should accept any
Iterable rather than just List.

__

On 21/08/2019, Paul Natsuo Kishimoto<EMAIL_ADDRESS>wrote:

Can you give an example of a specific case where this takes too long?
--
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub:
https://github.com/dr-leo/pandaSDMX/issues/104#issuecomment-523417701

Sorry. I can't as I don't know what you mean by too long.

In software development, performance must be quantified by some metric, such as:

time,
memory use,
disk usage,
network traffic or bandwidth

…required to accomplish a certain task.
"poor performance" implicitly means, "I believe that doing [operation X] should take no more than T1 seconds; instead it takes T2, which is greater than T1—i.e. too long."
Similarly, "Impact Performance" implicitly means "doing [operation X] in [way A] takes T1 seconds; doing it in [way B] takes T2 [> T1] seconds, and T1 is acceptable whereas T2 is not."
Python has built-in features for timing small bits of code, such as the look-ups you refer to.
Without (a) a specific example of code ("operation X"), and (b) specific, i.e. quantified, values for its current and desired performance (T1 and T2), there's no way to decide when the issue has been addressed, or how to prioritize it. The same applies over in #103.

Btw: Are you Aware of any practical example of hierarchical Code lists?

ISTAT does, I believe.

ItemScheme and its subclasses should accept any Iterable rather than just List.

This is a convenience that could be added as an enhancement. But, again, let's please try to use separate issues for atomic topics.

Largely addressed by #108.


Validate that codeSize is a multiple of 4 for SPIR-V

Unless the application is using VK_NV_glsl_shader (which hopefully no-one is, but it's easy to handle if they do) the VkShaderModuleCreateInfo::codeSize member should be a multiple of 4, since it's a byte count of a stream of 32-bit words.
It would also be nice to validate that the SPIR-V is legal too, but that's obviously a larger task.

We already pass the module through the SPIRV-Tools validator. It looks like we lost the multiple of 4 size validation when we put that in, and they can't implement it on their side, since they take the size as a count of words rather than of bytes. Can put that back in on our side.

Fix pushed to Master -- Thanks for the report!


PEP8: need some reworking, but it's a start :)

Py files formatted by pyformat
Added .gitignore file.
Some reworking on comments.
PS: a little sprint from PyCon6... after your talk! See you around!

Fine, thank you so much for your contrib. I will check the changes and I
will apply the patch.
2015-04-19 12:22 GMT+02:00 Christian Strappazzon<EMAIL_ADDRESS>
Py files formatted by pyformat
Added .gitignore file.
Some reworking on comments.
PS: a little sprint from PyCon6... after your talk! See you around!
You can view, comment on, or merge this pull request online at:
https://github.com/dddomodossola/gui/pull/2
Commit Summary

Used pyformat in order to format all the py files
Fixing some issues on comments after formatter :)

File Changes

A .gitignore
https://github.com/dddomodossola/gui/pull/2/files#diff-0 (60)
M configuration.py
https://github.com/dddomodossola/gui/pull/2/files#diff-1 (7)
M gui.py https://github.com/dddomodossola/gui/pull/2/files#diff-2
(1131)
M server.py
https://github.com/dddomodossola/gui/pull/2/files#diff-3 (408)
M simple_app.py
https://github.com/dddomodossola/gui/pull/2/files#diff-4 (58)
M widgets_overview_app.py
https://github.com/dddomodossola/gui/pull/2/files#diff-5 (318)

Patch Links:

https://github.com/dddomodossola/gui/pull/2.patch
https://github.com/dddomodossola/gui/pull/2.diff

—
Reply to this email directly or view it on GitHub
https://github.com/dddomodossola/gui/pull/2.


Review of the telemetry events

Is your enhancement related to a problem? Please describe
We'd like to review the telemetry events we are reporting to ensure we have proper information about how the users are using the extension and where they are eventually facing challenges
Describe the solution you'd like
We'd like to review the telemetry events we are reporting to ensure we have proper information about how the users are using the extension and where they are eventually facing challenges
Describe alternatives you've considered
No response
Additional context
No response

Notes from meeting this morning:

[ ] Log event for clicking on pull in the welcome
[ ] Log event when switching to the build page
[ ] Chart to show type of images being built
[ ] Chart to show architecture of images being built

Telemetry in, charts updated, but forgot to list the implied charts required for the new telemetry. Will add these, then close.

https://github.com/containers/podman-desktop-extension-bootc/pull/288 is closed, I believe we can close this now?

I've verified all events are being output and appear in Segment, and have drafts of all charts. Closing.


download_file cannot be used twice in the same rule because it cannot specify an identifier

The following example doesn't seem to work, though I think it should:
defs.bzl:
def __download_license_data_impl(ctx: "context") -> ["provider"]:
    base_url = lambda name: "https://github.com/spdx/license-list-data/blob/{}/json/{}.json".format(ctx.attrs.revision, name)
    def dl_json_file(name, sha1):
        name = "{}.json".format(name)
        out = ctx.actions.declare_output(name)
        ctx.actions.download_file(out, base_url(name), sha1 = sha1)
        return out

    if len(ctx.attrs.sha1) != 2:
        fail("sha1 must be a list of two strings")

    if "licenses:" != ctx.attrs.sha1[0][:9]:
        fail("first sha1 hash must start with 'licenses:'")
    if "exceptions:" != ctx.attrs.sha1[1][:11]:
        fail("second sha1 hash must start with 'exceptions:'")

    licenses_sha1 = ctx.attrs.sha1[0][9:]
    exceptions_sha1 = ctx.attrs.sha1[1][11:]

    licenses_out = dl_json_file("licenses", ctx.attrs.sha1[0])
    exceptions_out = dl_json_file("exceptions", ctx.attrs.sha1[1])

    return [
        DefaultInfo(default_outputs = [ licenses_out, exceptions_out ])
    ]

download_license_data = rule(
    impl = __download_license_data_impl,
    attrs = {
        "revision": attrs.string(),
        "sha1": attrs.list(attrs.string()),
    },
)

and BUILD:
load(":defs.bzl", "download_license_data")

download_license_data(
    name = "spdx_license_data",
    revision = "v3.19",
    sha1 = [
        "licenses:cd5e714801727eb3dce52908ed818b5f54ddd6ba",
        "exceptions:69ca85d10f0737ddd5fd6c68d047bfb0f0fc65a7",
    ],
)

yields:
When running analysis for `root//src/larry:spdx_license_data (prelude//platform:default-7b06d4530de034dc)`

Caused by:
    Analysis produced multiple actions with category `download_file` and no identifier. Add an identifier to these actions to disambiguate them

But download_file can't take an identifier!

Oops. That looks like a bug

Cc @krallin

We should just use the output file like we do for write actions, I'll put that up


Added comments to main.py for clarity

I added comments to the main.py file to help new contributors understand the codebase better. This should make the project more accessible and easy to contribute to. Please let me know if you have any questions or need further clarifications.

Thank you!
We don't want what is referred to as "mumbling" in the comments though, so closing for now


Octant should create a path and start if plugin path is not found

Describe the problem/challenge you have
If the plugin path does not exist (~/.config/octant/plugins), there is a warning in logs:
2021-02-18T12:09:31.940-0800	WARN	plugin/manager.go:368	unable to add /home/sfoo/.config/octant/plugins to JavaScript plugin watcher
github.com/vmware-tanzu/octant/pkg/plugin.(*Manager).watchJS
	/home/sfoo/octant/pkg/plugin/manager.go:368

However, octant doesn't start up. The patch should be created automatically if missing.
Environment:

Octant version (use octant version): 0.17
OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): manjaro

Nevermind, it was a local build issue.


Normalize Device Names when checking duplicates

improves the client side check so we don't get a server error

mirrors the server normalization in the service for checking duplicate device names
includes paper keys in keybase1.AllDeviceNames() to check for duplicates
removes duplicate frontend code and improves error message to avoid confusion on normalization (open to suggestions here)

error when simple collision:

error when normalization causes collision:

merging over flake


mtls/crypto/tls: maintain cipher suite order

it seems currently the client has no control of the cipher suite order, with extra ciphers being appended for example:
https://github.com/mosn/mosn/blob/a6f072bd2d46be6489e8a6bb8a7aedff91b6a5d4/pkg/mtls/crypto/tls/handshake_client.go#L144
is it possible for a client to set a list in a specific order, and not have it altered by the package? I have encountered servers (for example android.clients.google.com) that will return 403 Forbidden if CipherSuites sent by the client is in the wrong order.

I found a workaround with another package:
package cipher

import (
   "bufio"
   "github.com/refraction-networking/utls"
   "net"
   "net/http"
)

func get(addr string) (*http.Response, error) {
   req, err := http.NewRequest("GET", addr, nil)
   if err != nil {
      return nil, err
   }
   dial, err := net.Dial("tcp", req.URL.Host + ":" + req.URL.Scheme)
   if err != nil {
      return nil, err
   }
   cfg := tls.Config{ServerName: req.URL.Host}
   client := tls.UClient(dial, &cfg, tls.HelloCustom)
   spec := tls.ClientHelloSpec{
      CipherSuites: []uint16{
         0x1302, // TLS_AES_256_GCM_SHA384
         0xC02C ,// TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      },
      Extensions: []tls.TLSExtension{
         &tls.SupportedCurvesExtension{
            []tls.CurveID{tls.X25519},
         },
         &tls.SupportedPointsExtension{
            SupportedPoints: []byte{0},
         },
      },
   }
   client.ApplyPreset(&spec)
   req.Write(client)
   return http.ReadResponse(bufio.NewReader(client), req)
}

please describe with mosn code or standard  go lib code

Here is the same code with Mosn, that produce unexpected result:
package cipher

import (
   "bufio"
   "mosn.io/mosn/pkg/mtls/crypto/tls"
   "net"
   "net/http"
)

func get(addr string) (*http.Response, error) {
   req, err := http.NewRequest("GET", addr, nil)
   if err != nil {
      return nil, err
   }
   dial, err := net.Dial("tcp", req.URL.Host + ":" + req.URL.Scheme)
   if err != nil {
      return nil, err
   }
   cfg := tls.Config{
      CipherSuites: []uint16{
         0x1302, // TLS_AES_256_GCM_SHA384
         0xC02C ,// TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      },
      ServerName: req.URL.Host,
   }
   client := tls.Client(dial, &cfg)
   req.Write(client)
   return http.ReadResponse(bufio.NewReader(client), req)
}


Zotero stuck for several seconds when edit item

Zotero version: <IP_ADDRESS>
BBT version: 6.1.1
OS: Win10
Your question/suggestion: Zotero will be stuck for 2 or 3 seconds each time I edit items, such as add new tags for a paper. If I disable  zotero-better-bibtex, the problem disappears. So I am wondering whether this add-on causes the above problem,  and what zotero-better-bibtex will do when I add new tags or a new note for a paper.  BTW, there are ~2500 items in my Zotero library.
Any suggestions? Thanks a lot!
Support log ID:

I cannot do anything for you without a support log.

I am sorry for ommiting the support log. I followed the template of Question on use not covered by the other categories above. and it does not mention support log. Maybe I choose the wrong category. Despite this, it is my mistake. Now I know how to find the support log of BBT and Zotero (Help->), and I will try to figure this out and update the progress.
Thanks for your time!

You are right, the question template doesn't explain when not to use it. I'll update the issue templates to clarify this. But if you want me to look into this slowdown, I need a support log.

To be clear, Zotero should not be stuck 2 seconds after each edit, and certainly not for a library of this size. If you have tens of thousands of entries and are auto-exporting them, then maybe, but then I'd recommend different settings. A support log will give me your BBT settings too.

The Support log ID is: 943C74ZS-apse.
"If you have tens of thousands of entries and are auto-exporting them, then maybe"
Yes, I set automatic export to be On Change.

For a small library as this, that's the  recommended setting. I'll look at the log when I'm done cooking.

It solves the problem with auto-exporting Disabled. Maybe there are too many items (about 2500) in my library, and it takes time to update each time I edit the items. Enjoy cooking. Thanks for your time.

2500 is a small library. You could see slowdown if you have tens of thousands of items.


fix(release): the error of missing dist files

Add .npmignore file

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Disable webcl

To disable WebCL
Leverage existing flag "enable_webcl" to disable functions and exclude
related code in Blink.
Reduced size = 44K

@heke123 @halton
Please have a look.
The pair patch is
https://github.com/crosswalk-project/blink-crosswalk/pull/84

@heke123 @halton
It will pass compile with crosswalk-project/blink-crosswalk#84 applied in Blink repo.

@heke123
It's not necessary. thx.

@heke123

LGTM

@PeterWangIntel please force update to re-trigger the trybot

@halton , please help to merge


Add docs

Add gitignore
Add basic example and docs

Looks great, there's a repeated with in the docs. Fix that and I can merge it afterwards or feel free to just merge yourself.


MCE Console Fixes

Signed-off-by: Erin Murphy<EMAIL_ADDRESS>Issue: https://github.com/stolostron/backlog/issues/26671
Jira: https://issues.redhat.com/browse/ACM-1983

Tested on OCP 4.12 with console disabled. Could not delete MCE. Error in logs:
1.6687089606487985e+09	INFO	Failed to find console: cluster	{"controller": "multiclusterengine", "controllerGroup": "multicluster.openshift.io", "controllerKind": "MultiClusterEngine", "multiClusterEngine": {"name":"dummy-multiclusterengine"}, "namespace": "", "name": "dummy-multiclusterengine", "reconcileID": "a3ca5f53-95b5-4944-a161-50a425314576"}
1.6687089606488295e+09	INFO	Error ensuring plugin is removed from console resource	{"controller": "multiclusterengine", "controllerGroup": "multicluster.openshift.io", "controllerKind": "MultiClusterEngine", "multiClusterEngine": {"name":"dummy-multiclusterengine"}, "namespace": "", "name": "dummy-multiclusterengine", "reconcileID": "a3ca5f53-95b5-4944-a161-50a425314576"}

Just added a commit that should address this, just deleted this extra check from my previous commit by accident

/override ci/prow/sonar-pre-submit