All of you that are in using a computer for a long time should use it!
https://userbase.kde.org/RSIBreak
Changes from 0.12.11:
* Don't reset pause counter on very short inputs that can just be accidental.
* Improve high dpi support
* Translation improvements
* Compile with Qt 5.15 beta
* Minor code cleanup
http://download.kde.org/stable/rsibreak/0.12/rsibreak-0.12.12.tar.xz
Sunday, March 29, 2020
Sunday, March 15, 2020
20.04 releases branches created
Make sure you commit anything you want to end up in the 20.04 releases to them
We're already past the dependency freeze.
The Feature Freeze and Beta is this Thursday 19 of March.
More interesting dates
April 2: 20.04 RC (20.03.90) Tagging and Release
April 16: 20.04 Tagging
April 23: 20.04 Release
https://community.kde.org/Schedules/Applications/20.04_Release_Schedule
We're already past the dependency freeze.
The Feature Freeze and Beta is this Thursday 19 of March.
More interesting dates
April 2: 20.04 RC (20.03.90) Tagging and Release
April 16: 20.04 Tagging
April 23: 20.04 Release
https://community.kde.org/Schedules/Applications/20.04_Release_Schedule
Monday, March 09, 2020
20.04 releases dependency freeze this thursday
Next interesting dates:
March 12: 20.04 Dependency Freeze
March 19: 20.04 Freeze and Beta (20.03.80) tag & release
March 12: 20.04 Dependency Freeze
March 19: 20.04 Freeze and Beta (20.03.80) tag & release
Monday, February 10, 2020
Working with different remotes in git
One of the things that is typical when working with gitlab/github is work with different git remotes.
This is sometimes because you don't have commit access to the original repository so you fork it into your own repository and work over there, but you still want to have the original repository around so you can rebase your changes over it.
In this blog we will see how to do that with the okular repository.
First off, we start by cloning the original repository
Since we don't know the URL by memory, we go to https://invent.kde.org/kde/okular/ and press the Clone button to get a hint, if we have commit access we can use both urls, otherwise we have to use the https one, for the sake of this let's assume we do not have commit access.
Ok, at this point we have clone the upstream Okular repository, we can see we only have one remote, called origin
Now we want to do some fixes, since we can't commit into the main repository, we need to fork, for that we press the fork button in https://invent.kde.org/kde/okular/. Once done we end up in the fork of Okular under our name, e.g. https://invent.kde.org/aacid/okular.
Now what we want is to add our remote to the existing one, so we press the blue button (here we use the git@ one since we can always commit to our fork)
So now we have a remote called aacid_fork that points to url fork, aacid_fork is the name i chose because it's easy to remember, but we could have used any name we wanted there.
Now there's several things one may want to do
After doing the changes and doing the typical
What this does is push the local branch master to the branch named adding_since_to_function of the aacid_fork remote
and then change to work on that branch
After doing the changes and doing the typical
What this does is push the local branch adding_since_to_function to a branch with the same name of the aacid_fork
Sometimes some people say "hey let's work on my branch together", so you need to push not to origin, not to your fork but to someone else's fork.
Let's say you want to work on joliveira's gsoc2019_numberFormat branch, so you would need to add his remote
Then we would need to tell git, hey listen, please go and read the branches that remote i just added has
Next we have to tell git to actually give us the gsoc2019_numberFormat branch, there's lots of ways to do that, one that works is
This will create a local gsoc2019_numberFormat from the contents of the remote branch joliveira_fork/gsoc2019_numberFormat and that also "tracks" it, that means that if someone else does changes to it and you do
After doing the changes and doing the typical
Every time you want to get changes from a remote, remember to
When git pushing the syntax is
You can simply do
This is sometimes because you don't have commit access to the original repository so you fork it into your own repository and work over there, but you still want to have the original repository around so you can rebase your changes over it.
In this blog we will see how to do that with the okular repository.
First off, we start by cloning the original repository
Since we don't know the URL by memory, we go to https://invent.kde.org/kde/okular/ and press the Clone button to get a hint, if we have commit access we can use both urls, otherwise we have to use the https one, for the sake of this let's assume we do not have commit access.
$ git clone https://invent.kde.org/kde/okular.git
$ cd okular
Ok, at this point we have clone the upstream Okular repository, we can see we only have one remote, called origin
$ git remote -v
origin https://invent.kde.org/kde/okular.git (fetch)
origin https://invent.kde.org/kde/okular.git (push)
Now we want to do some fixes, since we can't commit into the main repository, we need to fork, for that we press the fork button in https://invent.kde.org/kde/okular/. Once done we end up in the fork of Okular under our name, e.g. https://invent.kde.org/aacid/okular.
Now what we want is to add our remote to the existing one, so we press the blue button (here we use the git@ one since we can always commit to our fork)
$ git remote add aacid_fork git@invent.kde.org:aacid/okular.git
$ git remote -v
aacid_fork git@invent.kde.org:aacid/okular.git (fetch)
aacid_fork git@invent.kde.org:aacid/okular.git (push)
origin https://invent.kde.org/kde/okular.git (fetch)
origin https://invent.kde.org/kde/okular.git (push)
So now we have a remote called aacid_fork that points to url fork, aacid_fork is the name i chose because it's easy to remember, but we could have used any name we wanted there.
Now there's several things one may want to do
Do changes in master and push them to your fork
This is really not the recommended way but since it's what i do and it'll explain how to push from one branch name to another i'll explain it.After doing the changes and doing the typical
git commit now we have to push the changes to our aacid_fork, so we do git push aacid_fork master:adding_since_to_functionWhat this does is push the local branch master to the branch named adding_since_to_function of the aacid_fork remote
Create a branch and then push that to your fork
This is what you should be doing, so what you should do isgit branch adding_since_to_functionand then change to work on that branch
git switch adding_since_to_functionAfter doing the changes and doing the typical
git commit now we have to push the changes to our aacid_fork, so we dogit push aacid_fork adding_since_to_functionWhat this does is push the local branch adding_since_to_function to a branch with the same name of the aacid_fork
Get a branch from someone else's remote and push to it
Sometimes some people say "hey let's work on my branch together", so you need to push not to origin, not to your fork but to someone else's fork.
Let's say you want to work on joliveira's gsoc2019_numberFormat branch, so you would need to add his remote
$ git remote add joliveira_fork git@invent.kde.org:joliveira/okular.git
$ git remote -v
aacid_fork git@invent.kde.org:aacid/okular.git (fetch)
aacid_fork git@invent.kde.org:aacid/okular.git (push)
joliveira_fork git@invent.kde.org:joliveira/okular.git (fetch)
joliveira_fork git@invent.kde.org:joliveira/okular.git (push)
origin https://invent.kde.org/kde/okular.git (fetch)
origin https://invent.kde.org/kde/okular.git (push)
Then we would need to tell git, hey listen, please go and read the branches that remote i just added has
git fetch joliveira_forkNext we have to tell git to actually give us the gsoc2019_numberFormat branch, there's lots of ways to do that, one that works is
git checkout --track joliveira_fork/gsoc2019_numberFormatThis will create a local gsoc2019_numberFormat from the contents of the remote branch joliveira_fork/gsoc2019_numberFormat and that also "tracks" it, that means that if someone else does changes to it and you do
git pull --rebase while on your local gsoc2019_numberFormat, you'll get them.After doing the changes and doing the typical
git commit now we have to push the changes to the joliveira_fork, so we dogit push joliveira_fork gsoc2019_numberFormatWhat you don't want to do
Don't push to the master branch of your remote, it's weird, some people do, but it's note really recommended.Things to remember
A git remote is another repository, it just so happens that it has "similar" code, but it's a fork, so you can push to it, checkout branches from it, etc.Every time you want to get changes from a remote, remember to
git fetch remote_name otherwise you're still on the "old" snapshot form your last fetch.When git pushing the syntax is
git push remote_name local_branch_name:remote_branch_nameBonus track: Using git mr
As shown in my previous blog post you can use git mr to easy download the code of a mr. Let's use as example Okular's MR #20 https://invent.kde.org/kde/okular/merge_requests/20.You can simply do
git mr 20 and it will create a local branch named mr/20 with the contents of that MR. Unfortunately, if you want to commit changes to it, you still need to use the original remote and branch name name, so if you do some changes, after the git commit you should dogit push joliveira_fork mr/20:gsoc2019_percentFormat
Sunday, February 09, 2020
20.04 releases schedule finalized
It is available at the usual place https://community.kde.org/Schedules/release_service/20.04_Release_Schedule
Dependency freeze is in ~five weeks (March12) and Feature Freeze a week after that, make sure you start finishing your stuff!
Dependency freeze is in ~five weeks (March12) and Feature Freeze a week after that, make sure you start finishing your stuff!
Thursday, February 06, 2020
New help porting to Go >= 1.12
At KDE we have a GitHub mirror. One of the problems about having a mirror is that people routinely try to propose Pull Requests over there, but no one is watching, so they would go stale, which is not good for anyone.
What no one? Actually no, we have kdeclose, a bot that will go over all Pull Requests and gracefully close them suggesting people to move the patch over to KDE infrastructure where we are watching.
The problem is that I'm running that code on Google AppEngine and they are cutting support for the old Go version that it's using, so I would need someone help me port the code to a newer Go version.
Anyone can help me?
P.S: No, I'm not the original author of the code, it's a fork of something else, but that has not been updated either.
Update: This is now done, thanks to Daniele (see first comment). Mega fast, thanks community!
What no one? Actually no, we have kdeclose, a bot that will go over all Pull Requests and gracefully close them suggesting people to move the patch over to KDE infrastructure where we are watching.
The problem is that I'm running that code on Google AppEngine and they are cutting support for the old Go version that it's using, so I would need someone help me port the code to a newer Go version.
Anyone can help me?
P.S: No, I'm not the original author of the code, it's a fork of something else, but that has not been updated either.
Update: This is now done, thanks to Daniele (see first comment). Mega fast, thanks community!
Sunday, February 02, 2020
QCA cleanup spree
The last few weeks I've done quite a bit of QCA cleanup.
Bit of a summary:
* Moved to KDE's gitlab and enable clazy and clang-tidy continuous integration checks
* Fixed lots of crashes when copying some of the classes, it's not a normal use case, but it's supported by the API so make it work :)
* Fixed lots of crashes because we were assuming some of the backend libraries had more features than they actually do (e.g. we thought botan would support always support a given crypto algorithm, but some versions don't, now we check if the algorithm it's supported before saying it is)
* Made all the tests succeed :)
* Dropped Qt4 support
* Use override, nullptr (Laurent), various of the "sanity" QT_* defines, etc.
* botan backend now requires botan2
* Fixed most of the compile warnings
What I probably also did is maybe break the OSX and Windows builds, so if you're using QCA there you should start testing it and propose Merge Requests.
Note: My original idea was to actually kill QCA because i started looking at it and lot of the code looked a bit fishy, and no one wants crypto fishy code, but then i realized we use it in too many places in KDE and i'd rather have "fishy crypto code" in one place than in lots of different places, at least this way it's easier to eventually fix it.
Bit of a summary:
* Moved to KDE's gitlab and enable clazy and clang-tidy continuous integration checks
* Fixed lots of crashes when copying some of the classes, it's not a normal use case, but it's supported by the API so make it work :)
* Fixed lots of crashes because we were assuming some of the backend libraries had more features than they actually do (e.g. we thought botan would support always support a given crypto algorithm, but some versions don't, now we check if the algorithm it's supported before saying it is)
* Made all the tests succeed :)
* Dropped Qt4 support
* Use override, nullptr (Laurent), various of the "sanity" QT_* defines, etc.
* botan backend now requires botan2
* Fixed most of the compile warnings
What I probably also did is maybe break the OSX and Windows builds, so if you're using QCA there you should start testing it and propose Merge Requests.
Note: My original idea was to actually kill QCA because i started looking at it and lot of the code looked a bit fishy, and no one wants crypto fishy code, but then i realized we use it in too many places in KDE and i'd rather have "fishy crypto code" in one place than in lots of different places, at least this way it's easier to eventually fix it.
Subscribe to:
Posts (Atom)
