I have openSUSE and Manjaro partitions as well as OpenMandriva Lx3. In openSUSE and Manjaro I recently noticed that spellcheck in Quassel has started working which it hasn’t since advent of Plasma5 desktop. Spellcheck did work in KDE4. Then I notice that both distros had updated Quassel to 12.5 wereas OM still has 12.4.
Also worthy of note in the commits on Github are some important security fixes.
If interested more can be found here:
Bug report filed:
How hard would it be for me to learn to do this myself? Anyone available to mentor my learning process at this task?
A guide to beginner contributors is a big miss on our wiki but it may require to spend some time to write a good one nobody have had this time until now.
However in general it mostly depends on how many confidence you have with compilation process, especially if you need to patch the source.
In your case case it could be really simple: just change the version into the SPEC file, load the source on the omdv filestore, fix the .abf.yml file and start to build it on ABF (I suppose you already know how to use github repo, otherwise feel free to ask here too).
There is a good guide here. Even if the images refer to the old ABF interface the concepts are still good.
Thanks, I will try that. In time, right now I have a “home organizing” project to get done.
@ben79 This should be an easy for you. I tried build this package and it should build well in your case. I’m not smarter, if I can build it, you can also 
Just try, it should be fine. Some packages are built very easily. As the @mandian writes. With others it may be harder but you can always deduce from the content of the error what is wrong. You can search in google or ask developers on irc. Basically you will not know if some package is easy to build or not until you try it yourself.
Probably will be easy once I get unblocked and get started. However the spring cleaning/home organizing project is # 1 on the agenda.
As a best practice when you build a new version of a program you should build it in cooker (master branch on git) first then merge into the current version, which actually is 3.0 so the cooker branch always provides the same version (or a more update one) with respect to the stable branch otherwise you will experience a package version conflict one day. I suggest to you to make a change directly into stable branch only if, for some technical reason, you wan’t have this in cooker (for instance a patch required by the particular version of the compiler provided by the stable branch but not more needed by the version provided by cooker branch).
@ben79 if ever you want/can/have time, don’t hesitate to publish your experience or a howto in ABF for beginners category
