text:
Use of Lazy Components

This PR replace #56 and solve #52, #47 and maybe #53
No change on the API surface.
Only the previously undocumented location property disappear.
Like the old behavior (without the location property), the router use the window.location property as source of truth.
In other word, you are able to use the router without using the location slice wired to the state and actions and the use of subscribe.
tl;dr If you are using the router this PR will add state first routing without no need to change your code.

@Swizz In other word, you are able to use the router without using the location slice wired to the state and actions and the use of subscribe.

What do you mean?

State first
const state = {
  location: location.state
}

const actions = {
  location: location.actions
}

const main = app(
  state,
  actions,
  (state, actions) => <Route render={() =>
Hello!
} />,
  document.body
)

const unsubscribe = location.subscribe(main.location)

main.location.go("route")

Window location
const state = {}

const actions = {}

const main = app(
  state,
  actions,
  (state, actions) => <Route render={() =>
Hello!
} />,
  document.body
)

history.pushState(null, "", "route")

@Swizz Can you resolve conflicts?

Great! Thanks, @Swizz!

Published as 0.5.0.

authors: Swizz jorgebucaran

repo: hyperapp/router


text:
Implementation of a Markdown Parser for Package Update Descriptions on WebUi

Summary
Implementation of a Markdown Parser for Package Update Descriptions on WebUi.
The Markdown of a Packge from GitHub will be parsed. Also it will be sentinized for security reasons.
We should always use markdown for our Release Notes.
Maybe an enhancement would be that we can collapse the description in the update panel to safe space. Can be discussed.
What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Build-related changes
[ ] Other, please describe:

If changing the UI of web configuration, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing setups:
The PR fulfills these requirements:

