dbeaver: update to 26.1.3

[al-tr]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, x86_64-glibc

updated openjdk to version 25 (it is LTS and GA since Sept 2025)
verified locally with a few databases, no issues

[ahesford]

Don't close PRs just to open a duplicate.

[al-tr]

Don't close PRs just to open a duplicate.

I've read contributing.md and understand that this is not desirable.
Previous PR was made according to the doc, but CI failed with the message "subject does not follow CONTRIBUTING.md guildelines" which is not descriptive at all.
So I can only speculate what went wrong. And my guess was that the only inconsistency in PR is the branch name: initially named it dbeaver-26.1.2, but the main dbeaver package version 26.1.2 is not released yet, though dependent packages dbeaver-common and dbeaver-jdbc-libsql already have 26.1.2 versions, which were the references I used during the branch creation.
So I only updated template to 26.1.1, but branch name stayed (I forgot about it and only saw it in the PR, my bad). So the wrong branch name being the only suspect I can assume is the reason of CI failure. Contribute.md references branch name as <a-descriptive-name> and not some template name, which poses it to not being important in the check. But I wasn't able to find anything else that could be the reason of the check failure, so I updated the branch understanding that this would require a new PR.

[slymattz]

I've read contributing.md and understand that this is not desirable. Previous PR was made according to the doc, but CI failed with the message "subject does not follow CONTRIBUTING.md guildelines" which is not descriptive at all. So I can only speculate what went wrong. And my guess was that the only inconsistency in PR is the branch name

Hi! It was the commit message that didn't comply with the rules; instead of Update dbeaver to 26.1.1 it should've read dbeaver: update to 26.1.1 or dbeaver: update to 26.1.1. The branch name could be named anything and the linter shouldn't complain.

[al-tr]

@slymattz thank you for clarification, is there any way to run CI checks locally? or maybe CI did say about the exact reason of failure and I missed it?

[al-tr]

has been updated to 26.1.2
built locally, verified functionality with a few databases
changelog isn't huge between 26.1.1 and 26.1.2
https://github.com/dbeaver/dbeaver/releases/tag/26.1.2

[al-tr]

this dir didn't change name. manually verified during build

[ar-jan]

when it does change, you'd see an error when building it locally.

[al-tr]

should I do anything here to get it merged?

[ar-jan]

Sometimes it takes a while for someone to merge it.

I'd bump it to the just released version 26.1.3 and force-push to update the pull request.

[ar-jan]

In general, it's helpful to run xlint pkgname to check template formatting and use xbump pkgname to create a correctly formatted git commit.

[al-tr]

@ar-jan updated to 26.1.3, verified locally with a few databases