text:
Build successfully for mac M1 (Apple Silicon), but Hyperion app can't run

[x] I confirm that this is an issue rather than a question.

Bug report
Build successfully for mac M1 (Apple Silicon), but Hyperion app can't run with error
Steps to reproduce
I builded Hyperion app follow this guild https://github.com/hyperion-project/hyperion.ng/blob/master/doc/development/CompileHowto.md in Mac M1.
and run Hyperion.app but got error.
What is expected?
Hyperion app can run natively in Mac M1
What is actually happening?
I builded Hyperion.app in Mac M1, everything was ok until I run command "cpack", I could still create the complete .dmg file, but I had got these warning lines while cpack was running:
macbookairm1@Macbooks-MacBook-Air build % cpack
CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: hyperion
CPack: - Install project: hyperion []
CPack: -   Install component: Hyperion
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/platforms/libqcocoa.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtDBus.framework/Versions/5/QtDBus
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtPrintSupport.framework/Versions/5/QtPrintSupport
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/platforms/libqminimal.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/platforms/libqoffscreen.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/platforms/libqwebgl.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtNetwork.framework/Versions/5/QtNetwork
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtQml.framework/Versions/5/QtQml
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtQmlModels.framework/Versions/5/QtQmlModels
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtQuick.framework/Versions/5/QtQuick
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtWebSockets.framework/Versions/5/QtWebSockets
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/sqldrivers/libqsqlite.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtSql.framework/Versions/5/QtSql
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqgif.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqicns.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqico.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqjpeg.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqmacheif.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqmacjp2.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqsvg.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtSvg.framework/Versions/5/QtSvg
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqtga.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqtiff.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqwbmp.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/plugins/imageformats/libqwebp.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/libusb-1.0.0.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/Python.framework/Versions/3.10/Python
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: /Users/xxx/hyperion/build/_CPack_Packages/macOS/DragNDrop/Hyperion-2.0.13-macOS-arm64/ALL_IN_ONE/Hyperion.app/Contents/Frameworks/QtSerialPort.framework/Versions/5/QtSerialPort
Add Python 3.10 to bundle
PYTHON_MODULES_DIR: /opt/homebrew/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10
CPack: Create package
CPack: - package: /Users/xxx/hyperion/build/Hyperion-2.0.13-macOS-arm64.dmg generated.

I run Hyperion terminal and get this log:
macbookairm1@Macbooks-MacBook-Air ~ % /Users/xxx/Desktop/Hyperion.app/Contents/MacOS/Hyperion ; exit;
zsh: killed     /Users/xxx/Desktop/Hyperion.app/Contents/MacOS/Hyperion

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

System

Macbook Air M1 16G 256GB
Hyperion.ng with commit https://github.com/hyperion-project/hyperion.ng/commit/5dc696b8dc4f4e224dba9e713ccf31958e34de88

Unfortunately, we do not have any develops with MacOS hardware/knowledge.
Happy, if someone would like digging into it…

I just build the latest release and it works just fine.
Hyperion.zip

@Rastafabisch your zip won't work for me. I also compiled the latest version and it work.
hyperion-2.0.16-beta.1-arm64.zip

So looks like the issue can be closed?

no, because they just work with their mac , because their build dont include additional libraries to work in any mac os. you see, their build just 10,8mb, What do you think it has? @Lord-Grey

also successfully build it on my m1 mac. can we bring this to brew? Especially the grabbers "hyperion-[osx|qt]" and the hyperion-remote?

authors: DonaldTrump-2020 Lord-Grey Rastafabisch cpolzer fightingforyou46 imkebe


text:
examples: add an MPTCP using Socket2

Show how one can easily create an MPTCP capable webserver using Socket2.

MPTCP is a new protocol added in the Linux Kernel since 5.6. The goal of MPTCP is to support multiple path (cf: ADSL & LTE).
This allow for aggregation of links's bandwidth and for resiliency if any of the link fails.
Even if MPTCP is added in the Linux Kernel since 5.6, you may still need to enable it manually using:
sysctl net.mptcp.enabled=1

Signed-off-by: Martin Andre martin.andre@tessares.net

note: this PR will fail until socket2 make a new release with the new Protocol::MPTCP, but the content can still be reviewed
(see https://github.com/rust-lang/socket2/commit/4c436818cddec880c26c4e79aca7106ba88827ff)

Thanks for the PR!
I'm a little hesitant to add a server example using a slightly different IO type. Especially needing to have another dev dependency and check it in CI. If it's already clear you can pass any IO type, is there a benefit to having this example on its own?
Do we just need to make the docs clearer you can pass any async IO?

I understand your totally valid point :)
I just think it would be great to have an explicit example of how to create a MPTCP server using Hyper as it may not be clear to everyone how to do so. I'm not sure about the dependencies, Socket2 was already present and this is why I thaught it wouldn't be too much of an issue (but Socket2 isn't used anywhere so maybe it's just a leftover that need to be cleaned).
It's totally up to you to accept this PR or not.

source: gharchive/pull-request

authors: Martichou seanmonstar

repo: hyperium/hyper

license: mit

license_type: permissive

license_source: bigquery


text:
Temporarily allow duplicate crossbeam-queue crates

crossbeam-queue is currently brought in both by Rayon (up to date v0.2.0) and Hyper's dependency chain (0.1.x). Since Hyper is in the process of updating things, I proposed we temporarily allow this to pass CI and revisit it when there is a new release of Hyper or the relevant dependencies thereof.
This will fix the build of #151, #148 etc.

Thanks!

repo: hyperium/tonic

license: MIT

license_source: github-api


text:
New chain logos for V3

Added black and color SVGs of Scroll, Polygon zkEVM and Base chains.

Superseded by 3.1.4 update last week

authors: aroralanuk jmrossy

repo: hyperlane-xyz/hyperlane-widgets


text:
Naming conventions for structs that represent off-chain messages

Location
[client, wire]
Problem
Currently, multiple conventions are used for naming structs that represent off-chain messages.

Exported types and suffix Msg (see wire/controlmsgs.go): ShutdownMsg, PingMsg etc.,
Exported types with no suffix or prefix (see client/proposalmsgs.go): LedgerChannelProposal, LedgerChannelProposalAcc etc.,
Unexported types with no suffix or prefix (see client/updatemsgs.go): virtualChannelFundingProposal and virtualChannelSettlementProposal
Unexported types with prefix msg (see client/updatemsgs.go): msgChannelUpdate, msgChannelUpdateAcc

The has two issues:

For implementing the protobuff adapter, all the types that represent off-chain messages must be exported.
It would be better to use a uniform naming convention, to make it more readable.