[ ] When resolving a specific issue, it's referenced in the PR's body (e.g. Fixes: #xxx[,#xxx], where "xxx" is the issue number)

If adding a new feature, the PR's description includes:

[x] A convincing reason for adding this feature
[ ] Related documents have been updated (docs/docs/en)
[ ] Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.
Other information:

I like it!

source: gharchive/pull-request

license: mit

license_type: permissive

license_source: bigquery


text:
Hyperion running on Android Devices

Dear All,
I have bought a Lightpack set from Prismatik for my Android TV Box - Geniatech ATV1200. Sadly, by the moment this device is not supported.
Do you have any plan of having Hyperion running on Android devices? I dont mean the android client app, I mean the real service.
best regards,

Just wanted to bump this - I have an android grabber I'm working on here:
https://github.com/abrenoch/hyperion-android-grabber
Would love some extra hands on the project!

I just saw this. I built a mock up that worked a while back but found some limitations in the Android SDK. IIRC I couldn't pull video from hardware inputs nor could I pull video from Netflix streams but the Android TV UI would respond. I haven't had a chance to work on it for a while and Android 7 or 8 may have fixed some issues. Here is my repo if you wanna try it out: https://github.com/packruler/BacklightHandler

@packruler Hey really nice stuff! I'll be sure to try out some bits of your code to see if it is an improvement on what I'm doing (first glance seemed pretty simple to understand... the code I found and was working with uses openGL for some stuff, and I'm not sure if that is a problem yet or not).
True netflix will not work with this method, but from what I've found it won't work with pretty much anything like that... Short of rooting of course. There may be an xposed module or something that could allow that to happen. What do you mean by hardware inputs though?

source: gharchive/issue

authors: abrenoch jgato packruler

repo: hyperion-project/hyperion


text:
add mariadb probe

Monika Pull Request (PR)
What feature/issue does this PR add

Implement #913
Add MariaDB probe

How did you implement / how did you fix it

Using @hyperjumptech/db-connection-checker library
Update validation / json-schema
Add guide probe documentation

How to test

run npm run test should all pass
create the following test.yaml:

notifications:
  - id: unique-id
    type: desktop

probes:
  - id: 'id-mariadb'
    name: Mariadb probe
    description: maria db connection monitor
    mariadb:
      - host: 172.17.0.1
        port: 3306
        username: user
        password: password
        database: mydb
    incidentThreshold: 2
    recoveryThreshold: 2
    alerts:
      - assertion: response.status != 200
        message: 'AAALEEEERT! DB offline'

run bin/run-dev -c test.yaml -s -1 to probe the database. Should run with connection refused error
spin up the mariadb instance with the above spec (no. 2)
monika should detect the new mariadb connection

Screenshot
Test result above

Notification created (desktop notification on linux)

Schema validation and suggestion

Quick Q: Does this PR explicitly only supports MariaDB, or it could be used for MySQL too?

authors: dennypradipta sapiderman

repo: hyperjumptech/monika

license: MIT

license_source: github-api


text:
New IAS authentication

IAS has a new api-key based authentication (described in revision 5.0 of IAS spec)

Can you please link the spec here?

Can you please link the spec here?

no public link yet :-(

Closed with PR #49

Can you please link the spec here?

finally there is a public link to v5: https://api.trustedservices.intel.com/documents/sgx-attestation-api-spec.pdf


text:
Update Splice main to version 0.2.5-snapshot.20241004.7154.0.v45aac3e1 (automatic PR)

This PR updates branch main of Splice from the latest changes as of version 0.2.5-snapshot.20241004.7154.0.v45aac3e1, commit DACH-NY/canton-network-node@45aac3e131

#59

authors: canton-network-da ray-roestenburg-da

repo: hyperledger-labs/splice


text:
chore(python): added pyproject.toml

closes #154
@dbluhm any chance you can review this? I followed some guides, and the demo is working, but python setup still remains a small mystery to me :).
Signed-off-by: blu3beri blu3beri@proton.me

I'm not super familiar with how bundling binaries looks in pyproject.toml so I'll read up a bit and review! (Looks good to me though)

Did some digging; it would seem that poetry is not currently well suited to building platform specific wheels. It might be possible but the poetry build command can only build pure python wheels right now. @ryjones could you provide a little more detail on why a pyproject.toml specifically is required to get PyPI tokens? We can set up the pyproject.toml to configure setuptools (which looks like the best option for building platform specific wheels) instead of poetry but I'm not sure that will fit the workflow you were hoping for.
Input from @andrewwhitehead (who has far more experience building python packages with bundled binaries) would probably also be helpful, if you get a chance.

@dbluhm I was following this guide: https://realpython.com/pypi-publish-python-package/#configure-your-package

@blu3beri I propose we construct a minimal pyproject.toml with just:
# pyproject.toml

[build-system]
requires = ["setuptools>=61.0.0", "wheel"]
build-backend = "setuptools.build_meta"

And continue using setuptools for builds, following the same pattern as askar and indy-shared-rs.

Thanks for the work @dbluhm! I will change the PR and revert the setup.py and double check with askar.

authors: blu3beri dbluhm ryjones

repo: hyperledger/anoncreds-rs


text:
Make mediation invitation parameter idempotent

To ease Aca-py's deployment in scenarios where command line arguments
cannot be changed easily, make --mediator-invitation and
--mediator-connections-invite available to the provision command.
provision stores the mediator invite to be used by the agent (effectively "provisioning" it).
start uses the stored invite. Once used, it does not establish connection again.
If the invitation changes, the  stored value is replaced by the new one, the default mediator is cleared and the new invitation
is used to establish connection.
Boy-scouting: I split the mediation invite tests apart from the other ones for the sake of easier comprehension/code management.

Codecov Report

Merging #1413 (500c522) into main (db9c6e1) will increase coverage by 0.01%.
The diff coverage is 97.64%.

@@            Coverage Diff             @@
##             main    #1413      +/-   ##
==========================================
+ Coverage   95.32%   95.33%   +0.01%
==========================================
  Files         482      483       +1
  Lines       29154    29224      +70
==========================================
+ Hits        27791    27861      +70
  Misses       1363     1363

I don't really understand what the goal is here. It seems like it's meant to store the mediation invitation if you add the argument to the provision command, but the conductor startup process is still looking for the mediation.invite setting instead of the stored invitation. It seems like the argument would need to be specified again in order to be accepted at startup?

I don't really understand what the goal is here. It seems like it's meant to store the mediation invitation if you add the argument to the provision command, but the conductor startup process is still looking for the mediation.invite setting instead of the stored invitation. It seems like the argument would need to be specified again in order to be accepted at startup?

Our issue is that in an automated scalable environment, new aca-py instances are spinned up with the same arguments as the original instance, thus retaining the mediation.invite setting. We want to avoid these new instances creating new connections to the mediator if one is already established, hence the need for idempotency.
However, I agree with your point that the conductor should not necessarily require the mediation.invite to be specified if one was provisioned and is already stored. I'll make sure this can be either/or.

repo: hyperledger/aries-cloudagent-python


text:
fix: incorrect return type

Small fix in the type hinting of the store_credential method
In general I think it may be good to look into static type checking tools for ACA-Py. E.g. tools like pyright can help find errors in typing (and thus implementation)
Signed-off-by: Timo Glastra timo@animo.id

@ianco -- do you want to look into the discussion above about using pyright?

authors: TimoGlastra swcurran


text:
Update snyk workflow to execute on Pull Request

run on pull_request not push
only when PRs change /aries_cloudagent files or /docker files.

Not sure how to test this...
fixes #2526

thanks @WadeBarnes - guess we will have to keep an eye on execution and file coverage...


text:
docs: fix meeting time in readme and add link to meetings page

Signed-off-by: Stephen Curran swcurran@gmail.com

Codecov Report

Merging #465 (199144a) into main (bf150fe) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #465   +/-   ##
=======================================
  Coverage   85.65%   85.65%
=======================================
  Files         253      253
  Lines        5467     5467
  Branches      878      878
=======================================
  Hits         4683     4683
  Misses        783      783
  Partials        1        1

Continue to review full report at Codecov.

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

Doh... I was playing with two meetings at once.  #fail

w00t!!  I'm a "contributor".  🔥

authors: codecov-commenter swcurran

repo: hyperledger/aries-framework-javascript


text:
Missing app directory & old README

Can someone please update the README so that the app can be built and installed as the instructions are out of date. There is no /app directory.

Hi,
If you looking for app and core folder, it's inside the packages/legacy
folder.
On Mon, 10 Apr 2023, 06:56 Rowan Shedden, @.***> wrote:

Can someone please update the README so that the app can be built and
installed as the instructions are out of date. There is no /app directory.
—
Reply to this email directly, view it on GitHub
https://github.com/hyperledger/aries-mobile-agent-react-native/issues/704,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXTKCPMOXQGVGDWGUEXSXVDXANOVRANCNFSM6AAAAAAWYOP4YA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

thankyou ... I see it now.

authors: PenguinTaro rowanshedden


text:
Full sync extremely slow

Description
Mainnet full sync is taking multiple weeks - running besu:21.7.2 in an Azure AKS Cluster with 10Gi of memory and 2 CPU cores and 3TB storage dedicated to chain data
25 peers
Expected behavior:
Sync to occur within a reasonable amount of time
Actual behavior:
Processing about 200 blocks per 40 minutes
Versions (Add all that apply)

Software version: 21.7.2
Java version: openjdk version "11.0.11" 2021-04-20
OS Name & Version: Docker?
Kernel Version: Linux besu-node-0 5.4.0-1059-azure #62~18.04.1-Ubuntu SMP Tue Sep 14 17:53:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Virtual Machine software & version: Ubuntu 18.04.6 LTS
Docker Version: [containerd://1.4.9+azure]
Cloud VM, type, size: [Azure AKS Standard_D4as_v4]

Additional Information

Logs:
2021-10-20 12:33:55.784+00:00 | EthScheduler-Services-5 (importBlock) | INFO  | FullImportBlockStep | Import reached block 13425400 (0xcc2f5263fcf689e9d102d5806ca369476088d68114af9461c507877ff9b1d01e), 1.714 Mg/s, Peers: 25
2021-10-20 12:59:01.764+00:00 | EthScheduler-Services-5 (importBlock) | INFO  | FullImportBlockStep | Import reached block 13425600 (0xefc9cf23d7fc3226f6f485a7d5921ea57aaa76ee6431ab62f8c78a84be71db72), 2.024 Mg/s, Peers: 25
2021-10-20 13:32:37.342+00:00 | EthScheduler-Services-5 (importBlock) | INFO  | FullImportBlockStep | Import reached block 13425800 (0xc61bb21c79877516c7824f60854b061d5c261a7154a5ff9991c080782050f4fd), 1.524 Mg/s, Peers: 25
2021-10-20 14:07:40.270+00:00 | EthScheduler-Services-5 (importBlock) | INFO  | FullImportBlockStep | Import reached block 13426000 (0xe8028f2e7ffdd28677f3e149304a422ea81559bb7d006536f497c8fcf4367f1d), 1.465 Mg/s, Peers: 25
2021-10-20 14:44:26.835+00:00 | EthScheduler-Services-5 (importBlock) | INFO  | FullImportBlockStep | Import reached block 13426200 (0xa1433c5cc63e8fea55d83efa5f75df38cc5fc27e57aa4ae6d9090602aa8d67eb), 1.402 Mg/s, Peers: 25

I've checked metrics, the process is not using much the CPU at all, using about 60% of the memory limit (~6Gi) and storage utilization is very low (see charts).  How can we expedite this sync?

Appears that the disk type has some bearing on the speed for which the sync occurs, once we completed the PipelineChainDownloader phase, it went into a world state download stage where it got really far behind in syncing.  We restarted the pod and we're syncing again but very slowly, averaging over 4s per block
2021-10-29 17:30:25.216+00:00 | EthScheduler-Services-32 (importBlock) | INFO  | FastImportBlocksStep | Completed importing chain segment 13107401 to 13107500, Peers: 26
2021-10-29 17:30:25.216+00:00 | EthScheduler-Services-32 (importBlock) | INFO  | PipelineChainDownloader | Chain download complete
2021-10-29 17:35:28.895+00:00 | EthScheduler-Services-7 (requestCompleteTask) | INFO  | CompleteTaskStep | Downloaded 254000000 world state nodes. At least 32296960 nodes remaining.

We're essentially back at the stage we were with the old instance on the slow HDD, CPU util isn't maxed out and there's plenty of memory.  What else can we do to kickstart this thing back into processing quickly?

there is a lot of state to download. It's a bit confusing because we expect fast sync to increase block numbers until it’s close to head, then stall in terms of block numbers - it needs to download the world state before it can continue. On our canary nodes the "stall" period is 5 days + at current mainnet size.
There are metrics around fast sync eg besu_synchronizer_fast_sync_pivot_block_current, besu_synchronizer_world_state_completed_requests_total and besu_synchronizer_world_state_pending_requests_current
If you can add these metrics to your dash, you can see progress of the "download state" step even while "block number" seems stuck.

^ above comment from me relates to fast sync whereas this issue is related to full sync

Peers stays constant at 25
Average block time is about 6.5 seconds
When it was in fast sync it was in the millisecond range, shot up afterwards
It’s catching up, it’s just really slow.  12 hours ago it was at 327,359 behind and currently it is at 323,504
Is that expected speed for a full sync?

Block time chart (not sure what happened mid-10/29 through end-of 10/31, maybe didn't report a value?

Checking if there had been any progress on finding out the cause.  Block time average is still 10 seconds, and we're still 218,641 blocks behind.

is the SSD gettinfg close to full?  the long period of no blocks processing looks a lot like either a rocksdb compaction or heavy SSD garbage collection.  The write performance of SSD drops off significantly when it approaches full.
ssd performance
how full is the disk?

Disk is reporting 37% full, CPU time is averaging under around .6, so it's not doing a whole lot.  How much space do we need to be mindful of for a full besu node?
Prometheus reports around 1k R/W IOPS, 30MB/s read throughput, 250k write throughput.  I assume it should be writing a heckuva lot more if there's still 200k blocks to go?

Other thoughts from @garyschulte
what is the max number of open files?  mainnet nodes usually have many thousands of rocksdb segments.
when running on a i/o bandwidth constrained machine I have found tweaking these params help:
Xplugin-rocksdb-max-background-compactions=1
Xplugin-rocksdb-max-open-files=8192
Xplugin-rocksdb-cache-capacity=67108864

I tuned the number of max open files in accordance to the number of rocksdb segments, bumped up the ulimit for max open files, bumped up the cache capacity, and limited the number of concurrent compactions.
if you are experiencing io constraints - those configs helped a lot on a raspi bonsai node.

Any update here?

We identified some optimizations in fast sync that makes fast sync retain much more of its world state download progress after a re-pivot.  This fix is in the nightly already and should make it into a release version soon:
https://github.com/hyperledger/besu/pull/3202

Hi @jmcruz1983 @adean-consensys - realise it's been a while but we have made some improvements in peering and syncing (22.1.0 had the fast sync optimisation mentioned above #3202 ). Additionally we are beginning a holistic assessment of peering behavior including any outstanding issues. So we're hoping that either those changes have it fixed already, or that you're able to give us some more info if you're still having related issues?

authors: adean-consensys garyschulte garyschulteog jmcruz1983 macfarla

repo: hyperledger/besu


text:
Thread Blocked

Versions (Add all that apply)

Software version: 22.7.3
Cloud VM, type, size: Digital Ocean Kubernetes - v1.24.4.

Additional Information (Add any of the following or anything else that may be relevant)
Running Prysm 3.1.1-patch as consensys client (-patch is a patch to increase the prysm default timeout from 6 seconds to 30 seconds).
Image:         hyperledger/besu:22.7.3
--data-path=/data
  --network=mainnet
  --rpc-http-enabled
  --sync-mode=X_CHECKPOINT
  --data-storage-format=BONSAI
  --rpc-http-host=0.0.0.0
  --rpc-http-cors-origins=*
  --rpc-ws-enabled=true
  --rpc-ws-host=0.0.0.0
  --host-allowlist=*
  --engine-host-allowlist=*
  --engine-jwt-enabled=true
  --engine-jwt-secret=/data/jwt.hex
  --engine-rpc-port=8551

2022-09-24 06:40:29.232+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,485 / 132 tx / base fee 4.16 gwei / 14,732,388 (49.1%) gas / (0x058f084329a115c1194b59e52bf5883fc4a5c1d286da3c365f5d2e61c56b26ed) in 3.748s. Peers: 24
2022-09-24 06:40:50.146+00:00 | vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-eventloop-thread-1,5,main] has been blocked for 6545 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
        at java.base@11.0.16/java.util.LinkedHashMap.newNode(LinkedHashMap.java:256)
        at java.base@11.0.16/java.util.HashMap.putVal(HashMap.java:627)
        at java.base@11.0.16/java.util.HashMap.put(HashMap.java:608)
        at app//io.netty.bootstrap.AbstractBootstrap.option(AbstractBootstrap.java:179)
        at app//org.hyperledger.besu.ethereum.p2p.rlpx.connections.netty.NettyConnectionInitializer.connect(NettyConnectionInitializer.java:182)
        at app//org.hyperledger.besu.ethereum.p2p.rlpx.RlpxAgent.initiateOutboundConnection(RlpxAgent.java:345)
        at app//org.hyperledger.besu.ethereum.p2p.rlpx.RlpxAgent.lambda$connect$10(RlpxAgent.java:265)
        at app//org.hyperledger.besu.ethereum.p2p.rlpx.RlpxAgent$$Lambda$1044/0x00000008406ad840.apply(Unknown Source)
        at java.base@11.0.16/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
        at app//org.hyperledger.besu.ethereum.p2p.rlpx.RlpxAgent.connect(RlpxAgent.java:256)
        at app//org.hyperledger.besu.ethereum.p2p.network.DefaultP2PNetwork.handlePeerBondedEvent(DefaultP2PNetwork.java:408)
        at app//org.hyperledger.besu.ethereum.p2p.network.DefaultP2PNetwork$$Lambda$1000/0x0000000840697440.onPeerBonded(Unknown Source)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.lambda$dispatchPeerBondedEvent$17(PeerDiscoveryController.java:621)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController$$Lambda$1039/0x00000008406af440.accept(Unknown Source)
        at app//org.hyperledger.besu.util.Subscribers.lambda$forEach$0(Subscribers.java:112)
        at app//org.hyperledger.besu.util.Subscribers$$Lambda$456/0x000000084042c040.accept(Unknown Source)
        at java.base@11.0.16/java.lang.Iterable.forEach(Iterable.java:75)
        at app//org.hyperledger.besu.util.Subscribers.forEach(Subscribers.java:109)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.dispatchPeerBondedEvent(PeerDiscoveryController.java:621)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.notifyPeerBonded(PeerDiscoveryController.java:423)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.addToPeerTable(PeerDiscoveryController.java:403)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.lambda$onMessage$1(PeerDiscoveryController.java:323)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController$$Lambda$1038/0x00000008406af040.accept(Unknown Source)
        at java.base@11.0.16/java.util.Optional.ifPresent(Optional.java:183)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.onMessage(PeerDiscoveryController.java:320)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent.lambda$handleIncomingPacket$4(PeerDiscoveryAgent.java:298)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent$$Lambda$1034/0x00000008406a8c40.accept(Unknown Source)
        at java.base@11.0.16/java.util.Optional.ifPresent(Optional.java:183)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent.handleIncomingPacket(PeerDiscoveryAgent.java:298)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent.lambda$handlePacket$10(VertxPeerDiscoveryAgent.java:297)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent$$Lambda$1027/0x000000084069c840.handle(Unknown Source)
        at app//io.vertx.core.impl.future.FutureImpl$3.onSuccess(FutureImpl.java:141)
        at app//io.vertx.core.impl.future.FutureBase.lambda$emitSuccess$0(FutureBase.java:54)
        at app//io.vertx.core.impl.future.FutureBase$$Lambda$684/0x00000008404a4440.run(Unknown Source)
        at app//io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
        at app//io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
        at app//io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:391)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
        at app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base@11.0.16/java.lang.Thread.run(Thread.java:829)
2022-09-24 06:40:51.449+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,486 / 177 tx / base fee 4.15 gwei / 15,726,259 (52.4%) gas / (0x2753823a48960426a37bf22f5ddd43d2257d593303bf52428c6e9883dd9bd949) in 10.135s. Peers: 19
2022-09-24 06:40:52.049+00:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x2753823a48960426a37bf22f5ddd43d2257d593303bf52428c6e9883dd9bd949, finalized: 0xfdfc6cbe38585a4bb1ab9f21ef52914c3ae8109acab78f9684d3b667ad4240b1, safeBlockHash: 0x11ce949be885a32bcf6cd4b58dd35d43664a4bf1e801da2b8666fa763e54eb25
2022-09-24 06:41:10.827+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,487 / 143 tx / base fee 4.18 gwei / 14,493,108 (48.3%) gas / (0x79b908af2969dc78e1b96580455b4c2ef14c964250d7c5a2d6864da17d8bf78d) in 18.487s. Peers: 23
2022-09-24 06:41:14.043+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,488 / 154 tx / base fee 4.16 gwei / 13,982,614 (46.6%) gas / (0xe92dd9a67ae3af3ccf0c2101492dbc708c35c4e726b6e20378baff82a554c7ce) in 2.559s. Peers: 19
...
2022-09-24 06:49:30.067+00:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x8c8904366243d7d1bc7e574dda3c296e6f7009acf19e4ddede096471063d5dc2, finalized: 0x11ce949be885a32bcf6cd4b58dd35d43664a4bf1e801da2b8666fa763e54eb25, safeBlockHash: 0x058f084329a115c1194b59e52bf5883fc4a5c1d286da3c365f5d2e61c56b26ed
2022-09-24 06:49:30.754+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,530 / 24 tx / base fee 4.39 gwei / 1,894,558 (6.3%) gas / (0x96c556c219b4e147df717c8885be775839718ebf997d58c7e3b537eeec0ecff6) in 0.397s. Peers: 18
2022-09-24 06:49:40.151+00:00 | vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-eventloop-thread-1,5,main] has been blocked for 6937 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
        at java.base@11.0.16/java.lang.Long.valueOf(Long.java:1180)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.RetryDelayFunction.lambda$linear$0(RetryDelayFunction.java:27)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.RetryDelayFunction$$Lambda$959/0x000000084067e840.apply(Unknown Source)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController$PeerInteractionState.execute(PeerDiscoveryController.java:718)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.dispatchInteraction(PeerDiscoveryController.java:572)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.bond(PeerDiscoveryController.java:509)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController$$Lambda$963/0x000000084067c840.performBonding(Unknown Source)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.RecursivePeerRefreshState.bondingInitiateRound(RecursivePeerRefreshState.java:117)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.RecursivePeerRefreshState.onNeighboursReceived(RecursivePeerRefreshState.java:213)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.lambda$onMessage$2(PeerDiscoveryController.java:333)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController$$Lambda$1267/0x000000084076bc40.accept(Unknown Source)
        at java.base@11.0.16/java.util.Optional.ifPresent(Optional.java:183)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.onMessage(PeerDiscoveryController.java:331)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent.lambda$handleIncomingPacket$4(PeerDiscoveryAgent.java:298)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent$$Lambda$1034/0x00000008406a8c40.accept(Unknown Source)
        at java.base@11.0.16/java.util.Optional.ifPresent(Optional.java:183)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent.handleIncomingPacket(PeerDiscoveryAgent.java:298)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent.lambda$handlePacket$10(VertxPeerDiscoveryAgent.java:297)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent$$Lambda$1027/0x000000084069c840.handle(Unknown Source)
        at app//io.vertx.core.impl.future.FutureImpl$3.onSuccess(FutureImpl.java:141)
        at app//io.vertx.core.impl.future.FutureBase.lambda$emitSuccess$0(FutureBase.java:54)
        at app//io.vertx.core.impl.future.FutureBase$$Lambda$684/0x00000008404a4440.run(Unknown Source)
        at app//io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
        at app//io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
        at app//io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:391)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
        at app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base@11.0.16/java.lang.Thread.run(Thread.java:829)
2022-09-24 06:50:11.239+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,531 / 166 tx / base fee 3.91 gwei / 29,983,389 (99.9%) gas / (0xe27b739c14e6ccae5a1bd6333250088979ecdc5a86e7f6f9e1eebe58a580fd03) in 31.049s. Peers: 19
2022-09-24 06:50:14.135+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,532 / 54 tx / base fee 4.40 gwei / 5,364,182 (17.9%) gas / (0x2f7e826ed2b3acb5ef5a5392ad7fc03cb72a248bc7a9c7a036cb8b95bf8fd220) in 1.575s. Peers: 20
2022-09-24 06:50:24.256+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,533 / 129 tx / base fee 4.05 gwei / 12,725,085 (42.4%) gas / (0xfaae581168f28255afda68ae6bec42b072db41b31cf90a4f737d53b99df00a66) in 2.621s. Peers: 18
2022-09-24 06:50:44.508+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,534 / 153 tx / base fee 3.97 gwei / 13,837,707 (46.1%) gas / (0x7895058c7b41098525458510f1867d1c6113d33dbbbeda06b6aafdbf1e177653) in 19.381s. Peers: 20
2022-09-24 06:50:45.265+00:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x7895058c7b41098525458510f1867d1c6113d33dbbbeda06b6aafdbf1e177653, finalized: 0x11ce949be885a32bcf6cd4b58dd35d43664a4bf1e801da2b8666fa763e54eb25, safeBlockHash: 0x058f084329a115c1194b59e52bf5883fc4a5c1d286da3c365f5d2e61c56b26ed
2022-09-24 06:50:55.495+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,535 / 111 tx / base fee 3.93 gwei / 12,393,685 (41.3%) gas / (0xdd01842b082c395c01fb944852b27f2bd4eb05689e91b8d6efc27b11c2fada50) in 9.717s. Peers: 17
2022-09-24 06:50:58.407+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,536 / 95 tx / base fee 3.84 gwei / 10,461,929 (34.9%) gas / (0x4db17509f3e031b9be472a6d4be65648086f2e7ee9f99785322f875d6164cb19) in 1.989s. Peers: 17
2022-09-24 06:51:07.490+00:00 | vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-eventloop-thread-1,5,main] has been blocked for 7652 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
        at app//org.apache.tuweni.units.bigints.UInt64.toBigInteger(UInt64.java:501)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PingPacketData.writeTo(PingPacketData.java:143)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.Packet.encode(Packet.java:138)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent.sendOutgoingPacket(VertxPeerDiscoveryAgent.java:171)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent.handleOutgoingPacket(PeerDiscoveryAgent.java:308)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent$$Lambda$951/0x0000000840677c40.send(Unknown Source)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.sendPacket(PeerDiscoveryController.java:524)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.lambda$bond$9(PeerDiscoveryController.java:502)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController$$Lambda$980/0x0000000840690440.accept(Unknown Source)
        at java.base@11.0.16/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
        at java.base@11.0.16/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
        at java.base@11.0.16/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent$VertxAsyncExecutor.lambda$execute$1(VertxPeerDiscoveryAgent.java:327)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent$VertxAsyncExecutor$$Lambda$983/0x0000000840691040.handle(Unknown Source)
        at app//io.vertx.core.impl.future.FutureImpl$3.onSuccess(FutureImpl.java:141)
        at app//io.vertx.core.impl.future.FutureBase.lambda$emitSuccess$0(FutureBase.java:54)
        at app//io.vertx.core.impl.future.FutureBase$$Lambda$684/0x00000008404a4440.run(Unknown Source)
        at app//io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
        at app//io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
        at app//io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:391)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
        at app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base@11.0.16/java.lang.Thread.run(Thread.java:829)
2022-09-24 06:51:28.093+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,537 / 45 tx / base fee 3.70 gwei / 29,493,661 (98.3%) gas / (0x7dd3f88faffc7e5ef8a7be32a86dccba7aedbd0a8a146296a7b7820838528955) in 20.540s. Peers: 17
2022-09-24 06:51:32.578+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,538 / 90 tx / base fee 4.15 gwei / 14,220,389 (47.4%) gas / (0x39d2f8b4eea589256cbe9377d6f45bf6f85ac1af215d2429103c57812bb50e3a) in 3.041s. Peers: 17
2022-09-24 06:51:52.430+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,539 / 158 tx / base fee 4.12 gwei / 19,300,691 (64.3%) gas / (0x520ca8ad786a2544808ae8e8558ca62beb711677502190a2fc7bb46c8c78bcb3) in 18.974s. Peers: 20
...
2022-09-24 06:57:30.100+00:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x477e7be773f289d246db5b55be6340e05c25342bacb49af38b2b225f08a3d38a, finalized: 0x058f084329a115c1194b59e52bf5883fc4a5c1d286da3c365f5d2e61c56b26ed, safeBlockHash: 0x1fd9193b10a9ca040725983549aa5c1a0265c1c3ea0c7a99bad46e02eaf1b1e0
2022-09-24 06:57:31.893+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,563 / 49 tx / base fee 4.27 gwei / 5,070,296 (16.9%) gas / (0x7d4f0c8c9c0abd0898a49efe8da5eea79ee13050a0b6e3c305cb436c7be470a8) in 1.278s. Peers: 20
2022-09-24 06:57:49.973+00:00 | vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-eventloop-thread-1,5,main] has been blocked for 7757 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
        at app//io.netty.channel.epoll.Native.epollWait0(Native Method)
        at app//io.netty.channel.epoll.Native.epollWait(Native.java:182)
        at app//io.netty.channel.epoll.EpollEventLoop.epollWait(EpollEventLoop.java:290)
        at app//io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:354)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
        at app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base@11.0.16/java.lang.Thread.run(Thread.java:829)
