Add check for mdadm tool
I am still working on this revision.
How can the creation of RAID be tested and what do you mean by loop device?
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
May 25 2019
May 24 2019
In D21340#469511, @cjlcarvalho wrote:There are some procedures missing in this test. First, you need to look if mdadm is installed in the system before testing RAID. Then, you need to test the creation of a RAID device and check if it was successfully created. After that, you can try to create partitions on it and test if it exists.
There are some procedures missing in this test. First, you need to look if mdadm is installed in the system before testing RAID. Then, you need to test the creation of a RAID device and check if it was successfully created. After that, you can try to create partitions on it and test if it exists.
@stikonas Does the rest looks sensible?
May 23 2019
Add condition in whihc partition size can not be computed
May 22 2019
Remove extra line
May 19 2019
Do not remove qca-qt5 from CMakeLists.txt
May 18 2019
May 17 2019
Shift common code to filesystem class
Also in general, I think we should create a bool variable where we store data, so that we only run this
I assume it is not required anymore.
Well, in principle both mean exactly the same thing, so I don't have strong opinion on this. I probably use them interchangeably anyway. Well, it's auto, so we don't care what type it is... So based on that I would say no need to make a commit. Other parts of KDE codebase also don't have unified style here. Just checked kwin, it has both auto and auto *
@stikonas any comments?
In D21251#466412, @shubham wrote:Yesterday I tried for putting theses revisions over gitLab. but could not succeed. I tried doing git push origin master and it said access denied. So what should I do now to push it remote and the merge? Thanks
Yesterday I tried for putting theses revisions over gitLab. but could not succeed. I tried doing git push origin master and it said access denied. So what should I do now to push it remote and the merge? Thanks
In D21251#466408, @shubham wrote:I have commit access, but It says access denied. Remember you had said it is hosted on remote server.
I have commit access, but It says access denied. Remember you had said it is hosted on remote server.
In D21251#466401, @shubham wrote:Oh, I do by running kdesrc-build script, which takes care of removing old build directory.
Please push this and the other revision on my behalf : )
oh ok, that's fine then.
Oh, I do by running kdesrc-build script, which takes care of removing old build directory.
Please push this and the other revision on my behalf : )
In D21251#466395, @shubham wrote:please test that it builds in a clean build dir.
I do not know what do you mean? tests?
please test that it builds in a clean build dir.
I do not know what do you mean? tests?
Do not remove <memory>
We also don't need this. Q_SLOTS are needed with old style Qt syntax where SIGNAL and SLOTS are used. With the new Qt5 connect syntax, you can just connect to any function, so no need to involve moc on this function.
The other include (#include "externalcommandhelper.h") I think can still go away but please test that it builds in a clean build dir.
It is needed by std::unique_ptr and std::unordered_set. We shouldn't rely on header being pulled in by some other header.
More redundant include
May 16 2019
Take few more instances into account.
Please push it on my behalf.
Apr 29 2019
Apr 6 2019
In D20269#444176, @stikonas wrote:Looks alright, although I wouldn't call that thing a typo. Variable names in C++ doesn't have to match in function header and implementation, although, it's probably less confusing if they match. But sometimes one can simply omit names in header and just have types.
Apr 5 2019
Looks alright, although I wouldn't call that thing a typo. Variable names in C++ doesn't have to match in function header and implementation, although, it's probably less confusing if they match. But sometimes one can simply omit names in header and just have types.
Mar 30 2019
Abandoned in favour of above comments
In D20109#440427, @shubham wrote:In D20109#440244, @stikonas wrote:I don't think we should change other lines too here. We pass that percent to KJob, so keep the type the same as KJob expects.
I have not changed the type for percent() signal, I have changed type for emitProgress()
In D20109#440244, @stikonas wrote:I don't think we should change other lines too here. We pass that percent to KJob, so keep the type the same as KJob expects.
Mar 29 2019
In D20109#440247, @cjlcarvalho wrote:We also need to adapt this connect KJob to the Qt5 signals and slots syntax.
We also need to adapt this connect KJob to the Qt5 signals and slots syntax.
I don't think we should change other lines too here. We pass that percent to KJob, so keep the type the same as KJob expects.
Move QCA header outside Qt headers
I don't think moving QtCrypto is right. It's not a Qt header, it belongs to QCA.
Do not change argument type for percent(KJob*, unsigned long) signal
Mar 27 2019
If most of our code follows this standard of using quint64, I think that it is reasonable to maintain the other parts of it in this way.
I did not find any other occurrences of unsigned long long, so probably quint64 is the coding style
Hmm, do we really need this? quint64 is unsigned long long. It's just a typedef, so both can be used interchangeably. And unsigned long long is also C++ data type, not just C... Altgough, obviously this change wouldn't break anything. I guess it's just a question of code style but I didn't find any KDE recommendations. Any other opinions from other reviewers?
Jan 4 2019
Ok, I'm subscribed.
Jan 3 2019
@cjlcarvalho Just double checked, it's still an issue.
@cjlcarvalho I don't recall any patch that fixed this. I can try to test
later today.
@stikonas Is this solved?
Jan 1 2019
In D17129#382304, @stikonas wrote:In D17129#382302, @varunp wrote:Most of the features in gsmartcontrol look like they have already been transferred to json. I can try to add all of this in the next few months. Is there any timeline on the next release of partitionmanager/kpmcore?
No timeline yet. First of all, there needs to be a new release of smartmontools. But probably best to work in a branch for a while.
Dec 25 2018
In D17129#382302, @varunp wrote:Most of the features in gsmartcontrol look like they have already been transferred to json. I can try to add all of this in the next few months. Is there any timeline on the next release of partitionmanager/kpmcore?
Most of the features in gsmartcontrol look like they have already been transferred to json. I can try to add all of this in the next few months. Is there any timeline on the next release of partitionmanager/kpmcore?