Proposal
My proposal is to consistently use the first style (exported types with suffix Msg for all the types.

@matthiasgeihs

OK, could you make a list of which types this would affect and how you would rename them? And roughly maybe which other packages this would affect?

@matthiasgeihs  Here's a list of names:

S.No
Old name
Name name

1
PingMsg
PingMsg (u)

2
PongMsg
PongMsg (u)

3
ShutdownMsg
ShutdownMsg (u)

4
AuthResponseMsg
AuthResponseMsg (u)

5
LedgerChannelProposal
LedgerChannelProposalMsg

6
LedgerChannelProposalAcc
LedgerChannelProposalAccMsg

7
SubChannelProposal
SubChannelProposalMsg

8
SubChannelProposalAcc
SubChannelProposalAccMsg

9
VirtualChannelProposal
VirtualChannelProposalMsg

10
VirtualChannelProposalAcc
VirtualChannelProposalAccMsg

11
ChannelProposalRej
ChannelProposalRejMsg

12
msgChannelUpdate
ChannelUpdateMsg

13
msgChannelUpdateAcc
ChannelUpdateAccMsg

14
msgChannelUpdateRej
ChannelUpdateRejMsg

15
virtualChannelFundingProposal
VirtualChannelFundingProposalMsg

16
virtualChannelSettlementProposal
VirtualChannelSettlementProposalMsg

17
msgChannelSync
ChannelSyncMsg

OK, looks good. As I understand, exposing the internal message types is just an intermediate step, before we move the message types to the wire package. Not sure if we actually then could actually unexpose some of them again? If that is the case, you could add a comment to the types that indicates this.

Nope, I the messages will have to remain exported forever, even after moving them to wire package.
Because, the encoders/decoders for these messages will be implemented in a different packages (say perunio or protobuf).

source: gharchive/issue

authors: manoranjith matthiasgeihs

repo: hyperledger-labs/go-perun


text:
Return redis_events tests

Bring back the redis_events integration tests that use additional plugin after repairing the build backend config line that was missing.
Also: changed the integration image names so faber using the integration dockerfile with the additional plugin is different from alice using the normal dockerfile in the docker directory.
Also: removed the edit condition for the PR workflow. It's not needed.
Also: Had to add additional $ character on the docker compose startup command on my linux machine. Not sure why? The workflow machine works with or without it.

Looks good to me, wondering about @WadeBarnes 's comment regarding the duplicate Dockerfile for the integration tests, but might be for another issue.

I couldn't think of a way to install the basic_message_storage plugin without another dockerfile. I agree it would be nice not to have an additional (almost duplicate) file.

repo: hyperledger/aries-acapy-plugins


text:
Anoncreds Revoking one credential of many of the same type fails proof

With anoncreds specifically. If faber issues multiple credentials to alice of the same type and then revokes any of the credentials, the next proof request will fail verification.
Steps (using demo):

start faber ./run_demo run faber --wallet-type askar-anoncreds --revocation
start alice ./run_demo run alice --wallet-type askar-anoncreds
connect
issue 3 credentials to alice
revoke credential 2
request proof
result will be verified = false

Screencast from 2024-05-07 09:39:59 AM.webm

Sounds like this is either a bug in ACA-Py’s selection of a default credential to use when there are multiple — should choose the most recent non-revoked one, or in Alice picking the wrong one to use from a set.

That said, I don’t know how “default” is defined by ACA-Py.  Presumably it is the first in the array of candidate VCs that could be used to satisfy the request.

authors: jamshale swcurran

repo: hyperledger/aries-cloudagent-python


text:
Update Python image version to 3.9.18

Reduces the number of vulnerabilities in the image.

I noticed that Synk is saying this is making “no change detected” — as we are still using Bullseye Slim 3.9.16. Is there a Bullseye Slim 3.9.18 that we should also update to as part of this?

The Synk scan for the PR is not scanning the docker file.  I'm basing this change off the Synk scan that includes the dockerfiles.

Slim-bookworm, perhaps?

I recall that breaking things when we tried it, but I could try again.

Slim-bookworm, perhaps?

I recall that breaking things when we tried it, but I could try again.

I was mostly speculating on why the Snyk scan didn't report any changes. Your other comment explained that :slightly_smiling_face: Would be interesting to see if that change further resolved reported vulnerabilities and what breaks as a result but that doesn't seem like an urgent need right now.

Slim-bookworm, perhaps?

I recall that breaking things when we tried it, but I could try again.

On the surface building with slim-bookworm succeeds.  However I think we should introduce this through the nightly tests as part of the matrix first to make sure there are no surprises.  I'll enter a ticket for that.

authors: WadeBarnes dbluhm


text:
Use deferred connection strategy instead of lazy strategy for connecting to the ledger

Currently a connection to the ledger pool is only made when a request is sent to the ledger.
In some cases we could improve the time to process credential and proof related tasks by already making a connection to the ledger beforehand.
Previously we connected to the ledger on startup, which had significant impact on the startup time (see issue: https://github.com/hyperledger/aries-framework-javascript/issues/265).
We should find a middle ground, which in browser terms I think is often called deferred loading. Loading will not happen on startup, but after the agent has been initialized.
We should take into account https://github.com/hyperledger/aries-framework-javascript/issues/395. I'm not sure on the impact on data usage, and resources (especially on mobile devices), but automatically connecting to 10 pools after the agent has been started is also not a desired thing I guess

@JamesKEbert I tried to describe the issue as best as possible. Please edit as you see fit

Fixed

repo: hyperledger/aries-framework-javascript


text:
Various fixes and improvements

Fixes:

Improved formatting on various data summaries
Presentations are now auto loaded on entering verification section
Added status icons to credentials and presentations

Enabled removal of listings that were grouped by status. Now, each item is all in one list but status is indicated. This significantly simplified code in a few places.

Make sure select inputs have English "no data" warnings instead of Chinese
Add context menus (enables copy/paste through right clicks)
Disable presentation proposal (which is not currently functional)
Visual improvements for Agent List window
Use enter key for triggering form actions where it makes sense

@PeterStrob Your review would be appreciated here (couldn't explicitly request due to github access issues)

Small issues with the display bugging out, though otherwise the changes look good!

authors: PeterStrob dbluhm

repo: hyperledger/aries-toolbox


text:
Feature: RPC and WS Engine API on unified port

Description
For drop-in replacement of Geth, it'd be useful if both the RPC and WS endpoints for the engine API were on the same port, namely 8551.
Currently RPC is on 8550 and WS on 8551:
execution_1             | 2022-03-21 19:40:11.328+00:00 | vert.x-eventloop-thread-1 | INFO  | JsonRpcHttpService | JSON-RPC service started and listening on 0.0.0.0:8550
execution_1             | 2022-03-21 19:40:11.330+00:00 | main | INFO  | WebSocketService | Starting Websocket service on 0.0.0.0:8546
execution_1             | 2022-03-21 19:40:11.337+00:00 | vert.x-eventloop-thread-1 | INFO  | WebSocketService | Websocket service started and listening on 0.0.0.0:8546
execution_1             | 2022-03-21 19:40:11.338+00:00 | main | INFO  | WebSocketService | Starting Websocket service on 0.0.0.0:8551
execution_1             | 2022-03-21 19:40:11.340+00:00 | vert.x-eventloop-thread-1 | INFO  | WebSocketService | Websocket service started and listening on 0.0.0.0:8551

Geth, Erigon and Nethermind have a combined RPC/WS endpoint defaulting to 8551.

I could work around it with --engine-rpc-http-port=8551 --engine-rpc-ws-port=8551 - any concerns about doing so?

How does this work? (I think using just --engine-rpc-http-port=8551 is enough if you want them to be on the same port) but wouldn't this create issues? I've seen error responses like this
2022-03-21 16:04:55.378 ERROR - Execution Client is offline
org.web3j.protocol.exceptions.ClientConnectionException: Invalid response received: 400; Websocket endpoint can't handle HTTP requests

So the "correct" way of doing WS is to have a lone, single port, and then either you do get Connection: Upgrade, which means it's now a Websocket connection, or you don't, in which case it remains an RPC connection.

authors: frankisawesome yorickdowne

repo: hyperledger/besu


text:
Exit after import

In https://github.com/ethereum/hive/pull/261 , I implemented hive block import for Besu.
However, when I do the import command (which fails, btw, but I don't know if it matters for this ticket), besu doesn't exit after the import is done. Is that a known/desired feature? Can you change it, so that besu exits after the block(s) have been imported?

Hey @holiman,
We'll be looking into this in the next few weeks.
As for the failures, do you have a link to some of the failed imports for Besu?
Thanks

This is a sync - test: https://hivetests.ethdevops.io/?suite=1587974674-63bde328c122e5fc52af6b280106531c.json
The sync server tries to import 10 blocks, and the tests then proceed trying to sync other clients from that source.
Here's the log from when Besu is the sync source: https://hivetests.ethdevops.io/viewer.html?file=results/besu_latest/client-bb212852.log#L29
And here, the log shows that Besu did exit properly after the import, and we started a second run with it in normal mode:
https://hivetests.ethdevops.io/viewer.html?file=results/besu_latest/client-bb212852.log#L34
So this ticket seems to be in error!

( I might have mixed up besu and nethermind, and should have filed the exit-after-import ticket with them instead. Sorry!)

Thanks for the info!

authors: holiman timbeiko


text:
Update holesky with fixed extraData, genesis time, shanghaiTime

Incorporates https://github.com/eth-clients/holesky/pull/73
and also @fab-10's changes from https://github.com/eth-clients/holesky/pull/72

@fab-10 I have some doubt about the removal of cancunTime (which is currently breaking the tests).
Eth-clients genesis didn't have it but geth did: https://github.com/ethereum/go-ethereum/blob/90d5bd85bcf2919ac2735a47fde675213348a0a6/params/config.go#L84
Nethermind didn't: https://github.com/NethermindEth/nethermind/blob/8ce10d324c05a44dc1fb9e07e6b8618350addac9/src/Nethermind/Nethermind.Specs/HoleskySpecProvider.cs#L15
I think it's probably fine either way...just not sure if "fork next" having a difference value affects peering

@fab-10 I have some doubt about the removal of cancunTime (which is currently breaking the tests).
Eth-clients genesis didn't have it but geth did: https://github.com/ethereum/go-ethereum/blob/90d5bd85bcf2919ac2735a47fde675213348a0a6/params/config.go#L84
Nethermind didn't: https://github.com/NethermindEth/nethermind/blob/8ce10d324c05a44dc1fb9e07e6b8618350addac9/src/Nethermind/Nethermind.Specs/HoleskySpecProvider.cs#L15
I think it's probably fine either way...just not 100% sure if "fork next" having a different value affects peering

Ok, now I remember why I added it in the first place, so should I readd it or have you found a way to fix the tests?

Ok, now I remember why I added it in the first place, so should I readd it or have you found a way to fix the tests?

@fab-10 I fixed the tests and confirmed with Stefan that a future cancunTime shouldn't affect peering so think we're good.
Would still like to confirm with other EL clients if the forkId is the expected value before we re-launch

It looks like the missing brace would have parsed the remaining accounts as storage fields? I presume this was possible because of a json parsing policy that ignores missing fields, otherwise we should have thrown when "balance":xx wasn't part of the json schema for storage fields.
can we add stricter json parsing for storage fields and/or test coverage?

Definitely a good idea to do that. Happy for that to be in another PR to not hold the release for the Holesky relaunch. Even better would be to be compatible with the same genesis config that other clients use.

Created this issue for tightening up the parsing https://github.com/hyperledger/besu/issues/5900

authors: fab-10 jframe macfarla siladu


text:
[question] chain connection error

[ ] burrow version (docker image tag or branch if built from source):- 0.21.0
[ ] monax version (if applicable)
[ ] go version (if applicable)g 1.11fi
[ ] docker version (if applicable) 18.06.1-ce
[ ] operating system details (osx/windows/linux) Ubuntu 16.04 64-bit
[ ] burrow deploy --address=F71831847564B7008AD30DD56336D9C42787CF63
[ ] could not connect to server
gave error as following:
rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:10997: connect: connection refused"

@anume1234 can you give us more context on what the issue is here? did you have a chain running before doing the burrow deploy ?

am closing this issue. feel free to reopen if there is an actual problem here or visit with the community int he #burrow room at chat.hyperledger.org

repo: hyperledger/burrow


text:
feat(connector-chia): add plugin implementation

Summary
Develop a Cactus Chia connector plugin + test infrastructure (container images, container manager class, etc.) from scratch.
Include end to end test cases powered by Jest and the said testing infrastructure that prove that the connector is working as intended with a locally simulated Chia network.
You will be creating a new package in the Cactus monorepo from scratch under the packages/cactus-plugin-ledger-connector-chia/ path.
Acceptance Criteria

Chia All-In-One image is created (tools/docker/chia-all-in-one/Dockerfile) which also has a README.md next to it explaining the building and running of the image and it's containers (tools/docker/chia-all-in-one/README.md)
1.1 Container health checks must be be operational and reliable for the image meaning that the HEALTHCHECK keyword needs to be used within the Dockerfile to define when the container has finished launching (e.g. it must only pass once the ledger is up and running, ready to accept transactions)
The AIO image mentioned above is published to the official GitHub Container Registry under the fully qualified image tag of ghcr.io/hyperledger/cactus-chia-all-in-one:2022-MM-DD-$GIT_SHORT_HASH for example ghcr.io/hyperledger/cactus-chia-all-in-one:2021-01-08-7a055c3 (do not use the exact example tag of course)
A packages/cactus-test-tooling/src/main/typescript/chia/chia-test-ledger.ts code file is added with a ChiaTestLedger class in it that is responsible for providing a start() method that takes care of launching
A packages/cactus-plugin-ledger-connector-chia/src/main/typescript/plugin-ledger-connector-chia.ts file is added with a PluginLedgerConnectorChia class in it. This class uses the chia-js npm package under the hood to implement the connector's usual methods.
The functionality of the connector is covered by the end to end tests mentioned earlier. The tests must be using the AIO image to simulate a production Chia ledger with reasonable accuracy.
Web services are implemented so that the connector's functionality can be exposed via the network when the plugin is loaded into the Cactus API server.
Tests are also covering (e.g. using) the generated API client class (for which you'll need to define the necessary request and response types and endpoints in a file at packages/cactus-plugin-ledger-connector-chia/src/main/json/openapi.json file.

Links, Tips, Useful Information

Most important tip: You should study the code of other - already working - connector plugins to see how they implement web services for example. A lot of the code is just boilerplate around the actual logic that translates Cactus API requests into RPC calls to the Chia ledger.

1 .There is a Typescript library facilitating RPC calls to Chia chains: https://www.npmjs.com/package/chia-js The latter should be used for the internal workings of the connector class to keep things simple (e.g. do not go down the rabbit hole of trying to use bindings from another language via IPC or other complex workarounds).
2. Start with the connector plugin package's implementation by simply copy pasting one of the existing connectors and then find & replace the ledger name within that folder accordingly ($COPIED_LEDGER_NAME => chia)
3. Double check that in packages/cactus-plugin-ledger-connector-chia/package.json the dependency versions to other Cactus packages are up to date and that the name of the package itself is also up to date.

I am interested to work on this project.

Hi @petermetz I am interested to work on this Cactus Chia connector plugin project.

Hey @petermetz
I'm Dipanshu.
I applied  for this project through LFX mentorship.
I'm excited.
I'm planning to utilize the meantime to understand the workflows of our community.
I'll also try to better understand the enhancements that we'll be making through this project.
Since I'm new to this project and open source
I was wondering if you could help me with some specific references to get started
I'd be really help me a lot.

Greetings Mentor @petermetz ,
I'm looking forward to working with you. I already sent my application through the LFX mentorships. Here's my email mandalpurushottam66@gmail.com
Thankyou
Purushottam @oyepuru

Hi @petermetz, I am really interested in working on this issue. And I just applied on the LFX mentorships.
Thank you for your consideration.
Xinyu
xzhang0980@gmail.com

Hi @petermetz
While building the plugin and the pipeline, what are the essential tradeoffs we should keep in mind, and how can I measure the performance metric if it is working?

Is there any communication channel apart from Github for this project?

Found the discord link for the Hyperledger Foundation: https://discord.gg/invite/hyperledger

yes @RajGM you may clarify your doubt over there.

Hi, @petermetz
What is the base image we are going to use for the chai connector?
Any particular port we want to expose services with?
Are any particular node modules recommended to use apart from chai-js?
Any particular chai test pattern?

https://www.chia.net/
https://registry.hub.docker.com/r/chianetwork/chia-docker/tags

Jumping to step 3 as https://github.com/Chia-Network/chia-docker resolves steps 1-2

Looking at #1636 @petermetz

authors: OyePuru RajGM i-dipanshu legendarykamal petermetz xyzhang7

repo: hyperledger/cactus


text:
feat: invent ledger-agnostic SQL/DSL

Is your feature request related to a problem? Please describe.
This is a moonshot feature not something that we have a clear idea on how to implement or even if it should be implemented (could be a massive undertaking for no actual gain in the end, hence the moonshot label above).
Describe the solution you'd like
I want to be able to say something like
Use case: End users Lennon and Skyler perform an atomic swap between their wallets across ledgers A and B, trading (some arbitrary) pair of coins X and Y where the exchange rate is (conveniently) 1 exactly.

The syntax is just some pseudo code I made up on the fly, but you can probably see that it is basically the classical SQL syntax.

The example is a classical one from traditional RDBMS' textbooks where they teach you how important the all-or-nothing semantics of atomic transactions through an example of balance transfers in the classical financial universe.

BEGIN TRANSACTION;

# Reduce Skyler's X balance by 1000
UPDATE  "Ledger_A"."COIN_X_BALANCES"
  SET BALANCE = BALANCE - 1000
  WHERE ACCOUNT_ID = "SKYLER_ACCOUNT_ID"

# Increase Lennon's X balance by 1000
UPDATE  "Ledger_A"."COIN_X_BALANCES"
  SET BALANCE = BALANCE + 1000
  WHERE ACCOUNT_ID = "LENNON_ACCOUNT_ID"

# Reduce Lennon's Y balance by 1000
UPDATE  "Ledger_B"."COIN_Y_BALANCES"
  SET BALANCE = BALANCE - 1000
  WHERE ACCOUNT_ID = "LENNON_ACCOUNT_ID"

# Increase Skyler's Y balance by 1000
UPDATE  "Ledger_B"."COIN_Y_BALANCES"
  SET BALANCE = BALANCE + 1000
  WHERE ACCOUNT_ID = "SKYLER_ACCOUNT_ID"

COMMIT TRANSACTION;

Describe alternatives you've considered
Considered doing with without SQL/DSL and we likely will end up doing that first as well since doing what's described in this issue as a moonshot due to it's likely very high difficulty as we'd have to implement our own SQL parser, query planner, etc, not even mentioning the fact that there will be compatibility issues among the different ledgers (which is where most ORM libraries fall short as they try to provide a sensible common interface for databases that are sometimes conceptually different from each other)
Additional context
https://wiki.hyperledger.org/display/cactus/2020-11-12+Meeting+notes?focusedTaskId=1
cc: @RafaelAPB @takeutak @sfuji822 @jonathan-m-hamilton

A cool paper where something similar was implemented (complexity/effort required is off the charts though)
https://arxiv.org/abs/1908.09343

One more paper defining such interface:
https://www.iaas.uni-stuttgart.de/publications/Falazi2020_SCIP-Smart-Contract-Invocation-Protocol-SCIP-A-Protocol-for-the-Uniform-Integration-of-Heterogeneous-Blockchain-Smart-Contracts.pdf
Canton does have a somehow similar scheme, via DAML - https://www.canton.io/publications/canton-whitepaper.pdf
I believe this ledger-agnostic SQL-based DSL is useful when, for example, one needs a provably-secure Cactus deployment. I would say that some solutions would need this, while others would benefit from a greater degree of flexibility.

@RafaelAPB Agreed, 100% and thanks for adding more, interesting items to my reading list, I'll skim these ;-)

authors: RafaelAPB petermetz


text:
CI to run Eslint as part of the build job

The CI script should invoke npm run lint as part of the build job.

Dependent on #43 being closed first.

Fixed by #123


text:
Build adjustments

Made it build properly
Updated the readme for secp256k1 dependency
Rationalized some tests

LGTM. @rfajta - The Linux Foundation requires a sign off on PRs.
https://github.com/hyperledger/fabric/blob/master/CONTRIBUTING.md#legal-stuff
Please add when you have a chance.

authors: rfajta srderson

repo: hyperledger/fabric-api


text:
Channel created fail

Hello, I was following the tutorial of the Fabric Python SDK.
First I set up the network with the commands given.
export HLF_VERSION=1.4.0
docker pull hyperledger/fabric-peer:${HLF_VERSION} \
    && docker pull hyperledger/fabric-orderer:${HLF_VERSION} \
    && docker pull hyperledger/fabric-ca:${HLF_VERSION} \
    && docker pull hyperledger/fabric-ccenv:${HLF_VERSION}
docker-compose -f test/fixtures/docker-compose-2orgs-4peers-tls.yaml up

Then I tried to create a channel and join a peer like the following.
async def async_main():
    cli = Client(net_profile=CONNECTION_PROFILE_PATH)

    print(cli.organizations) # orgs in the network
    print(cli.peers) # peers in the network
    print(cli.orderers) # orderers in the network
    print(cli.CAs) # ca nodes in the network

    # get the admin user from local path
    org1_admin = cli.get_user(org_name='org1.example.com', name='Admin')

    # Create a New Channel, the response should be true if succeed
    response = await cli.channel_create(
        orderer='orderer.example.com',
        channel_name='businesschannel',
        requestor=org1_admin,
        config_yaml=CONFIG_YAML_PATH,
        channel_profile='TwoOrgsChannel'
    )
    if response:
        print("Create channel successful")
    else:
        print("Create channel failed")
        print(response)
        exit(-1)

    # Join Peers into Channel, the response should be true if succeed
    response = await cli.channel_join(
        requestor=org1_admin,
        channel_name='businesschannel',
        peers=['peer0.org1.example.com', 'peer1.org1.example.com'],
        orderer='orderer.example.com')
    if response:
        print("Join channel successful")
    else:
        print("Join channel failed")
        exit(-1)

def main():
    loop = asyncio.get_event_loop()
    loop.run_until_complete(async_main())

if __name__ == '__main__':
    main()

But the response reported back is False. Really not sure about the cause and how to debug on the issue. Some help might be needed on how to correctly use the client to interact with the Fabric network.

Do you have configtxgen binaries in your PATH?

Thank you for timely reply.
I guess no for the moment. Didn't see that in the instruction, I thought the docker images are all that are required.  Is there any suggested way to do that? Or should I install fabric and include all its binaries in the PATH?

you need to include binaries in the PATH. For example, export PATH=$PATH:$PWD/fabric-bin at the fabric-sdk-py directory

Yes, I found the NOTE now. And your suggestion works for me. Thanks for helping.

great to hear, I am closing the issue now, let reopen or create a new issue if there are other problems. Thanks.

@znss1989  Dear Author ,i also have this problem when i try to run a test in fabric-sdk-py directory:

i have join the binaries in the PATH , bashrc:
how can i do,thank you!

authors: Creazy-MR dexhunter znss1989

repo: hyperledger/fabric-sdk-py


text:
[suggestion] Enhance configuration parsing with precise field locations

Feature request
I would like to get meaningful errors when I pass configuration (via JSON, ENV vars or both) to Iroha 2.
Consider the following cases that currently occur:

I have passed PUBLIC_KEY and PRIVATE_KEY env vars, and I get an error:

Please add PUBLIC_KEY and PRIVATE_KEY to the configuration.

It turned out that yes, in JSON configuration I could provide them as top-level fields with these names, but when it comes to ENV, I should specify them as IROHA_PUBLIC_KEY and IROHA_PRIVATE_KEY.
By the way: yes, it prints exactly "PUBLIC_KEY AND PRIVATE_KEY", not "PUBLIC_KEY and PRIVATE_KEY".
The descriptive error would be:

Please add PUBLIC_KEY (env: IROHA_PUBLIC_KEY) and PRIVATE_KEY (env: IROHA_PRIVATE_KEY) fields to the configuration.

I forgot to specify the P2P addr:

Please add p2p_addr to the configuration.

The descriptive error would be:

Please add TORII.P2P_ADDR (env: TORII_P2P_ADDR) to the configuration.

Thoughts on implementation
Introduce a data structure for configuration parameter location:
struct Location {
  env_var: &'static str,
  serde: &'static str
}

Then refactor the configuration proc macros so they can generate all of the locations in order to use them statically.
Sample macro usage:
#[derive(Proxy)]
#[proxy(locations = "config_locations_private", env_prefix = "IROHA_")]
struct Iroha {
  public_key: PublicKey,
  sumeragi: Sumeragi
}

#[derive(Proxy)]
#[proxy(env_prefix = "SUMERAGI_")]
struct Sumeragi {
  p2p_addr: String
}

Generated modules
// by proc macro
mod config_locations_private {
  use crate::Location;

  pub const public_key: Location = Location {
    env_var: "IROHA_PUBLIC_KEY",
    serde: "PUBLIC_KEY"
  }

  pub mod sumeragi {
    pub const p2p_addr: Location = Location {
      env_var: "SUMERAGI.P2P_ADDR",
      serde: "SUMERAGI_P2P_ADDR"
    }
  }
}

// visibility control, if needed
pub mod config_locations {
  pub use super::config_locations_private;
}

Then, this code could be used in other parts to throw descriptive errors, like that:
if let (Some(public_key), Some(private_key)) = (&self.public_key, &self.private_key) {
  // ...
} else {
  return Err(ConfigError::MissingParameters {
    locations: vec![config_locations::public_key, config_locations::private_key]
  });
}

Motivation
Iroha will be even more useful if it throws descriptive and helpful errors when misconfiguration happens.
Also, it will be useful for #2373 - the tool will be able to define ENV variables in a docker-compose configuration with static check.
Who can help?
No response

Related:

#3031 (#3321)

serde_path_to_error might be used to get additional info about the location during deserialisation.

we don't want source code locations in user facing errors

It's not about source code locations. It is about locations of where the config parameter was read, like "oh, we got this torii.address from file iroha.toml btw".
This is being addressed by #4456.

repo: hyperledger/iroha


text:
Register<AssetDefinition> permissions

ATM, there are no permissions for registering asset definitions in the default validator, i.e. all Register<AssetDefinition> operations are never denied. For example it is allowed that alice@wonderland registers a new asset definition xor#genesis. Should we disallow alice@wonderland from accessing other domains by default and introduce some tokens to grant such a privilege?

we should only allow domain owner and the account that owns a permission token to register AssetDefinition in another Domain


text:
Update MAINTAINERS.md: Move people to Emeritus

mac-arrap's last activity was 2022-04-29

I think it makes sense to move Cam to the emeritus list.
@appetrosyan is it likely that @Erigara will be continuing as a maintainer of Ursa?

Yes, as long as we’re developing Iroha

@brentzundel @appetrosyan updated

We should also remove others but that can be a separate PR.

authors: appetrosyan brentzundel mikelodder7 ryjones

repo: hyperledger/ursa


text:
Expose bitfield

This adds two optional fields bitfield and length to the has method request. If set, the response includes a run-length encoded bitfield of the downloaded blocks from seq for length.
On the client side, a new getBitfield method is added. It resolves to the decoded bitfield, wrapped in a  bitfield instance.
This, together with #5, solves #2 and should allow indexers to work reliably and efficiently on sparsely synced hypercores.

Whats your usecase for getting the bitfields out? Since this is adding the semver'ed api surface, we're per default a little conservative about adding apis

I have an indexer that wants to index all downloaded blocks for a list of (sparse) feeds.Therefore, it tracks which key-seq pairs it has indexed already. With hyperspace, I cannot ensure that there's no downloads happening while the indexer is not running. So, to check for that, without this patch I'd have to to an async has request for each seq of a potentially long list of long feeds. With this patch, it's just one async request per feed, and then the bitfield comparison can happen in a regular sync loop.

@mafintosh if a new method getBitfield sounds better to you I'm fine with that as well. I thought it fitted nicely with the has method (to keep API surface smaller) but don't really mind.

authors: Frando mafintosh

repo: hyperspace-org/hyperspace


text:
Create operator helm chart

Hello @mrueg

Used helmify

repo: hyperspike/valkey-operator


text:
Capture config per framework/instrumentation

The capture config should be configurable per framework/instrumentation but also globally (
https://github.com/hypertrace/agent-config/blob/eb054cd09abbc30e8d196618ca8526999019a5d1/config.proto#L37).
For instance I want to disable body capture for servlet but still have it enabled for okhttp client.

While I see the consequences of the use case legit, I'd really like to run some discussion around this as I believe people is not too interested on enable/disable per library but probably per use case (e.g. client, server, remote service, etc). Any thoughts on this @davexroth @mohit-a21 ?

The use case I had in mind was that particular body instrumentation can be problematic so it could be disabled without affecting others.

Exactly, it will mostly be something used by us in the field if a particular framework causes issues in a customers application.
But as it will be more of an internal config, we may be able to have a different config block such as message Frameworks { map of framework name to options }

authors: davexroth jcchavezs pavolloffay

repo: hypertrace/agent-config


text:
[Report] HyperCRX Biweekly Report : 2024-10-23

Description
📈 User Growth （ as of October 22, 2024 ）

Google Chrome Users : The number of HyperCRX users on Google Chrome reached 1,096.
Microsoft Edge Users :  The number of users on Microsoft Edge is 1127.

✍ Update Summary

Version Update : HyperCRX plugin updated to version 1.9.12.
Bugs Fixed ：

Fixed the issue where the tooltip failed to display when toggling between the starred and unstarred states in the repository.Thx @Xsy41

https://github.com/hypertrons/hypertrons-crx/pull/877

Features Improved ：

We have updated the labels UI of the warehouse to make it more aesthetically pleasing and streamlined. 🎉 Thx @frank-zsy @tyn1998 @wangyantong2000 @Xsy41

https://github.com/hypertrons/hypertrons-crx/pull/880
https://github.com/hypertrons/hypertrons-crx/pull/886

Updated the linking and embedding method for osgraph icons. 🎉 Thx @frank-zsy @wangyantong2000 @Xsy41

https://github.com/hypertrons/hypertrons-crx/pull/888
https://github.com/hypertrons/hypertrons-crx/pull/890

https://github.com/hypertrons/hypertrons-crx/pull/892 Thx @wangyantong2000
https://github.com/hypertrons/hypertrons-crx/pull/893 Thx @wangyantong2000
https://github.com/hypertrons/hypertrons-crx/pull/895 Thx @wangyantong2000

I think the periodic report of the project should not only list and summarize some data. We can add some project phase plans, as well as some personal thoughts and ideas (if any). Meanwhile, anyone is welcome to share their ideas, thoughts, suggestions, or anything else you want to say under this report.
At present, HyperCRX's short-term goals are to complete the complete launch of FastPR, the rapid refactoring and functional improvement of OSS-GPT, and the preparation for adaptation to the Gitee platform.
Expected to complete the launch of the new feature FastPR in November.

At present, I am trying to fix the #773 , welcome to discuss together.

repo: hypertrons/hypertrons-crx


text:
enable deferred button for archived assignments

see frontend story: https://github.com/hypha-dao/dho-web-client/issues/1489

@Gerard097 is this fixed on the backend ?

repo: hypha-dao/dao-contracts


text:
Segmentation Fault on Startup

STEPS TO REPRODUCE
Login from display manager.
EXPECTED OUTCOME
For the past few days of using Hyprland I have been able to login normally.
OUTCOME:
A black screen appears (the normal Hyprland startup since I have the logo and splash disabled), then returns to the display manager. Crash report indicates this is segmentation fault.
ATTEMPTED FIXES/NOTES
Did obvious things like rebooting and pacman -Syu.
I have tried reinstalling Hyprland, launching with a default config file and downgrading to previous installed version.
Login through i3 works normally.
I might be missing something obvious (I hope not). I'm fairly new to Linux and only started using Hyprland a few days ago.
System is a Dell XPS 13 9300 with Intel i5-1035G1 CPU, integrated graphics.
LOGS/CONFIG
crashreport.txt
hyprland.txt
coredump.txt

ca you git bisect if this is a regression?

I don't have a known good version, when I reverted Hyprland, the issue persisted. That makes me think it's a conflict somewhere but the logs don't give me much direction to investigate that.

patch.txt
try this

I'm sorry but I can't figure out how to apply this patch.

git apply

I'm getting:
> error: src/managers/AnimationManager.cpp: No such file or directory
> error: subprojects/wlroots: No such file or directory

I've also tried uninstalling the packages that had been installed since Hyprland, but that didn't affect the outcome.

you probably are in the wrong dir, make sure you're in Hyprland named dir

Same issue in /usr/include/hyprland and /usr/share/hyprland.

Thanks for you patience. When I run Hyprland in i3 it launches. Sorry I didn't check that earlier. When I do that I get:
00:00:00.051 [types/wlr_drm_lease_v1.c:715] No DRM backend supplied, failed to create wlr_drm_lease_v1_manager 00:00:00.051 [backend/headless/backend.c:68] Creating headless backend 00:00:00.062 [backend/x11/backend.c:164] Starting X11 backend 00:00:00.068 [backend/headless/backend.c:16] Starting headless backend [196 12:53:13.002070] [glfw error 65544]: process_desktop_settings: failed with error: [org.freedesktop.DBus.Error.ServiceUnknown] The name org.freedesktop.portal.Desktop was not provided by any .service files
I can't find the Hyprland directory for some reason. When I find from root, it only shows me directories in usr/include and usr/share.

I can launch normally into hyprland again. I have no idea what changed. The only thing I did between this reset and the last was run hyprland from terminal in i3. Thanks for your help and patience. I'll mark as closed.

I'm still getting this issue inconsistently whenever I restart hyprland. Still aren't closer to pinpointing a solution.

patch.txt
try this patch

Do you know where the pacman default Hyprland dir is?

you'll have to build manually from git

Ah alright, I'll get back to you when I've tried that.

I'm on the latest commit (which at this point is 1ec0b7b59a84a07f97c3ebee9f6694bc4a1b1dcd) and I'm also experiencing this issue with SDDM. I did a git bisect and found this wlroots update  (8c9e2e1ff1d22f7954f5e75194e9f77cacffa3f6) to be the problem. I can't apply the patches because I have no idea what commit this issue was opened on, but this info might be useful regardless.

I have this problem on 0.28 and there is an issue cloning the  wlroots subrepo via yay
The git server is returning a 503.

I have this problem on 0.28 (pacman latest binary) and there is an issue cloning the wlroots subrepo via yay
``

I do not think it is appropriate to ask irrelevant questions in GitHub issues. If you come across a problem, please post your inquiry in the GitHub discussion or on Discord.
gitlab.freedesktop.org is currently unavailable from as the registry data is being migrated from Google Cloud to a self-hosted solution. They estimate it will be between 8 and 12 UTC. However, they seem to have run into some sort of problem and have extended the downtime as it is now 17 UTC.

@memchr I'm sorry but where exactly did I ask a question? I was reporting an issue that I was encountering while trying to install this library.
Last time I checked - that is what github issues is for.

@memchr I'm sorry but where exactly did I ask a question? I was reporting an issue that I was encountering while trying to install this package.
Last time I checked - that is what github issues is for.

Could you please double check the current thread you are posting to? #2709 is Segmentation Fault on Startup. I mean you no offense, but your question is not related to this issue in anyway. If you wish to report an bug, please create a new issue thread rather than randomly commenting on an existing unrelated issue.

@memchr The first thing I said in my comment is that I am encountering this issue on 0.28 of Hyprland
My issue is almost word-for-word what OP said. So I thought I would just give this thread some traction.
Apologies if this is not allowed

@memchr The first thing I said in my comment is that I am encountering this issue on 0.28 of Hyprland

I have this problem on 0.28 (pacman latest binary)

My issue is almost word-for-word what OP said. So I thought I would just give this thread some traction.
Apologies if this is not allowed

No, it is not my position to say that it is not allowed, I am just recommending that you create a new issue thread instead of posting to a completely unrelated existing issue, thus confusing people tracking this bug.
Please do a double check of the original post:

STEPS TO REPRODUCE Login from display manager.
EXPECTED OUTCOME For the past few days of using Hyprland I have been able to login normally.
OUTCOME: A black screen appears (the normal Hyprland startup since I have the logo and splash disabled), then returns to the display manager. Crash report indicates this is segmentation fault.
ATTEMPTED FIXES/NOTES Did obvious things like rebooting and pacman -Syu. I have tried reinstalling Hyprland, launching with a default config file and downgrading to previous installed version. Login through i3 works normally. I might be missing something obvious (I hope not). I'm fairly new to Linux and only started using Hyprland a few days ago. System is a Dell XPS 13 9300 with Intel i5-1035G1 CPU, integrated graphics.

Sorry if you are confused by the github's user interface, but the OP's problem is clearly completely unrelated to yours.
Please do not reply if possible.

@memchr just to clarify, as I see now why you might think I am posting in an unrelated thread,
I am encountering this issue that OP is encountering, when trying to boot Hyprland from sddm
Aug 27 12:16:40 danarch sddm[744]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
Aug 27 12:16:40 danarch sddm[744]: Auth: sddm-helper (--socket /tmp/sddm-auth-0197350e-a93c-41c6-803b-7ef0c33313e8 --id 1 --start /usr/local/bin/wrappedhl --user dan) crashed (exit code 1)
Aug 27 12:16:40 danarch sddm[744]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"

Aside from that my hyprland crash report is identical to OP's as I already stated, as is my coredump after the crash.
The issue I reported about freedesktop was just an aside.
Let's not be rude please

I have eventually isolated the issue. The seg fault only occurs when my laptop is charging. I have no clue what the connection is, but it's consistently reproducible.

@99MatthewBarton are you still using hyprland?
have you installed the latest bios and firmware files for your system??
have you tried to build the latest version?
in AUR you have hyprland-git package

@romanstingler yes I'm still using hyprland. I was on hyprland-git for a while but I moved back to the stable branch. The issue still persists. It is definitely caused by having the charging cable plugged in so it is easy to bypass.

authors: 99MatthewBarton MightyPlaza dan-cooke memchr pranavrao145 romanstingler vaxerski

repo: hyprwm/Hyprland


text:
windowrule matching but not applied

Hyprland Version
0.30.0
Bug or Regression?
Bug
Description
Having setup the following window rules to match Firefox (and Thunderbird) Popups[1]
Which worked fine until some weeks ago. Now it sometimes isn't floating anymore (therefor also no pin, move)
Logs for one example[2]
But sometimes it does work[3]
Looks to me like if it's spawned with title: "" it workes, if it changes to it, it doesn't.
How to reproduce
Firefox popup via e.g. Simple Tab Groups and move tab to other group
Crash reports, logs, images, videos
[1]
windowrulev2 = float,class:^(firefox)$,title:^$
windowrulev2 = opacity 1 0.25, class:^(firefox)$,title:^$
windowrulev2 = move 0% 0%,class:^(firefox)$,title:^$
windowrulev2 = noinitialfocus,class:^(firefox)$,title:^$
windowrulev2 = pin,class:^(firefox)$,title:^$

[2]
➜ ~ rg 55db4f9609e0 /tmp/hypr/1b48642fd15c433c53876f1b933dcd46265caf8f_1699171536/hyprland.log
58438:[LOG] Registered signal for owner 55db4f9609e0: 55db4f93f920 -> 55db4f960a48 (owner: XDG Window)
58439:[LOG] Registered signal for owner 55db4f9609e0: 55db4f93ae80 -> 55db4f960b18 (owner: XDG Window)
58440:[LOG] Registered signal for owner 55db4f9609e0: 55db4f943f20 -> 55db4f960ff8 (owner: Toplevel)
58441:[LOG] Registered signal for owner 55db4f9609e0: 55db4f943f30 -> 55db4f961060 (owner: Toplevel)
58442:[LOG] Registered signal for owner 55db4f9609e0: 55db4f943f40 -> 55db4f960f90 (owner: Toplevel)
58445:[LOG] Registered signal for owner 55db4f9609e0: 55db4f93f930 -> 55db4f960ab0 (owner: CWindow)
58448:[LOG] Set keyboard focus to surface 55db4f93f640, with [Window 55db4f9609e0: title: "Firefox"]
58450:[LOG] Registered signal for owner 55db4f9609e0: 55db4f93f910 -> 55db4f9609e0 (owner: XDG Window Late)
58451:[LOG] Registered signal for owner 55db4f9609e0: 55db4f95aab0 -> 55db4f960b80 (owner: XDG Window Late)
58452:[LOG] Registered signal for owner 55db4f9609e0: 55db4f93aea0 -> 55db4f960cb8 (owner: XDG Window Late)
58453:[LOG] Registered signal for owner 55db4f9609e0: 55db4f95aa40 -> 55db4f960df0 (owner: XDG Window Late)
58454:[LOG] Registered signal for owner 55db4f9609e0: 55db4f95aa60 -> 55db4f960d88 (owner: XDG Window Late)
58455:[LOG] Registered signal for owner 55db4f9609e0: 55db4f95aa70 -> 55db4f960d20 (owner: XDG Window Late)
58456:[LOG] Registered signal for owner 55db4f9609e0: 55db4f95aa80 -> 55db4f960e58 (owner: XDG Window Late)
58457:[LOG] Registered signal for owner 55db4f9609e0: 55db4f95aa50 -> 55db4f960c50 (owner: XDG Window Late)
58465:[LOG] Creating a surfaceTree Root! [Window 55db4f9609e0: title: "Firefox"]
58468:[LOG] Window rule float -> class:^(firefox)$,title:^$ matched [Window 55db4f9609e0: title: ""]
58469:[LOG] Window rule opacity 1 0.25 ->  class:^(firefox)$,title:^$ matched [Window 55db4f9609e0: title: ""]
58470:[LOG] Window rule move 0% 0% -> class:^(firefox)$,title:^$ matched [Window 55db4f9609e0: title: ""]
58471:[LOG] Window rule noinitialfocus -> class:^(firefox)$,title:^$ matched [Window 55db4f9609e0: title: ""]
58472:[LOG] Window rule pin -> class:^(firefox)$,title:^$ matched [Window 55db4f9609e0: title: ""]
58473:[LOG] Window 55db4f9609e0 set title to
58480:[LOG] Creating a subsurface Node! [Window 55db4f9609e0: title: ""]
58484:[LOG] [Window 55db4f9609e0: title: "", class: firefox] unmapped
58496:[LOG] Destroying the SubSurface tree of unmapped window [Window 55db4f9609e0: title: ""]
58516:[LOG] [Window 55db4f9609e0: title: "", class: ] destroyed, queueing.

hyprctl clients
Window 55db4f9609e0 -> :
        mapped: 1
        hidden: 0
        at: 12,727
        size: 1261,701
        workspace: 2 (2)
        floating: 0
        monitor: 0
        class: firefox
        title:
        initialClass: firefox
        initialTitle: Firefox
        pid: 2211
        xwayland: 0
        pinned: 0
        fullscreen: 0
        fullscreenmode: 0
        fakefullscreen: 0
        grouped: 0
        swallowing: 0

[3]
➜ ~ rg 55db4e7b0cf0 /tmp/hypr/1b48642fd15c433c53876f1b933dcd46265caf8f_1699171536/hyprland.log
60608:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e89ae20 -> 55db4e7b0d58 (owner: XDG Window)
60609:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e644f00 -> 55db4e7b0e28 (owner: XDG Window)
60610:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e85e160 -> 55db4e7b1308 (owner: Toplevel)
60611:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e85e170 -> 55db4e7b1370 (owner: Toplevel)
60612:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e85e180 -> 55db4e7b12a0 (owner: Toplevel)
60615:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e89ae30 -> 55db4e7b0dc0 (owner: CWindow)
60617:[LOG] Window rule float -> class:^(firefox)$,title:^$ matched [Window 55db4e7b0cf0: title: ""]
60618:[LOG] Window rule opacity 1 0.25 ->  class:^(firefox)$,title:^$ matched [Window 55db4e7b0cf0: title: ""]
60619:[LOG] Window rule move 0% 0% -> class:^(firefox)$,title:^$ matched [Window 55db4e7b0cf0: title: ""]
60620:[LOG] Window rule noinitialfocus -> class:^(firefox)$,title:^$ matched [Window 55db4e7b0cf0: title: ""]
60621:[LOG] Window rule pin -> class:^(firefox)$,title:^$ matched [Window 55db4e7b0cf0: title: ""]
60622:[LOG] Rule move, applying to [Window 55db4e7b0cf0: title: ""]
60624:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e89ae10 -> 55db4e7b0cf0 (owner: XDG Window Late)
60625:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e6b2af0 -> 55db4e7b0e90 (owner: XDG Window Late)
60626:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e644f20 -> 55db4e7b0fc8 (owner: XDG Window Late)
60627:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e6b2a80 -> 55db4e7b1100 (owner: XDG Window Late)
60628:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e6b2aa0 -> 55db4e7b1098 (owner: XDG Window Late)
60629:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e6b2ab0 -> 55db4e7b1030 (owner: XDG Window Late)
60630:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e6b2ac0 -> 55db4e7b1168 (owner: XDG Window Late)
60631:[LOG] Registered signal for owner 55db4e7b0cf0: 55db4e6b2a90 -> 55db4e7b0f60 (owner: XDG Window Late)
60639:[LOG] Creating a surfaceTree Root! [Window 55db4e7b0cf0: title: ""]
60647:[LOG] Creating a subsurface Node! [Window 55db4e7b0cf0: title: ""]
60648:[LOG] Set keyboard focus to surface 55db4e89ab40, with [Window 55db4e7b0cf0: title: ""]
60653:[LOG] [Window 55db4e7b0cf0: title: "", class: firefox] unmapped
60666:[LOG] Destroying the SubSurface tree of unmapped window [Window 55db4e7b0cf0: title: ""]
60686:[LOG] [Window 55db4e7b0cf0: title: "", class: ] destroyed, queueing.

This is a common problem with Firefox, it spawns windows with a title and then renames them. Window rules matching title are not dynamic (i.e. they aren't re-evaluated when the title changes). I guess title could be made to be dynamic (maybe check if there's already an issue for that and otherwise create it). In the meantime you can listen to events for windowtitle changes and apply the changes yourself (https://wiki.hyprland.org/Configuring/Expanding-functionality/#example-script or https://github.com/hyprwm/contrib/tree/main/shellevents).

authors: andresilva blubkatze


text:
Touchpad scrolling causing issues

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit b9c58b6e75f7d0141d8ba88fb3f6f022fed0877a  (seat: send enter/leave events to all bound wl_seats for a client).
Date: Wed May 15 14:33:42 2024
Tag: v0.40.0-92-gb9c58b6e, commits: 4698

flags: (if any)

Bug or Regression?
Regression
Description
Touchpad scrolling stops working after switching tabs in Firefox. Touchpad scrolling in Kate and pcmanfm-qt only works for one of the contexts in split view.
How to reproduce
Firefox

Open two tabs in Firefox, with one having a page long enough to scroll in
Switch between said tabs
Attempt to scroll in the previously scrollable page using a touchpad
Observe that it does not scroll

Kate/pcmanfm-qt

Open a file/folder with enough content to scroll
Open split view mode (Ctrl+Shift+L for Kate, F6 for pcmanfm-qt)
Attempt to scroll using the mouse wheel in both split contexts (it should work as expected)
Attempt to scroll using a touchpad in both split contexts
Observe that it only scrolls within the last context that was scrollable. Mouse wheel scrolling is also limited to that context from that point forward.

Crash reports, logs, images, videos
firefox_wl_debug.log

can you check the wl log on sway and see if theres anything oddly different?

I was having this same issue in every app yesterday. Scrolling using the touchpad didn't work anywhere. I guess there were some fixes overnight. Today, scrolling using the touchpad works everywhere except qutebrowser for me.

One stark contrast is that on sway wl_pointer.set_cursor is regularly called whereas on hyprland it simply stops being called 1/3 of the way into the log and does not get called a single time afterwards.
sway_firefox_wl_debug.log

I have similar issues since yesterday. Zathura pdf viewer is also touched by this

Hyprland doesn't send wl_pointer.axis_stop events?

I don't know how to check that. There is no crash to see the log, and logs then i launch something in terminal does not show this

I don't know how to check that. There is no crash to see the log, and logs then i launch something in terminal does not show this

get a log from you scrolling and breaking the scrolling in a wayland application by running it with WAYLAND_DEBUG=1 $APPLICATION > application_scroll.log 2>&1 and attach it here

Seems like the scrolling gets stuck in a state where it thinks that the scrolling hasn't ended because no axis_stop events are logged for non-discrete scrolling events. It, therefore, attempts to scroll on the last scrollable context whether that context is gone or not and we experience the scrolling not working anymore..?

application_scroll.log

patch.txt
this should fix it then

correct, it does indeed fix it

thanks a lot for finding the issue! Saved me a lot of time debugging that I spent writing the xwayland garbage instead :)

authors: Agent00Ming ArtemChandragupta ehula vaxerski


text:
fix a few asan reported leaks on exit of hyprland

Describe your PR, what does it fix/add?
a few of the leaks are mostly unimportant since the OS will reclaim the memory anways, but it reduces the asan spam if one builds with it atleast.
Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
the changes could use some testing and reviewing so i didnt miss anything obvious, perhaps some weird combination of HW and situation will cause some use after free?

dunno why this is a problem but sure I guess

i knew i missed something obvious, im on a laptop and went into the closet digging for some dusty old logitech usb keyboard. hottplugging its gonna double free because its not set to nullptr here
diff --git a/src/managers/input/InputManager.cpp b/src/managers/input/InputManager.cpp
index 58b5caa3..fb9d2b8a 100644
--- a/src/managers/input/InputManager.cpp
+++ b/src/managers/input/InputManager.cpp
@@ -1195,6 +1195,7 @@ void CInputManager::destroyKeyboard(SKeyboard* pKeyboard) {
     pKeyboard->hyprListener_keyboardKey.removeCallback();

     xkb_state_unref(pKeyboard->xkbTranslationState);
+    pKeyboard->xkbTranslationState = nullptr;

     m_lKeyboards.remove(*pKeyboard);


text:
WIP Support color management protocols

Describe your PR, what does it fix/add?
Add support for color management protocols xx-color-management-v4 and frog-color-management-v1. Will only store and pass color management properties. The actual CM should be implemented by someone else with means to verify that it works as expected. Passing hdr metadata without processing should be enough for fullscreen gaming.
``experimental:wide_color_gamutsets the colorspace toBT2020_RGB. Might not be needed. experimental:xx_color_management_v4enables both protocols. Requires restart.experimental:hdr` forces hdr in desktop mode. Will look weird without proper CM.
Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
Mostly copied code from other protocols. Might mess with pointers, have some redundant stuff and miss some bits.
Is it ready for merging, or does it need work?
WIP. Requires https://github.com/hyprwm/aquamarine/pull/112

[ ] xx-color-management-v4
[x] frog-color-management-v1
[x] send hdr metadata

ref #4933

I'd also mark this as draft

Frog CM can be tested. Most of the gaming stuff https://wiki.archlinux.org/title/KDE#HDR should work the same. I use https://github.com/Zamundaaa/VK_hdr_layer
Will only work with successfully parsed EDID and fullscreen applications.

idek how to test it or how to spot the difference. Only piece of equipment I have with hdr is my laptop

AQ_TRACE=1 HYPRLAND_TRACE=1 and believe what logs say %)
Without the support hdr setting in games is not available. With incorrect support enabling hdr will result in obviously wrong colors (undersaturated/oversaturated/too dim/too bright). The tricky part is to spot slightly wrong colors. I guess some colorimetry equipment might be needed.
Laptop might not work https://github.com/hyprwm/aquamarine/issues/116. Mine doesn't.

well then I can't test. My monitors are old, garbage TN panels. No HDR here.

Nice work @UjinT34
I tried mpv and Silent Hill 2, they seem work. But I need to manually set experimental:hdr=true . Also my second monitor isn't back to sdr after I disable the option.
I will try to compare the color with KDE later.

I confirmed it's working in MPV using the following demo: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/
Log samples:
[TRACE] ColorManagement supportsBT2020 true, supportsPQ true
[TRACE] ColorManagement primaries 0.677734375,0.3134765625 0.283203125,0.6484375 0.1484375,0.068359375 0.3125,0.3291015625
[TRACE] ColorManagement max avg 417.7095, min 0.12436535, max 417.7095, brightness 0.5
[LOG] [AQ] drm: Modesetting DP-2 with 2560x1440@143.91Hz
[TRACE] [AQ] drm: Committed a buffer, updating state
[TRACE] [AQ] drm: CDRMFB: buffer has drmfb attachment with fb 5c85274f8e20
[TRACE] [AQ] Connector blob id 115: clock 592000, 2560x1440, vrefresh 144, name: 2560x1440
[ERR] [AQ] atomic drm: setting hdr min 622, max 209, avg 209, content 209, primaries 33887,15674 14160,32422 7422,3418 33887,15625

I tested the video simultaneously in Hyprland and i3, switching between them to compare on the same monitor (AG322QC4). With hyprshade disabled, there was a subtle but noticeable difference - the colors were more vivid on Hyprland. To verify, I relaunched it from the main branch and performed the same comparison. This time, I observed no difference compared to i3, confirming that the changes made to aquamarine and hyprland were successful.
Well done @UjinT34 !
Note: Enabling experimental:hdr caused color distortion, as expected, so I kept it disabled.
GPU: GTX1080 with nvidia-dkms 565.77-2.

Regarding the last log entry in the sample, was AQ_LOG_ERROR used for debugging purposes? Relevant code part

Fixed it

I guess some colorimetry equipment might be needed.

i have access to an (ex-) xRite i1 DisplayPro colorimeter. is there anything in particular you'd want me to test? displaycal offers profile verification using a firefox window. would ff be colour managed here? i think not.. otherwise i could verify.

Hey, I tried using this by building Aquamarine and Hyprland with your patches but couldn't notice a difference.
I added the following to my config:
#hyprlang noerror true
experimental:xx_color_management_v4 = true
experimental:wide_color_gamut = true
#hyprlang noerror false

And also tried experimental:hdr = true, but that just messed up my colors.
I have a Samsung Odyssey Neo G9 and iirc, HDR worked fine on windows 10 back when I bought it.
I tried using mpv with some movies, as well as the LG videos provided in this pr, and nothing.
Chromium didn't detect HDR when watching youtube either(it did on windows iirc).
Am I doing something wrong?
Thanks in advance!

@nnra6864 have you installed https://github.com/Zamundaaa/VK_hdr_layer ?
and try to run
ENABLE_HDR_WSI=1 mpv --vo=gpu-next --target-colorspace-hint --gpu-api=vulkan --gpu-context=waylandvk --fullscreen  file.mkv

confirm works. process:
https://www.reddit.com/r/mpv/comments/1b43637/comment/kt01t54/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
or if your using arch(btw) just install vk-hdr-layer-kwin6-git(aur) and run
ENABLE_HDR_WSI=1 mpv --vo=gpu-next --target-colorspace-hint "path to vid"
note: (at least in my instance), --gpu-api=vulkan is not needed (suggested from the original reddit comment)

I don't know any wayland clients that can use those protocols directly. Everything needs to work through vulkan with some layer. Different layers might give different results. Looks like only gamescope can be used for xwayland apps. For gaming without gamescope you'll need a wayland-enabled proton version. https://github.com/Frogging-Family/wine-tkg-git/actions/workflows/proton-arch-nopackage.yml works for me.
https://github.com/Zamundaaa/VK_hdr_layer and gamescope pass different parameters for the same game. Couldn't spot a difference in images though. Both of them and this proto implementation might not be 100% correct.
According to https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/hdr10.md color management is not required for HDR. But it seems that something is required to get a better picture.

@nnra6864 have you installed https://github.com/Zamundaaa/VK_hdr_layer ?
and try to run
ENABLE_HDR_WSI=1 mpv --vo=gpu-next --target-colorspace-hint --gpu-api=vulkan --gpu-context=waylandvk --fullscreen  file.mkv

Also chromium doesn't support HDR in linux yet

Hey, i am positive that worked.
I managed to spot differences, mostly in reds being quite a bit stronger in some cases, but I can't help but feel it's unnatural?
For example, in the LG video provided by somebody in this thread, the red car in one of the shots looked really nice.
However, when I tried playing Man of Steel(got the 4k hdr version), reds in the explosion that happens at ~22min looked oversaturated, as seen in the picture.
SDR

HDR

how should the CM be impl, like this? https://invent.kde.org/plasma/kwin/-/merge_requests/436/diffs

Personally I like HDR on demand instead of always on.  When you enable HDR on desktop, the compositor needs to use correct ICC profile to render SDR apps, otherwise the color looks dull.
Also monitors usually have different color profile for SDR and HDR that you can tweak (except laptop).

how should the CM be impl, like this? https://invent.kde.org/plasma/kwin/-/merge_requests/436/diffs

kwin might not be the easiest implementation to follow. Some of the code is inside Qt.
CM needs:

gather output capabilities and ICC settings and determine a preferred image description (not used by current clients)

perform necessary transformations based on the output and client settings

pass correct values to some drm properties:

https://drmdb.emersion.fr/properties/3435973836/DEGAMMA_LUT (not supported by AQ)
https://drmdb.emersion.fr/properties/3435973836/CTM output->state->setCTM
https://drmdb.emersion.fr/properties/3435973836/GAMMA_LUT output->state->setGammaLut
https://drmdb.emersion.fr/properties/3233857728/HDR_OUTPUT_METADATA output->state->setHDRMetadata
not all of those properties are required but they can make some transformations easier

Lots of docs about color and HDR https://gitlab.freedesktop.org/pq/color-and-hdr

well the thing is, at least for my monitor, you'd need to fullscreen the HDR content, and it will also black out my monitor for around 1s which imo is kinda annoying

well the thing is, at least for my monitor, you'd need to fullscreen the HDR content, and it will also black out my monitor for around 1s which imo is kinda annoying

Exact same for me.
I thought this was expected behavior tho, am I wrong?

well the thing is, at least for my monitor, you'd need to fullscreen the HDR content, and it will also black out my monitor for around 1s which imo is kinda annoying

Exact same for me. I thought this was expected behavior tho, am I wrong?

ya its expected behavior, but still wanna mitigate it somehow though


text:
AUR Package

Creating this as a reminder for myself (in case nobody has done this in the next 20h) and as a todo-check for the community in general

@alba4k, can you add hyprlang as a dependency to the PKGBUILD, please?

The problem is that hyprlang-git still shows up as 0.3.2 (the maintainer would need to run makepkg and update the pkgver)
This will fix itself as soon as hyprlang in the repos is updated to 0.4.0
the problem here isn't that hyprlang isnt added as a dependency, it's that it is, and that I specified that its version needs to be at least 0.4.0
this issue will fix itself in some time, in the meantime, should I just remove the check? I assume this also affects the hypridle-git package?

repo: hyprwm/hyprlock


text:
refix support for symlinked images

Refixing #472

ah i see, the code that needs fixing has been moved to hyprgraphics, i'll close this one and make a pr there.


text:
[Dictionary] Change Internal Data Structure to use std::span

Change the dictionary’s internal structure to use std::span (first, store the data in the segment, once it runs; move to storage manager).

I would recommend adapting the current dictionary segment. Adding new segments types can be a little bit of a pain (and adds compile time).
What can be done here:

continue to use the std::vector INTERNALLY for the first steps
use std::spans that are defined on top of vectors.data()
find all cases, where the vectors are accesses and rewrite to spans

there is a function that gets the dictionary, that should be easy to rewrite
there are the iterables (here pass 99% of the accesses to segments through) which need a few adaptions

Once we know if that works (there are always problems coming up) we can get rid of the std::vectors and store data in a "chunk of bytes".

Any news here?

Have not started yet, as my working days this week are Friday and Sunday. Will start working on it after lunch and perhaps have some updates this evening.

Any news here?

@tjjordan  and me will start on implementing this now

Is implemented.

authors: Bouncner phoeinx rrcomtech


text:
Add partial support for Nordea

Hi, and thanks a lot for making this library!
We used this to integrate with Nordea's Web Services API, and modified the library to support that use case.
If you are interested in upstreaming these changes, here they are :)
I didn't get the certificate requesting part to quite work right with little effort and we don't really need it, with certs generated using other means, so that functionality unfortunately isn't part of this PR. I have included a mention in the readme that the Nordea client lacks the *certificate -methods.
Other WS API calls work though, and I added a new method uploadFile to the client.
I'm happy to answer questions and to try make changes to the implementation if any are needed. As far as I can see, this shouldn't break anything with the Osuuspankki client, but to be honest I don't have a client account there so I haven't really tested either. If possible, I'd recommend testing that it still works before publishing these changes.
Again, thanks for your work

The build seems to fail due to reduced test coverage. I did play around with the pankkiyhteys.test.ts specs and could duplicate some of those Osuuspankki client tests for the Nordea client, but I'm not quite convinced that that would add much real test coverage "safety". The methods tested in those specs mostly fall through to the Client-class, which both of these clients inherit, so that would mostly test the same thing twice. The tests do a lot of mocking and don't (obviously) send request to the actual banks, so they can't really catch errors coming from bank API differences either.

Hi,
Awesome that you found this useful and were able to get Nordea API working! I'll test that my use case with Osuuspankki continues to work with these changes. After that I'll happily merge this.
Don't worry about coverage limits. I think I'll end up removing it.

Thanks, sounds good. No rush on our end, we are currently using our version directly from the github fork and that works well enough for now.
I also did some other chore work, upgraded all dependencies and cleaned up some ESLint warnings here. I didn't include those in this PR because they are kinda irrelevant to the Nordea feature, but I can make another PR if you'd like (perhaps if/when this gets merged).

authors: hyrsky noppa

repo: hyrsky/pankkiyhteys


text:
build hysds_ui on mozart component

Build hysds_ui if installing mozart component. Assumption is that nodejs/npm is already installed.

i thought we removed npm install --silent because `hysds-dockerfile1 was failing because verdi didn’t have nodejs

authors: DustinKLo pymonger

repo: hysds/hysds-framework


text:
Delete copies of CONUS hourly data on object storage

@amsnyder, @alaws-USGS  and hytest crew:
As described in more detail in this notebook, there are currently 3 copies of the CONUS404 hourly data on object storage:

AWS S3 nhgf-development
RENCI Pod rsignellbucket2
USGS Pod hytest

Since this data also exists on caldera, I suggest we delete the dataset on AWS S3 nhgf-development (saving USGS about $1600/month) and also on the RENCI pod rsignellbucket2, which was an allocation to be used before the USGS pod was acquired.
Any objections?
If not I will delete the dataset from the RENCI pod rsignellbucket2, freeing up the space for other use.
Someone with permissions for nhgf-development would need to delete the copy there.

I forgot, there is one more copy!
(rclone)[rsignell@pn124 ~]$ rclone size osn-usgspod-testbucket:usgspod-testbucket/hytest/conus404/conus404_hourly_202302.zarr --checkers 34 --dis
able ListR
Total objects: 10.915M (10914729)
Total size: 70.266 TiB (77257934739130 Byte)

I'm currently deleting the version on rsignellbucket2 with this command:
rclone delete osn-rsignellbucket2:rsignellbucket2/hytest/conus404/conus404_hourly_202302.zarr --disable ListR --rmdirs --checkers 34

It's deleting at rate of about 6TB per hour.

I forgot, there is one more copy!   Before we had the hytest bucket on USGS pod 1, we had the usgspod-testbucket to see if the pod was working okay.   And that copy is still there:
(rclone)[rsignell@pn124 ~]$ rclone size osn-usgspod-testbucket:usgspod-testbucket/hytest/conus404/conus404_hourly_202302.zarr --checkers 34 --disable ListR
Total objects: 10.915M (10914729)
Total size: 70.266 TiB (77257934739130 Byte)

The rclone remote for this bucket I have specified in ~/.config/rclone/rclone.conf as:
[osn-usgspod-testbucket]
type = s3
provider = Ceph
access_key_id = <osn key for this bucket here>
secret_access_key = <osn secret key for this bucket here>
endpoint = https://usgs.osn.mghpcc.org
no_check_bucket = true

@amsnyder shall I delete this as well or would you like someone else to have the experience?

You can go ahead and delete the copy in usgspod-testbucket

Okay, I'll fire it off.

authors: amsnyder rsignell

repo: hytest-org/hytest


text:
[FEATURE] JWT refreshToken 개발

상세 기능

JWT refreshToken 개발
유효기간 : 14일로 설정
refreshToken 관리 방안 고민

관리 X
redis 에 저장

로그인 API 응답 스펙 변경

기존 {
     "memberId": 1,
     "accessToken": "token"
 }

변경 {
     "memberId": 1
     "accessToken": "accessToken",
     "refreshToken": "refreshToken"
 }

accessToken 만료 시 refreshToken으로 재발급을 받는 API

endPoint

/api/accounts/refresh

POST
Request Body{
  "refreshToken": "token"
}


text:
why chatLinelayer is always draw in front of chatPointHighlightLayer ?

in the example of multi-touch chart-tracking, the chatlinelayer is always draw in front of the chartPointHighlightlayer, even though I change the position in [layer].
I read the wiki, but dont understand in which order the layers are draw. can you please answer this.

Following

I fixed it by doing this:
creating Chart() as usual, except not adding LineLayer
 let chart = Chart(frame: chartFrame,
                          innerFrame: innerFrame,
                          settings: ChartSettings(),
                          layers: [
                            xAxisLayer,
                            yAxisLayer,
                            guidelinesLayer,
                            showCoordsLinesLayer,
                            //chartPointsLineLayer,
                            chartPointsCircleLayer,
                            touchLayer])

then create LineLayer and add as subview before adding chart
        let lineView = Chart(frame: chartFrame,
        innerFrame: innerFrame,
        settings: ChartSettings(),
        layers: [chartPointsLineLayer])

        self.chartView.addSubview(lineView.view)
       //we have to add lineView separately, because else it would be in front of chartPointsCircles (and it looks wrong)
        self.chartView.addSubview(chart.view)
        self.patientChart = chart

Thats it, now line is behind points.
Actually this solutions makes bug, when lineView duplicates on screen rotation. I solved this by doing this before "addSubview":
self.chartView.subviews.forEach({ $0.removeFromSuperview() })

authors: chulkov heumn woshahua

repo: i-schuetz/SwiftCharts


text:
Fix getFixedT function always returning values in current language

I was running into an issue where getFixedT always returned values in the current language not the requested language. I found  this issue - https://github.com/i18next/next-i18next/issues/1184 about it. The fix for it was merged in and released and seemed to work. However a bit later the fix got reverted as people did not expect all locales to be loaded by the library. See the following issue - https://github.com/i18next/next-i18next/issues/1267.
This PR proposes a potential new argument to the serverSideTranslations function (could also be a config override field really). This argument can be used to provide extra locales to load for the specific page and allows one to opt into loading more or all locales. As a result getFixedT will then work for the locales that are loaded for the page.

If the general direction/idea is accepted I will clean this PR up and will add tests/documentation updates too.

Checklist

[x] only relevant code is changed (make a diff before you submit the PR)
[x] run tests npm run test
[x] tests are included
[x] commit message and code follows the Developer's Certification of Origin

sounds interesting... can you also adapt the readme and add a test?

Sure I'll do that.
Do you think the extra argument is fine or should I move it into configOverride?

configOverride is the passed in next-i18next config... so I think the extra argument should be ok.

Thank you for your contribution.
Included in v11.3.0


text:
OAuth not presenting itself.

First off: Thank you for sharing this, as it is much needed.
Unfortunately, it doesn't seem to be working for me. When heading to Netlify CMS login at /admin/ seeing login options for email and password but no GitHub authorization button.
In fact, it seems to be redirecting to /admin/#/ rather than the Github authorization page.

So you don't even get the Github button? Did you set up the config.yml for the CMS, as well as adding the app to your Github account? I'm not actually using this right now but I just tried it and it still works for me.

Yes on both counts. Your instructions were excellent. Everything seems to be in order, but no go.
Still puttering around with the problem, but I suspect it has something to do with the 11ty template I was experimenting with. It was originally designed for Netlify deployment, so perhaps there is something in there I am missing that is causing the issue. Will try again with a clean setup.
That said, thank you very much for the kind and quick reply. If I figure out what error I'm making (and manage to resolve it)  I will share it here.

Hmmm, same problem here, and just double check my config still don't work for me. are you fixed this? really want to make Netlify CMS work with Cloudflare Pages:-(

@F1ySyn I just tried and am still unable to reproduce the problem.
One thing I thought of: Are you using a framework like Next.js or something that deploys a _worker.js for server-side code? The Pages /functions directory is not compatible with using a manual-mode _worker.js so that definitely wouldn't work...

I encountered a similar problem (I only saw the 'Netlify identify' button, no other means of authentication). Copying static/admin/index.html to static/admin/ of my repo fixed this.
As a side note, I would consider copying the index.html of https://github.com/SubhenduX/decap-cms-cloudflare-pages instead, as SubhenduX already went to the trouble to rename and update it to Decap CMS.

Actually, to make it work in Decap CMS 3.1.0, I had to add some more configuration settings to static/admin/config.yml (I assume some default values changed in the newer versions). My full Github-related config is:
backend:
  name: github
  repo: <github user | github organization>/<github repo>
  branch: main
  site_domain: <your site domain>
  base_url: <your site domain>
  auth_endpoint: /api/auth

Opened PR #7 for this.

Opened PR #7 for this.

Merged, thanks!


text:
Demonstrate source detection result evaluation

We should demonstrate how one could evaluate results of the source detection workflow. For example we could quantify quality vs. noise, quality vs. faint/strong sources, runtime, confusion matrix, ...
Perhaps Olga has some ideas what/how we should analyze source detection.

Example ideas for plots:

Plot accuracy vs. noise
Plot accuracy vs. source size
https://arxiv.org/pdf/2110.08618.pdf
https://web.archive.org/web/20190501212002id_/https://iopscience.iop.org/article/10.3847/1538-4357/aa8d1e/pdf

Need to test this with more sources.

authors: cvoegele deiruch


text:
Removal of META-INF/services

Currently the META-INF folder completely gets removed by the Apktool (as stated in the docs), but that also removes the services folder inside of it which is very important to libraries/applications that use service loader to load some interface implementations, like coroutines-android module that uses service loader to locate MainDispatcherFactory.
This causes a runtime crash whenever someone wants to use Dispatchers.Main in their application since it cannot be loaded.
Information

Apktool Version (apktool -version) - 2.4.0 (I tried with 2.3.1+)
Operating System (Mac, Linux, Windows) - Mac OS
APK From? (Playstore, ROM, Other) - Any APK containing service loader (like coroutines android)

Stacktrace/Logcat
java.lang.IllegalStateException: Module with the Main dispatcher is missing. Add dependency providing the Main dispatcher, e.g. 'kotlinx-coroutines-android'

Steps to Reproduce

java -jar ./apktool_2.3.1.jar d ./sample.apk -o ./temp/sample -f
build the app using java -jar ./apktool_2.3.1.jar b ./temp/sample -o ./sample2.apk -f
Resign using jar signer

Frameworks
If this APK is from an OEM ROM (Samsung, HTC, LG). Please attach framework files
(.apks that live in /system/framework or /system/priv-app)
APK
If this APK can be freely shared, please upload/attach a link to it.
Questions to ask before submission

Have you tried apktool d, apktool b without changing anything? No
If you are trying to install a modified apk, did you resign it? Yes
Are you using the latest apktool version?

This issue will be fixed by this MR.

repo: iBotPeaches/Apktool


text:
パスコードが登録出来ていない

リザルトコードからはパスコードが登録出来たように見えるが、実際には登録されていません。Switchbot Appで確認しても作成したパスコードが見えません。
{'statusCode': 100, 'body': {'commandId': 'CMD166636073309219'}, 'message': 'success'}

その後、再度試したら問題なくパスコードが出来上がるのを確認出来ました。