2022-09-24 06:57:50.352+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,564 / 53 tx / base fee 3.91 gwei / 7,285,983 (24.3%) gas / (0xd29e610ba25dba1eabe99413b61a39211a5cae0d0e53529234309dd45d632c51) in 17.619s. Peers: 23
2022-09-24 06:58:03.008+00:00 | vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-eventloop-thread-1,5,main] has been blocked for 6733 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.notifyPeerBonded(PeerDiscoveryController.java:421)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.addToPeerTable(PeerDiscoveryController.java:403)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.lambda$onMessage$1(PeerDiscoveryController.java:323)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController$$Lambda$1038/0x00000008406af040.accept(Unknown Source)
        at java.base@11.0.16/java.util.Optional.ifPresent(Optional.java:183)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.internal.PeerDiscoveryController.onMessage(PeerDiscoveryController.java:320)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent.lambda$handleIncomingPacket$4(PeerDiscoveryAgent.java:298)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent$$Lambda$1034/0x00000008406a8c40.accept(Unknown Source)
        at java.base@11.0.16/java.util.Optional.ifPresent(Optional.java:183)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.PeerDiscoveryAgent.handleIncomingPacket(PeerDiscoveryAgent.java:298)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent.lambda$handlePacket$10(VertxPeerDiscoveryAgent.java:297)
        at app//org.hyperledger.besu.ethereum.p2p.discovery.VertxPeerDiscoveryAgent$$Lambda$1027/0x000000084069c840.handle(Unknown Source)
        at app//io.vertx.core.impl.future.FutureImpl$3.onSuccess(FutureImpl.java:141)
        at app//io.vertx.core.impl.future.FutureBase.lambda$emitSuccess$0(FutureBase.java:54)
        at app//io.vertx.core.impl.future.FutureBase$$Lambda$684/0x00000008404a4440.run(Unknown Source)
        at app//io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
        at app//io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
        at app//io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:391)
        at app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
        at app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base@11.0.16/java.lang.Thread.run(Thread.java:829)
2022-09-24 06:58:12.970+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,565 / 175 tx / base fee 3.66 gwei / 28,024,358 (93.4%) gas / (0xf979972dc63b850e3bff1212034bfb54e9bb94670aaa961e4d8f9f239fc57790) in 21.612s. Peers: 19
2022-09-24 06:58:22.567+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,566 / 56 tx / base fee 4.06 gwei / 5,975,358 (19.9%) gas / (0x6ecf0499f871b862dfd42f80f387013ddc391619d437b6cf60f61637e680664a) in 1.253s. Peers: 20
2022-09-24 06:58:46.922+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,567 / 196 tx / base fee 3.76 gwei / 27,554,493 (91.8%) gas / (0x5520b4ab97d431d016869ed6669ec79987640497ca417b0bf8ec871e73dd0ccb) in 23.831s. Peers: 20
2022-09-24 06:58:48.567+00:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x5520b4ab97d431d016869ed6669ec79987640497ca417b0bf8ec871e73dd0ccb, finalized: 0x058f084329a115c1194b59e52bf5883fc4a5c1d286da3c365f5d2e61c56b26ed, safeBlockHash: 0x1fd9193b10a9ca040725983549aa5c1a0265c1c3ea0c7a99bad46e02eaf1b1e0
2022-09-24 06:58:59.412+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,568 / 158 tx / base fee 4.15 gwei / 12,332,277 (41.1%) gas / (0x24584b120aba11ba256e362a33ff17701fb4125c31dc3dac197ae0406aea7463) in 10.528s. Peers: 19
2022-09-24 06:59:03.091+00:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #15,601,569 / 29 tx / base fee 4.06 gwei / 26,910,626 (89.7%) gas / (0x92a22812aa239b1dee02aca7ac282acc855ec4e378f428d9c2ac26438ff023e0) in 2.609s. Peers: 19

k top node
pool-7dnpdozsa-7b6m4   2013m        25%    13879Mi         100%
pool-7dnpdozsa-7b6mh   772m         9%     3310Mi          23%

The above could of been related to memory constraint.  I restarted besu-0 and memory at 65% but slowly climbing up. Currently 82%
I am going to try set Xmx and will report back

Restarted with -Xmx8g  and memory started at  7500Mi about 50% used. After approx an hour
pool-7dnpdozsa-7b6m4   1349m        17%    11705Mi         84%

Seems to be climbing...

Restarted with -Xmx8g and memory started at 7500Mi about 50% used. After approx an hour
pool-7dnpdozsa-7b6m4   1349m        17%    11705Mi         84%

Seems to be climbing...

Did you ever stabilize with this setting or do you think there is a memory leak that will eventually gobble any amount of gigs you throw at it?

Same or similar issue with v22.7.
ianaz-besu_node-1  | 2022-09-25 06:42:27.122+00:00 | vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-worker-thread-14,5,main] has been blocked for 89934 ms, time limit is 60000 ms
ianaz-besu_node-1  | io.vertx.core.VertxException: Thread blocked
ianaz-besu_node-1  | 	at java.base@11.0.16/jdk.internal.misc.Unsafe.park(Native Method)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1796)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3128)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1823)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1998)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.internal.methods.ExecutionEngineJsonRpcMethod.response(ExecutionEngineJsonRpcMethod.java:89)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.BaseJsonRpcProcessor.process(BaseJsonRpcProcessor.java:42)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.TracedJsonRpcProcessor.process(TracedJsonRpcProcessor.java:41)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.TimedJsonRpcProcessor.process(TimedJsonRpcProcessor.java:45)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.AuthenticatedJsonRpcProcessor.process(AuthenticatedJsonRpcProcessor.java:51)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.jsonrpc.execution.JsonRpcExecutor.execute(JsonRpcExecutor.java:91)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler.lambda$handler$8(JsonRpcExecutorHandler.java:79)
ianaz-besu_node-1  | 	at app//org.hyperledger.besu.ethereum.api.handlers.JsonRpcExecutorHandler$$Lambda$744/0x0000000840513840.handle(Unknown Source)
ianaz-besu_node-1  | 	at app//io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
ianaz-besu_node-1  | 	at app//io.vertx.ext.web.impl.BlockingHandlerDecorator$$Lambda$1159/0x0000000840695040.handle(Unknown Source)
ianaz-besu_node-1  | 	at app//io.vertx.core.impl.ContextImpl.lambda$null$0(ContextImpl.java:159)
ianaz-besu_node-1  | 	at app//io.vertx.core.impl.ContextImpl$$Lambda$978/0x000000084060e040.handle(Unknown Source)
ianaz-besu_node-1  | 	at app//io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:100)
ianaz-besu_node-1  | 	at app//io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:157)
ianaz-besu_node-1  | 	at app//io.vertx.core.impl.ContextImpl$$Lambda$976/0x000000084060d440.run(Unknown Source)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
ianaz-besu_node-1  | 	at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
ianaz-besu_node-1  | 	at java.base@11.0.16/java.lang.Thread.run(Thread.java:829)

I had --Xplugin-rocksdb-high-spec-enabled but not sure if relevant

The devs seem to be tracking a memory leak. I've restarted back on 22.7.3 with -Xmx8g and node memory currently at 96%. I suspect it will hit 100% again and lock up.  Awaiting hotfix to see if it can help.

Same issue, Besu was consuming ~80% of my CPU and RAM usage was almost 3/4 of total available (32GB)....

Had to kill the process and fallback to Geth + Lighthouse node I have as backup which has been working like clockwork, unlike my Besu + Lighthouse node 😅

There is a dev snapshot people have had some success with. I've installed and testing "22.7.4-SNAPSHOT".  Will see how that goes and report back

I have been seeing the same issue. Validator was not attesting to anything for many hours.
The machine has enough memory, but I do not know if the Java VM puts a limit to the usage.
Hardware monitoring during the time of missed attestations shows this:

For me 22.7.4 release and -Xmx8g seems to have resolved this issue. I am still missing a few attestations but could be other performance / client issues.
Im happy to this is closed from my side.

Same for me with 22.7.4, running since a bit after the release. Thanks!

Same here. Sysload dropped even further.

marking as closed, fixed by #4415

authors: b-m-f gamell garyschulte ianaz nhlroyrocks stefanlsd


text:
Run Benchmark with Distributed Clients

Context

I followed the Distributed Clients steps : node ./src/comm/client/zoo-client.js zookeeper-server
but can not continue to step 4, just stay in the following state.
what should I do next or what else do I need to configure?
Expected Behavior

Connected to ZooKeeper
Created client node:/caliper/clients/client_1514532063571_0000000006
Created receiving queue at:/caliper/client_1514532063571_0000000006_in
Created sending queue at:/caliper/client_1514532063571_0000000006_out
Waiting for messages at:/caliper/client_1514532063571_0000000006_in......
Actual Behavior

Connected to ZooKeeper
Created client node:/caliper/clients/client_1514532063571_0000000006
Created receiving queue at:/caliper/client_1514532063571_0000000006_in
Created sending queue at:/caliper/client_1514532063571_0000000006_out
Waiting for messages at:/caliper/client_1514532063571_0000000006_in......
Possible Fix

Steps to Reproduce

Existing issues

[ ] Stack Overflow issues
[ ] GitHub Issues
[ ] Rocket Chat history

Context

Your Environment

Version used:
Environment name and version (e.g. Chrome 39, node.js 5.4):zookeeper3.4.5
Operating System and version (desktop or mobile):ubuntu 16.04
Link to your project:

Just open another terminal, then run 'node main.js'.

authors: feihujiang vamdivd

repo: hyperledger/caliper


text:
[FABG 998]Integration tests

Integration tests include:  package cc, install cc, get installed cc package, query installed cc, approve cc, query approve cc, check commit readiness, commit cc, query committed cc
Signed-off-by: huangjiehua huangjiehua@aisino.com

hi @bstasyszyn. There are two Fabric-SDK-GO(Integeration Test), and one is  successful, but the other is canceled. The log turned out to be "Build not found" which is canceled. I would appreciate your help and advice as to what I should do next.

hi @bstasyszyn. There are two Fabric-SDK-GO(Integeration Test), and one is successful, but the other is canceled. The log turned out to be "Build not found" which is canceled. I would appreciate your help and advice as to what I should do next.

Not sure where this build came from. @troyronda do you know?

@bstasyszyn Not sure why this extra test run showed up.

@huangjiehua looks like this PR is ready. would you mind adding a DCO sign-off commit formatted with with your full name.
Signed-off-by: Legal Name <email-address>.

@huangjiehua looks like this PR is ready. would you mind adding/amending a DCO sign-off commit formatted with your full name.
Signed-off-by: Legal Name <email-address>.
Thanks very much and thanks again for your contribution.

Thank you for the review. After DCO sign-off, do I need to make a new PR?

@huangjiehua I noticed that your sign-off in your commit is huangjiehua <huangjiehua@aisino.com>. I was hoping you could include & format your full name in the commit sign-off.
Yes git commit --amend works.

@bstasyszyn @huangjiehua Looks like the merge commit has some linter errors that were missed in the PR linter check.
https://dev.azure.com/Hyperledger/Fabric-SDK-Go/_build/results?buildId=18949&view=logs&jobId=1c778e8e-596b-5a0a-22c2-460364725d7c&j=1c778e8e-596b-5a0a-22c2-460364725d7c&t=e316d21a-7c0e-5fb0-c3c7-045475225585

@bstasyszyn @huangjiehua Merge integration tests timed out after an hour, but looked like they were going to pass.

@troyronda , I fouond the problems.  Do I need to fix this in the new PR?

@huangjiehua I am not sure why the linter didn't run on this file in the original PR.
Your changes are merged, so a new PR with the fixes would be great. Thanks again!

authors: bstasyszyn huangjiehua troyronda

repo: hyperledger/fabric-sdk-go


text:
feat(gateway): add WithBlockNum option

Rationale
I have a use case where each organization has an application that listens to chaincode events through the gateway and react accordingly.
All events should be processed, even when starting the application after the other organizations.
Proposed changes
Currently the gateway only supports listening to new events, not existing ones, although the event client has such capability.
This PR introduces a new gateway option to let the user specify from which block to start listening to events.
Design choices
FromBlockSet is a flag since 0 would be a valid block number, we need to determine if the user has explicitly set a starting block number.

@andrew-coleman

authors: mblottiere troyronda


text:
fix: modify certificate alternate DNS duplication

Signed-off-by: zhj0811 zhaojian@peerfintech.cn

Thanks! Could you please provide some more context here - what is the issue? Is there a JIRA?

It is a tiny PR. The  X509v3 Subject Alternative Name result contains duplicate alternateNames when alternateNames using multi domain

Thanks for the PR.
The change looks correct to me but there needs to be a corresponding test update. Since the current code isn't working as intended, there's clearly a test gap that needs to be addressed.
ca_test.go contains the tests for SignCeritificate and I'd expect new assertions around line 230.

The PR does not affect the ca_test.go.  It is negligible.

Thanks for the PR.

The change looks correct to me but there needs to be a corresponding test update. Since the current code isn't working as intended, there's clearly a test gap that needs to be addressed.

ca_test.go contains the tests for SignCeritificate and I'd expect new assertions around line 230.

The PR does not affect the ca_test.go.  It is negligible.

I'll try to be more clear. The fix is fine but the pull request must include a corresponding update to the unit tests to ensure the issue is resolved and is not regressed.
To quote our contribution guidelines:  > Include unit and integration tests (or changes to existing tests) with every change.
Without a test update, the PR as written will not be merged.
Thanks.

@Mergifyio backport release-2.2

authors: sykesm zhaojianpeerfintech zhj0811

repo: hyperledger/fabric


text:
Re-establish the correct function of filterError

Description

A recent PR from @juliancarrivick-ibm ( #2177 ) inadvertently defeated the intended function of the filterError() function, which was to avoid error logging for benign conditions in certain cases. Unlike many other situations the PR fixed, these messages were correctly intended to be at the debug level only. This PR re-establishes the correct function (and eliminates tens of thousands of WARN messages from busywork logs), corrects the inline documentation and removes dead code that has been commented out.
Motivation and Context

Corrects a nit in PR #2177
How Has This Been Tested?

I have observed that the warnings no longer appear in interactive runs. This is a minor fix; I assume it will pass CI tests.
Checklist:

[x] I have added a Signed-off-by.
[x] I have either added documentation to cover my changes or this change requires no new documentation.
[x] I have either added unit tests to cover my changes or this change requires no new tests.
[x] I have run golint and have fixed valid warnings in code I have added or modified. This tool generates false positives so you may choose to ignore some warnings. The goal is clean, consistent, and readable code.

Signed-off-by: Bishop Brock bcbrock@us.ibm.com

Oops! Sorry about that!

LGTM, thanks

authors: bcbrock juliancarrivick-ibm srderson


text:
Add error codes to all ethconnect errors

Allocate unique integers to every error
Include in the errors when printed in the logs
Wherever possible retain the code-free error in the return on REST "error": "message goes here" JSON responses
Add a separate "code": "FFEC100049" on all rest responses
Add a separate "errorCode": "FFEC100049" on replies in the receipt store

Note leaving this in draft until #173 merges, and I can rebase on top of main.

Codecov Report

Merging #178 (79604c0) into main (475dc25) will decrease coverage by 0.23%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #178      +/-   ##
==========================================
- Coverage   97.40%   97.17%   -0.24%
==========================================
  Files          56       57       +1
  Lines        6622     6786     +164
==========================================
+ Hits         6450     6594     +144
- Misses        130      148      +18
- Partials       42       44       +2

Impacted Files
Coverage Δ

ethconnect/internal/messages/messages.go
86.95% <0.00%> (-13.05%)
:arrow_down:

ethconnect/internal/kafka/client.go
67.30% <0.00%> (-10.48%)
:arrow_down:

ethconnect/internal/kafka/kafkabridge.go
96.00% <0.00%> (-2.14%)
:arrow_down:

ethconnect/internal/kafka/kafkacommon.go
96.42% <0.00%> (-0.70%)
:arrow_down:

ethconnect/internal/rest/restgateway.go
93.71% <0.00%> (-0.08%)
:arrow_down:

ethconnect/internal/rest/webhooks.go
100.00% <0.00%> (ø)

ethconnect/internal/rest/resterror.go
100.00% <0.00%> (ø)

ethconnect/internal/kafka/clientmock.go
100.00% <0.00%> (ø)

ethconnect/internal/events/submanager.go
100.00% <0.00%> (ø)

ethconnect/internal/rest/receiptstore.go
100.00% <0.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

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

Merged back with main and ready for review fyi @vdamle @jimthematrix

Raised https://github.com/hyperledger/firefly-ethconnect/pull/183 after seeing an intermitting build issue (unrelated to this change).

authors: codecov-commenter peterbroadhurst

repo: hyperledger/firefly-ethconnect


text:
Increase handling of JSON Number large numbers (vs. string)

Builds on #76 to cover some additional important cases where consumers of this library use types that need to support:

Scientific notation in JSON structure
The possibility of JSON Number encoded (vs. string) large numbers

The code does cause errors in some previously ignored scenarios that would result in bad numbers:

Attempting to parse a HexUint64 from a number larger than 18446744073709551615
Attempting to parse a HexUint64 from a fractional number like 1.2345

Thanks for covering these cases that I didn't in the original PR @peterbroadhurst. They look good to me with the exception of @EnriqueL8 's comment. I'll leave him to approve it once that comment has been resolved.

repo: hyperledger/firefly-signer


text:
[feature] #3435: Introduce validator visitor

Description
syn::visit::Visit inspired visitor for validator.
By the principle of least surprise the default implementation of Validate trait passes for every entity.
Users can copy the code in default_validator and adjust it to their own needs if the require some sensible defaults
Linked issue
Closes  #3435
Benefits

It's easy for the writer of validator to plug in their own validation
users get to share state during validation

Checklist

[ ] I've read CONTRIBUTING.md
[ ] I've used the standard signed-off commit format (or will squash just before merging)
[ ] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

There are two semantically distinct default validators:

Default implementation validator - consequence of default implementations on trait methods
Example validator - one that we use in tests, something sensible that we can work with on a live blockchain

We have two options on how to implement these defaults:

Have the 1st validator to always pass any validation. We essentially don't provide any default for the user. The validator only visits every node in the validation tree and does nothing. The user will then plug in their own validation where they see fit. This is essentially how syn::visit::Visit works. Our current default_validator crate will remain as it is currently, providing custom validation and tokens. In this scenario default and example validators are distinct
Have only 1st validator but with defaults from the 2nd validator. This is what we have now. The default validator would not only visit every node, but it would also perform some actual validation. Our current default_validator crate will be mostly empty as it's only there to define entrypoint function, default validation is given by implementing

To sum up. The question is what are the contents of Validate trait and what are the contents of default_validator crate (I would rather rename this crate into example_validator)

This approach is interesting and solves two problems:
1. Convenient usage of default implementation (however I have a question about it, see below)

2. Validator state

As a downside I don't like having a lot of mehtods in just one trait, but I can't suggest anything better.

Validator trait can be split into multiple traits, like ValidateInstruction/ValidateQuery. I tried and dislike that approach. We can try that in after this PR is merged

I don't agree about renaming into example_validator. In my mind Iroha should provide a default configuration to work out of the box. So in our tests we should test this configuration (or very close to it).

I haven't renamed it

I haven't renamed it

Yeah, but you noticed that idea in the comment above

Also, please, update client/tests/integration/smartcontracts/validator_with_admin to a more convinient look

authors: Arjentix mversic

repo: hyperledger/iroha


text:
[documentation]: Release roadmap

The proposed release roadmap submitted for review as a recommendation.

Thank you. This is an excellent roadmap, please address my questions, I believe some clarification may help others.

@Erigara

In general I agree with need to refactor of ISI

Thank you.

however i have some doubts about blaming WASM in most of our problems. Would like to see RFC with further considerations.

I would like to clarify this a bit. We can still do what we want to do with WASM. We can do it with any binary format. Most binary formats are "good enough". However, I don't think that the trade-offs have been considered well and that we can do far better than WASM. I have not done a detailed comparison which would make my point clear, this will come later.

I would like to clarify this a bit. We can still do what we want to do with WASM. We can do it with any binary format. Most binary formats are "good enough". However, I don't think that the trade-offs have been considered well and that we can do far better than WASM. I have not done a detailed comparison which would make my point clear, this will come later.

@appetrosyan as you may know there was similar comparison in the past, please don't hesitate addressing some points/comments from there too https://wiki.hyperledger.org/display/iroha/Scripting+Languages+and+Runtimes+for+Iroha2+Smart+Contracts

Moved to https://github.com/hyperledger/iroha-rfcs/pull/6

authors: 6r1d Mingela appetrosyan


text:
Add Blocks at a Configured Depth to Pruning Queue

This PR creates a pruning manager, which prunes state roots from a queue at predictable times.  It is evaluated at chain commit time. 10 percent of the queue is pruned, which allows state roots to be returned to validity, if need be before they are finally pruned.
This PR does not solve the problem of abandoned forks, as they cannot be properly re-evaluated if a validator switches back to them. To properly cleanup state after a chain has been dropped, we will need the Block Tree Manager (See RFC 5).  When uncommitted blocks expire from the Block Tree Manager, their state roots can be pruned.

Oh, commit Add decimate to StatePruneManager has If a root is prune, in the commit message (prune -> pruned).

Added some new commits to handle the issue where an identical leaf is produced, and then is pruned from a prior state root hash.  This approach is the most direct - scanning the change logs.
Future changes could make this more efficient by managing this with an in-memory reference count.

authors: nick-drozd peterschwarz

repo: hyperledger/sawtooth-core


text:
Searching people in Organization view doesn't work

Bug
how do we show search results in people page, org view?

Expected behavior
Searching for a person in org chart view should do something

Actual behavior
switching the people page to Org view and then entering a valid name will cause the search bar icon to spin for a few seconds and then stop.  Seems to do nothing.

Repro steps
see above

Build
can't tell for some reason...   maybe #822 reasons...

Severity
2. blocks functionality

Details/Notes
Should doing a query in the "All People" view and getting a result have any impact on the view when I switch to "Org view"??  They are currently disconnected...  Even when I search for a person and select that person (so that the right pane switches to their name) -- when I then change to org view, it is back to being centered on me.

At the very least, if we can't figure out how to display results maybe we should disable search in Org view?

migrated to new tmobile/sawtooth-next-directory repo

repo: hyperledger/sawtooth-next-directory


text:
[User Story] Data Model - Data Queried by User ID

[User Story]
Data Model - Data Queried by User ID

Epic Title

User Story Title
Data Model - Data Queried by User ID

T-shirt size: S(mall), M(edium), L(arge)
M

User Story
Data Model - Data Queried by User ID

Description
Data that needs to be queried by User ID

Details

Additional User Story

Dependencies

Assumptions

Questions/Clarifications

pretty sure we have this one too.

authors: PatrickLammers adamgering


text:
Screen freezes randomly

When logging into hyprland, randomly the screen will freeze and no updates to the screen are visible. Sometimes this happens a few minutes after startup, sometimes there is not a problem all day. I'm still able to interact with the system. I'm able to kill Hyprland or reboot the system by mimicking the key presses I would normally use, however, nothing changes on the screen. No terminal pops up and the mouse doesn't move. Running this on arcolinux (arch derivative). Attached is the hyprland log file
hyprlandLog.txt, the crash report
hyprlandCrashReport2792.txt, and my config file
hyprland.txt.
Not sure if the crash report is referring to when I am forced to exit Hyprland. Therefore, coredumpctl does not give any PIDs for me to post the info of.  Please let me know if I can provide any more information. I switched from the linux-lts kernel to the standard linux kernel before writing this. So far, it seems as if there has been no freezing issues, however, as I mentioned the freezing happens at random it seems.

post the log from hyprland launched with HYPRLAND_LOG_WLR=1  pleas

Attached is the log file and the bash script I used to execute Hyprland with the environment variable set
hyprlandLog2.txt
hyprland_exec.txt

Installed base arch and the problem is no longer there. I'm going to assume this is an arcolinux problem ( maybe some weird default values). However, since I've installed the new system I can no longer help debug, will close this issue.

I have the same problem on a new Arch system. At first it wasn't doing that but IDK if I did something wrong with the config but now it crashes 2-4 times per hour.

Nevermind, might be an issue with amdgpu as we both have an AMD gpu and it also happened on XFCE4

Nevermind, might be an issue with amdgpu as we both have an AMD gpu and it also happened on XFCE4

I also have AMD gpu, and hyprland freezes randomly once or twice in a day. dunno why.

It's been a long time since I haven't got screen freezes. It was probably an issue with amdgpu. Is your system up to date ? Personally, I'm running Arch Linux, so I have a pretty recent amdgpu package (23.1.4).

repo: hyprwm/Hyprland


text:
Wallpaper not set on full screened video when swiping workspace

Hyprland Version
v0.27.2
Bug or Regression?
Bug
Description
when i swipe workspace on full screened video the wallpaper is black and not what i set with swaybg
During the swiping transition the wallpaper is black
How to reproduce
full screen any YouTube video and swipe with touchpad to another workspace
Crash reports, logs, images, videos
No response

aint this fixed in -git?

i'm on stable
I don't know maybe?

it was fixed with https://github.com/hyprwm/Hyprland/commit/f4f0f35c5b2725189563fc65e17a0141fd801eb7

Thank you

authors: MiniApollo vaxerski


text:
[force_zero_scaling] Context menus open first in the wrong place

Hyprland Version
Hyprland, built from branch main at commit 51cda87fe47efec25265b3b9f6bebf9a0882aa08 dirty (hyprctl: rerender on cursor_zoom_factor dynamic calls). Tag: v0.27.2-64-g51cda87f
Bug or Regression?
Bug
Description
Opening a XWayland context menu when using force_zero_scaling, it shows up in the wrong place. If I close and reopen it, the menu appears in the correct place.
How to reproduce

Open Steam with force_zero_scaling
try to open a context menu
observe wrong place
close and reopen
observe correct place

Crash reports, logs, images, videos
Logs for hovering over Profile (opens at wrong position), unhovering, and rehovering (opens at correct position):
[LOG] Set keyboard focus to surface 555fbaa0a7c0, with window name: Steam
[LOG] Registered signal for owner 555fb99b5270: 555fb9553be0 -> 555fb99b52d8 (owner: XWayland Window)
[LOG] Registered signal for owner 555fb99b5a90: 555fb9553c10 -> 555fb99b5a98 (owner: CWLSurface)
[LOG] CWLSurface 555fb99b5a90 called init()
[LOG] Registered signal for owner 555fb99b5270: 555fb9553bf0 -> 555fb99b5340 (owner: CWindow)
[LOG] Searching for matching rules for steam (title: )
[LOG] Window got assigned a surfaceTreeNode 0
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde30 -> 555fb99b54e0 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde40 -> 555fb99b5750 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde70 -> 555fb99b5410 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde10 -> 555fb99b5618 (owner: Xwayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde20 -> 555fb99b5680 (owner: Xwayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fdf20 -> 555fb99b5478 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb995d850: 555fb9553c00 -> 555fb995d8c8 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 555fb995d850: 555fb9553bd0 -> 555fb995d930 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 555fb995d850: 555fb9553c10 -> 555fb995d998 (owner: SurfaceTreeNode)
[LOG] Creating a surfaceTree Root! (pWindow: 555fb99b5270)
[LOG] Map request dispatched, monitor eDP-2, xywh: 454.400000 408.800000 72.000000 184.800000
[LOG] Unmanaged window 555fb99b5270 requests geometry update to 575 511 90 231
[LOG] Window 555fb99b5270 unmapped (class steam)
[LOG] Unregistered late callbacks XWL
[LOG] Callback 555fb99b5508 -> 555fb99b5500, XWayland Window Late removed.
[LOG] Callback 555fb99b5778 -> 555fb99b5770, XWayland Window Late removed.
[LOG] Callback 555fb99b5438 -> 555fb99b5430, XWayland Window Late removed.
[LOG] Callback 555fb99b54a0 -> 555fb99b5498, XWayland Window Late removed.
[LOG] Callback 555fb99b56a8 -> 555fb99b56a0, Xwayland Window Late removed.
[LOG] Callback 555fb99b5640 -> 555fb99b5638, Xwayland Window Late removed.
[LOG] Unmapped was not focused, ignoring a refocus.
[LOG] Destroying the SubSurface tree of unmapped window 555fb99b5270
[LOG] Callback 555fb995d958 -> 555fb995d950, SurfaceTreeNode removed.
[LOG] Callback 555fb995d9c0 -> 555fb995d9b8, SurfaceTreeNode removed.
[LOG] Callback 555fb995d8f0 -> 555fb995d8e8, SurfaceTreeNode removed.
[LOG] SurfaceTree Node removed
[LOG] Callback 555fb99b5ac0 -> 555fb99b5ab8, CWLSurface removed.
[LOG] CWLSurface 555fb99b5a90 called destroy()
[LOG] Callback 555fb99b5368 -> 555fb99b5360, CWindow removed.
[LOG] Callback 555fb99b5300 -> 555fb99b52f8, XWayland Window removed.
[LOG] Registered signal for owner 555fb99b5270: 555fb9553be0 -> 555fb99b52d8 (owner: XWayland Window)
[LOG] Registered signal for owner 555fb99b5a90: 555fb9553c10 -> 555fb99b5a98 (owner: CWLSurface)
[LOG] CWLSurface 555fb99b5a90 called init()
[LOG] Registered signal for owner 555fb99b5270: 555fb9553bf0 -> 555fb99b5340 (owner: CWindow)
[LOG] Searching for matching rules for steam (title: )
[LOG] Window got assigned a surfaceTreeNode 0
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde30 -> 555fb99b54e0 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde40 -> 555fb99b5750 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde70 -> 555fb99b5410 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde10 -> 555fb99b5618 (owner: Xwayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fde20 -> 555fb99b5680 (owner: Xwayland Window Late)
[LOG] Registered signal for owner 555fb99b5270: 555fb94fdf20 -> 555fb99b5478 (owner: XWayland Window Late)
[LOG] Registered signal for owner 555fb995d850: 555fb9553c00 -> 555fb995d8c8 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 555fb995d850: 555fb9553bd0 -> 555fb995d930 (owner: SurfaceTreeNode)
[LOG] Registered signal for owner 555fb995d850: 555fb9553c10 -> 555fb995d998 (owner: SurfaceTreeNode)
[LOG] Creating a surfaceTree Root! (pWindow: 555fb99b5270)
[LOG] Map request dispatched, monitor eDP-2, xywh: 460.000000 408.800000 72.000000 184.800000
[LOG] Window 555fb99b5270 unmapped (class steam)
[LOG] Unregistered late callbacks XWL
[LOG] Callback 555fb99b5508 -> 555fb99b5500, XWayland Window Late removed.
[LOG] Callback 555fb99b5778 -> 555fb99b5770, XWayland Window Late removed.
[LOG] Callback 555fb99b5438 -> 555fb99b5430, XWayland Window Late removed.
[LOG] Callback 555fb99b54a0 -> 555fb99b5498, XWayland Window Late removed.
[LOG] Callback 555fb99b56a8 -> 555fb99b56a0, Xwayland Window Late removed.
[LOG] Callback 555fb99b5640 -> 555fb99b5638, Xwayland Window Late removed.
[LOG] Unmapped was not focused, ignoring a refocus.
[LOG] Destroying the SubSurface tree of unmapped window 555fb99b5270
[LOG] Callback 555fb995d958 -> 555fb995d950, SurfaceTreeNode removed.
[LOG] Callback 555fb995d9c0 -> 555fb995d9b8, SurfaceTreeNode removed.
[LOG] Callback 555fb995d8f0 -> 555fb995d8e8, SurfaceTreeNode removed.
[LOG] SurfaceTree Node removed
[LOG] Callback 555fb99b5ac0 -> 555fb99b5ab8, CWLSurface removed.
[LOG] CWLSurface 555fb99b5a90 called destroy()
[LOG] Callback 555fb99b5368 -> 555fb99b5360, CWindow removed.
[LOG] Callback 555fb99b5300 -> 555fb99b52f8, XWayland Window removed.

Video showing the issue:
https://github.com/hyprwm/Hyprland/assets/44881120/03b0db7a-de19-4882-ba9b-4f28f6130a27

Focusing the window and resizing it (fullscreen toggle for instance) fixes the issue.  I see it with minecraft launcher all the time.

This is not happening anymore. Closing.


text:
Freeze when closing or switching from an app that tears

Hyprland Version
Hyprland, built from branch main at commit a2a29a60e5301df2cadf58c1bb18495d02710547 dirty (tearing: cleanup vars and avoid rendering before drm is ready).
Bug or Regression?
Bug
Description
The desktop freezes when switching from a fullscreen app that tears to one that doesn't.
9 out of 10 times it will freeze instead of switching. Closing the app has the same result.
Is caused by https://github.com/hyprwm/Hyprland/commit/a2a29a60e5301df2cadf58c1bb18495d02710547#diff-b12458cc1c330ab36cf13b6652d2babf94b8dc91408d83a8d3ec48ef238ca156R156-R157
How to reproduce
Have tearing enabled on a fullscreen app (vrrtest in my case) on one workspace and attempt to switch to another workspace. Usually will freeze the desktop but sometimes it will be successful
Crash reports, logs, images, videos
No response

the "don't leave fullscreen on new window" is on purpose

the "don't leave fullscreen on new window" is on purpose
That's not what I'm seeing here.

First of all this only happens if I visually can see tearing, VRR has to be disabled. VRRTest is just the easiest app to verify that.
When VRRTest is running and tearing on fullscreen on workspace 1, trying to switch to workspace 2 (that has nothing open) will more often than not stop the rendering of my desktop and show me a stop frame of VRRTest. Mouse is also frozen.
While in that state, switching back to the workspace 1 will resume the rendering, VRRTest is still running, I can move my mouse.
Doing it over and over I'm sometimes able to successfully switch to workspace 1 and see my wallpaper
Just closing the VRRTest will also cause this and I haven't found a way of recovering from that requiring me to kill Hyprland.
I've used windowrulev2 = immediate,class:(love) to force tearing in VRRTest
I just found that out - sometimes it just work as it should. But restarting Hyprland will cause the bug to appear again.

check with 230356012be03412db78a9e85c711ec878fd0a69

It's fixed, thanks!

authors: FakeMichau vaxerski


text:
Hyprland freezes up laptop if I switch to another tty and back to hyprlands tty

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit 54a8329936d31537411c7a1a4d1815820b98316a dirty (layout: Fixed ghost window when opened while fullscreen on a different workspace (4822)).
Date: Sun Feb 25 14:09:41 2024
Tag: v0.35.0-96-g54a83299

flags: (if any)

System Information:
System name: Linux
Node name: justine-laptop
Release: 6.7.6-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Fri, 23 Feb 2024 16:31:48 +0000

GPU information:
07:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [Radeon RX Vega 6 (Ryzen 4000/5000 Mobile Series)] [1002:1636] (rev d1) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

plugins:

Bug or Regression?
Bug
Description
I though the issue was Hyprlock as I was testing it but discovered without Hyprlock I can reproduce the total freeze i.e no keyboards or input devices work and the display no longer updates.
To induce it say I start Hyprland on tty2 and then switch to tty1 and back it freezes. The only way to recover is to power off the laptop.
I tried the same on river and sway and it works fine for them.
How to reproduce
Start Hyprland on tty2 then switch to say tty1 and back and it freezes.
Crash reports, logs, images, videos
No response

log please?

I tried to find the crash log but there is none it's as if the system total freezes.
There is only the startup log in /tmp/hypr/54a8329936d31537411c7a1a4d1815820b98316a_1708893335/hyprland.log
[LOG] Instance Signature: 54a8329936d31537411c7a1a4d1815820b98316a_1708893335
[LOG] Hyprland PID: 890
[LOG] ===== SYSTEM INFO: =====
[LOG] System name: Linux
[LOG] Node name: justine-laptop
[LOG] Release: 6.7.6-arch1-1
[LOG] Version: #1 SMP PREEMPT_DYNAMIC Fri, 23 Feb 2024 16:31:48 +0000

[LOG] GPU information:
07:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [Radeon RX Vega 6 (Ryzen 4000/5000 Mobile Series)] [1002:1636] (rev d1) (prog-if 00 [VGA controller])

[LOG] os-release:
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

[LOG] ========================

[INFO] If you are crashing, or encounter any bugs, please consult https://wiki.hyprland.org/Crashes-and-Bugs/

[LOG]
Current splash: "stop playing league loser" - hyprBot

[LOG] Creating the HookSystem!
[LOG] Creating the KeybindManager!
[LOG] [hookSystem] New hook event registered: configReloaded
[LOG] Creating the AnimationManager!
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 57.17µs. Estimated average calc time: 0.07µs.
[LOG] Creating the ConfigManager!
[LOG] NOTE: further logs to stdout / logfile are disabled by default. Use debug:disable_logs and debug:enable_stdout_logs to override this.
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 29.08µs. Estimated average calc time: 0.07µs.
[LOG] Using config: /home/justine/.config/hypr/hyprland.conf

But that is of no use as it's for this session I'm typing on.
Any advice / help would be very much appreciated.

It maybe something in my config as I rename my hyprland.conf to hyprland.conf.old and started up again and switching to tty1 and back to tty2 work as expected. So I'll go examine the rest of mu config commenting out things one by one until I hopefully find the culprit.

I have read Crashes and Bugs and there are no other past logs present ever for some reason ??

Read the 3rd to last line...
[LOG] NOTE: further logs to stdout / logfile are disabled by default. Use debug:disable_logs and debug:enable_stdout_logs to override this.

I cannot see anything wrong as yet but my dots are here if it helps someone else see what I have or have not done to my Hyprland config ?

me neither, but I'll leave the examination to you. Lmk if you find the culprit

I'll

I have read Crashes and Bugs and there are no other past logs present ever for some reason ??

Read the 3rd to last line...
[LOG] NOTE: further logs to stdout / logfile are disabled by default. Use debug:disable_logs and debug:enable_stdout_logs to override this.

@vaxerski  How do I debug:enable_stdout_logs ? Could you please give me an example ? Thanks in advance.

debug {
    disable_logs = false
}

Happens when defined custom resolution and refresh rate.
Freeze:
monitor = HDMI-A-1, 1920x1080@75, 0x0, 1
monitor = HDMI-A-1, 1920x1080@75, auto, 1
monitor = HDMI-A-1, 1920x1080@75.002998, 0x0, 1
Work as expected (no freeze):
monitor = HDMI-A-1, preferred, auto, 1
monitor = HDMI-A-1, highrr, 0x0, 1
Log has nothing useful as it stops after [LOG] Session got activated! when freezed.
Stable version works as expected with any config variation from above.
Bisect result: d62e7a5125c551fe8a94e076e64d42b702d923b1 is the first bad commit

can someone ssh into the frozen computer, do sudo gdb attach $(pidof Hyprland) and share bt -full?

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007995f803888d in syscall () from /usr/lib/libc.so.6
(gdb) bt -full
#0  0x00007995f803888d in syscall () at /usr/lib/libc.so.6
#1  0x00007995f448557e in ??? ()
    at /usr/lib/dri/radeonsi_dri.so
#2  0x00007995f4c37e5a in ??? ()
    at /usr/lib/dri/radeonsi_dri.so
#3  0x00007995f4996c7f in ??? ()
    at /usr/lib/dri/radeonsi_dri.so
#4  0x00007995f4636006 in ??? ()
    at /usr/lib/dri/radeonsi_dri.so
#5  0x00005b44b449f2f9 in CHyprRenderer::endRender() ()
#6  0x00005b44b4496ede in CHyprRenderer::renderMonitor(CMonitor*) ()
#7  0x00005b44b441677b in handleWrapped(wl_listener*, void*) ()
#8  0x00007995f89f701e in wl_signal_emit_mutable ()
    at /usr/lib/libwayland-server.so.0
#9  0x00007995f89f8a23 in wl_event_loop_dispatch_idle ()
    at /usr/lib/libwayland-server.so.0
#10 0x00007995f89f8b3d in wl_event_loop_dispatch ()
    at /usr/lib/libwayland-server.so.0
#11 0x00007995f89f92d7 in wl_display_run ()
    at /usr/lib/libwayland-server.so.0
#12 0x00005b44b4354b2a in main ()
(gdb)

Happens when defined custom resolution and refresh rate. Freeze: monitor = HDMI-A-1, 1920x1080@75, 0x0, 1 monitor = HDMI-A-1, 1920x1080@75, auto, 1 monitor = HDMI-A-1, 1920x1080@75.002998, 0x0, 1 Work as expected (no freeze): monitor = HDMI-A-1, preferred, auto, 1 monitor = HDMI-A-1, highrr, 0x0, 1
Log has nothing useful as it stops after [LOG] Session got activated! when freezed. Stable version works as expected with any config variation from above.
Bisect result: d62e7a5 is the first bad commit

I can confirm that if I set my resolutions as explained above everything works correctly and Hyprland does not freeze when switching tty. But then my resolutions are wrong so
Normaly I have in my hyprland.conf
monitor=eDP-1,1920x1080,1920x0,1
monitor=HDMI-A-1,1920x1080,0x0,1

But this makes Hyprland freeze with no logs if I switch tty and back to Hyprlands tty. But if I change that config to:
monitor=eDP-1,preferred, auto,1
monitor=HDMI-A-1,highrr,0x0,1

Then I can safely switch back and forth between tty but my resolutions are wong on the HDMI screen.

patch69.txt
try

Patch works. Though log now has some errors when switching from Hyprland tty to another tty, not sure if it's relevant.

Same here. It works and I have errors in the logs but I don't see anything wrong on the desktop.
hyprland.log

Just an FYI setting my monitors using the following works and gives me my normal 1920x1080 although you should really be able to manually set them with out issue.
# Original setting that freezes Hyprland on switching tty and back
# monitor=eDP-1,1920x1080,1920x0,1
# monitor=HDMI-A-1,1920x1080,0x0,1
# Below works allowing me to switch back and forth tty and gives me 1920x1080
monitor=eDP-1,preferred, auto,1
monitor=HDMI-A-1,preferred, 0x0,1

can you check latest I think a dupe got fixed

can you check latest I think a dupe got fixed

I've put back my original config and it does indeed work so this can be closed if everyone else is happy ?
Thank you @vaxerski

Is this supposed to be fixed in 0.36 ? I still have the issue, and the patch fixes it.

can you check latest I think a dupe got fixed

@vaxerski Can you confirm?
I have the same problem and just tested that it is not fixed on main but applying the patch does still fix the problem.
For anyone else that runs across this on Nix, you can fix it with an overlay that applies the patch:
patches/hyprland/000-fix-tty-switching.txt:
diff --git a/src/events/Misc.cpp b/src/events/Misc.cpp
index b77cf038..eaaaec18 100644
--- a/src/events/Misc.cpp
+++ b/src/events/Misc.cpp
@@ -169,6 +169,7 @@ void Events::listener_sessionActive(wl_listener* listener, void* data) {

     for (auto& m : g_pCompositor->m_vMonitors) {
         g_pCompositor->scheduleFrameForMonitor(m.get());
+        g_pHyprRenderer->applyMonitorRule(m.get(), &m->activeMonitorRule, true);
     }

     g_pConfigManager->m_bWantsMonitorReload = true;

nixpkgs.overlays = [
  (_finalPkg: prevPkg: {
    hyprland = prevPkg.hyprland.overrideAttrs (_finalAttrs: previousAttrs: {
      patches = previousAttrs.patches ++ [
        ./patches/hyprland/000-fix-tty-switching.txt
      ];
    });
  })
];

I can commit the patch no prob

authors: 12paper FUFSoB constantitus justinesmithies silvanshade vaxerski


text:
GTK4 Popup Does Not Release Keyboard On Close

Hyprland Version
 System/Version info
Hyprland, built from branch  at commit 12985fa0d8e43b1e33326dfb49be681970dfaea5  ().
Date: 2024-03-05
Tag:
flags: (if any)
System Information:
System name: Linux
Node name: nixos
Release: 6.7.5
Version: #1-NixOS SMP PREEMPT_DYNAMIC Fri Feb 16 18:14:32 UTC 2024
GPU information:
63:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf] (rev c7) (prog-if 00 [VGA contr
olle
r])
os-release: BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="23.11.20240218.e0da498"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 23.11 (Tapir)"
SUPPORT_END="2024-06-30"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="23.11 (Tapir)"
VERSION_CODENAME=tapir
VERSION_ID="23.11"
plugins:

Bug or Regression?
Bug
Description
If you close GTK4 popup with keyboard (esc) while your mouse is focused on another window (terminal), keyboard does not work unless you focus into GTK4 app again with mouse.
How to reproduce

open GTK4 app
Open popup
Move your mouse to another window
Close popup with keyboard (esc)
Keyboard doesn't respond.

Crash reports, logs, images, videos
https://github.com/hyprwm/Hyprland/assets/20723848/d009062f-ac5d-4140-87e0-f8e3e49d7998

what's your config? I'd assume this is follows_mouse = 2?

no its follow_mouse = 1
my whole config:
monitor=eDP-1,2560x1600@90,auto,2
monitor=DP-1, 3840x2160@144,auto,2
monitor=DP-2, 3840x2160@144,auto,2

exec-once = dbus-hyprland-environment
exec-once = bash ~/.config/hypr/scripts/monitors.sh

$terminal = kitty
$app_menu = ~/.config/hypr/scripts/apps.sh
$browser = firefox
exec-once=hyprctl setcursor Bibata-Modern-Ice 24
exec-once=hyprctl dispatch exec [workspace 3 silent] $browser

exec-once = hyprpaper & hypridle & configure-gtk

exec-once=systemctl --user restart pulseaudio.service
exec-once=sway-audio-idle-inhibit

env = WLR_NO_HARDWARE_CURSORS,1
env = XCURSOR_SIZE,24
env = XCURSOR_THEME,capitaine-cursors
env = DESKTOP_SESSION,hyprland
env = XDG_SESSION_TYPE,wayland
env = GTK_USE_PORTAL,0
env = GTK_DEBUG,0

$base           = 0xff191724
$surface        = 0xff1f1d2e
$overlay        = 0xff26233a
$muted          = 0xff6e6a86
$subtle         = 0xff908caa
$text           = 0xffe0def4
$love           = 0xffeb6f92
$gold           = 0xfff6c177
$rose           = 0xffebbcba
$pine           = 0xff31748f
$foam           = 0xff9ccfd8
$iris           = 0xffc4a7e7
$highlightLow   = 0xff21202e
$highlightMed   = 0xff403d52
$highlightHigh  = 0xff524f67

env = XCURSOR_SIZE, 36

input {
    kb_layout = us
    kb_variant =
    kb_model =
    kb_options =
    kb_rules =

    follow_mouse = 1

    touchpad {
        natural_scroll = no
	scroll_factor = 0.2
	disable_while_typing = true
	drag_lock = true
	tap-and-drag = true
    }

    sensitivity = -0.2
    repeat_delay = 150
    repeat_rate = 90
}

device {
  name = steelseries-steelseries-rival-110-gaming-mouse
  sensitivity=-1.2
}

general {
    gaps_in = 5
    gaps_out = 20
    border_size = 0
    col.active_border = $rose $pine $love $iris
    col.inactive_border = $muted
    layout = dwindle
    allow_tearing = false
}

decoration {

rounding = 5

blur {
  enabled = false
  size = 5
  passes = 2
  new_optimizations = true
  special = true
  brightness = 0.9
}

  drop_shadow = false
  shadow_range = 3
  shadow_render_power = 1
  col.shadow = rgba(1a1a1aee)
}

animations {
    enabled = yes

    bezier = myBezier, 0.05, 0.9, 0.1, 1.05

    animation = windows, 1, 7, myBezier
    animation = windowsOut, 1, 7, default, popin 80%
    #animation = border, 1, 10, default
    animation = borderangle, 1, 8, default
    animation = fade, 1, 7, default
    animation = workspaces, 0, 5, default
}

dwindle {
    pseudotile = yes # master switch for pseudotiling. Enabling is bound to mainMod + P in the keybinds section below
    preserve_split = yes # you probably want this
}

master {
    new_is_master = true
}

gestures {
    workspace_swipe = off
}

misc {
    force_default_wallpaper = 0
    disable_splash_rendering = true
    disable_hyprland_logo = true
}

windowrulev2 = size 500 500, title: Save Image
windowrulev2 = center, title: Save Image
windowrulev2 = center, title: Save As
windowrulev2 = size 500 500, title: Save As
windowrulev2 = workspace 3, class:($browser)
windowrulev2 = workspace 2, class:($terminal)
windowrulev2 = workspace 1,title:^(lf)$
windowrulev2 = float, class:(swayimg)
windowrulev2 = center, class:(swayimg)
windowrulev2 = noborder, class:(swayimg)
windowrulev2 = workspace 5, class:(celluloid)
layerrule = unset, testing

$mainMod = SUPER

bind = $mainMod, T, exec, $terminal
bind = $mainMod, Q, killactive,
bind = $mainMod, B, exec, $browser
bind = $mainMod, SPACE, exec, $app_menu
bind = $mainMod, F, exec, $file_manager
bind = $mainMod, M, exit,

bind = $mainMod, H, movefocus, l
bind = $mainMod, L, movefocus, r
bind = $mainMod, K, movefocus, u
bind = $mainMod, J, movefocus, d

bind = $mainMod, 1, exec, hyprctl dispatch workspace 1
bind = $mainMod, 2, exec, hyprctl dispatch workspace 2
bind = $mainMod, 3, workspace, 3
bind = $mainMod, 4, workspace, 4
bind = $mainMod, 5, workspace, 5
bind = $mainMod, 6, workspace, 6
bind = $mainMod, 7, workspace, 7
bind = $mainMod, 8, workspace, 8
bind = $mainMod, 9, workspace, 9
bind = $mainMod, 0, workspace, 10

# Move active window to a workspace with mainMod + SHIFT + [0-9]
bind = $mainMod SHIFT, 1, movetoworkspace, 1
bind = $mainMod SHIFT, 2, movetoworkspace, 2
bind = $mainMod SHIFT, 3, movetoworkspace, 3
bind = $mainMod SHIFT, 4, movetoworkspace, 4
bind = $mainMod SHIFT, 5, movetoworkspace, 5
bind = $mainMod SHIFT, 6, movetoworkspace, 6
bind = $mainMod SHIFT, 7, movetoworkspace, 7
bind = $mainMod SHIFT, 8, movetoworkspace, 8
bind = $mainMod SHIFT, 9, movetoworkspace, 9
bind = $mainMod SHIFT, 0, movetoworkspace, 10
bind = $mainMod SHIFT, S, exec, hyprshot -m region
bind = , F5, exec, brightnessctl set 10%-
bind = , F6, exec, brightnessctl set +10%
bind = , F2, exec, pamixer --decrease 10
bind = , F3, exec, pamixer --increase 10
bind = , F1, exec, pamixer --toggle-mute
bind = , F10, exec, systemctl suspend && hyprlock
bind = $mainMod, Z, fullscreen

Do you use nvidia GPU?

Same issue here, using an NVIDIA GPU on NixOS (unstable package for Hyprland to have more recent versions), and with the default follow_mouse value. Is this possibly just another case of NVIDIA being a pain with GTK4/Wayland?
Video linked here (ignore the cursor not being the proper one on the Flatpak GTK4 program, this is, I think, a NixOS issue that has been solved for the next release).
https://github.com/hyprwm/Hyprland/assets/160250128/3d82d2ba-4440-476e-a5be-a0ff9782c405

related issue https://github.com/hyprwm/Hyprland/issues/4848

authors: Atemo-C JustasPolis MightyPlaza fecet vaxerski


text:
Fix button scaling

I can't write C++, you may want to tidy this up.

Done. I also pushed another commit that fixes the title text rendering, and the clickable area of the buttons.

repo: hyprwm/hyprland-plugins


text:
only run push event on master branch

I notice a duplicated CI running, this PR "fixes" it.

Thanks! I just generated the file with PkgTemplates.jl.
https://github.com/invenia/PkgTemplates.jl/blob/master/templates/github/workflows/CI.yml#L3
Maybe we can make a PR for the repository.

There's some discussion in https://github.com/invenia/PkgTemplates.jl/issues/193 but not concluded.

Ah, I see. Thanks for the information!


text:
Stop Woocommerce Version Check

The plugin must not check for major woocomerce versions . The code must be light as much as possible
After all we do not expect woopoly 1.0.0 to work with woocomerce 2.6 , it is a major update.
Versions check must be for minor changes only in woocommerce and polylang

Tricky decision:
Ideally the first woo3 release should be compatible with both woocommerce 2.6 and woocommerce 3.0 for the convenience of users during their transition period, though it's certainly adding complexity to the code and testing.
As a user myself, my production is up to date with all components except wooCommerce3 and I would be annoyed if the plugins started releasing woo3 only versions.
Should v1 refuse to activate if wooCommerce >3.0 is not detected?

ie add check for woocommerce3 in canActivate() and update activateError.php to indicate dependency on wooCommerce3 or higher ?

At the moment:

the updates for woo3 should work as well or better with woocommerce 2.6 than the current 0.26 version.
New fixes and enhancements are applied to v3 only, leaving execution of old unfixed code for v2.6.

@Jon007 I got your Idea, The last version which supports woo v2.6 will be woopoly v0.29 , the new version must support woo v3.0 only with no support for the old version, and I think this way makes sense. and it is easier to test.
if we need to support users who use woo2.6 or fix some old bugs we can still patch the version 0.29 , these patch versions will be available throw WordPress repo too then users can switch to old version of this plugin using wp-rollback
WooPoly 1.0.0 and later versions will handle this type of checks clearly upon activationt , I am already working on a solution for this. for now we must stop the check for Woo3.0 in our new code . we check only for minor changes in Woo3.0 and Polylang 2.0

ok, understood, let's keep a separate branch for 0.29 patches.
Actually there are some in my previous RC which apply to 0.29, but really we need to focus limited available time on moving forward.
Noting WooCommerce 3.0.7 now out, should update the minimum version:  there is no point supporting 3.0.1-3.0.6, only the latest version.

repo: hyyan/woo-poly-integration


text:
Variation Does not Synchronise in another language

using Storefront
only with WooCommerce, Polylang and Hyyan WooCommerce Polylang Integration 3 plugins
What product versions and settings are you using when this issue occurs?

PHP: 5.6.30
WordPress: 4.9.1
WooCommerce: 3.2.6
Polylang: 2.2.7
Hyyan WooCommerce Polylang Integration: 1.0.4
Browser: Mozilla

adding attributes from Attributes page.
adding variation in add new product page(variable product).
(4 variation)
i use only 2 language (english and myanmar)
when i buy from one language, another language stock does not reduce.

cart page like this when i buy 1 from each language.

there are quite a few settings that might affect this.

please confirm Stock synchronisation is checked in Settings/woopoly/features and Settings/woopoly/meta
please check the actual product:  when you edit the product go to the Inventory section, and look at:
Manage stock?  []  Enable stock management at product level

If you want stock to be managed at the variation level, this checkbox must be cleared on the product.
Then go to the variations section and ensure Manage Stock is checked on the individual variations.
I don't use this feature and haven't checked it on 3.2.6 but it did work on previous versions

select in stock synchronisation
nth filled in inventory.
enable in manage stock on the individual variations.
still it does not work in different language of variation product. :(

i got it sit.
when i change themes. it is ok. thz

it also need clear in shipping information of product level.
after that i got it. really thz sir.

ok good!
since it is resolved, let's close the issue


text:
Wrong range of Refinenet residual?

The refinenet (unet) output is converted with a sigmoid. So unet output is between (0, 1). In IFNet, it's further transformed:
https://github.com/hzwer/arXiv2020-RIFE/blob/3ed182299c95a1c87f9c6cb340f854315f79ee1d/model/IFNet.py#L106
So res should be within (0, 1) as well? But in the paper, the residual Delta is between (-1, 1).

Sorry I did a wrong calculation. res is within be (-1, 1). There are no errors.