Overview

Request 902836 accepted

The latest kdiff3 currently shipped with Tumbleweed is unsuitable for everyday use. I, for example, use it as my go-to `git mergetool` and I need that a lot. And it must be reliable and not messing up merge-output. Since the upgrade from 1.8.4 to 1.9.2, many regressions have to be experienced, please see the list of fixed issues below.

From a distribution point of view, I see two options: Fix-up 1.9.2 like proposed here, or (really!) downgrade to 1.8.5 until a new reliable 1.9 release comes out. I have contributed many fixes to upstream meanwhile.

- Remove GCC 11 build fix:
* 0001-Explicitly-include-limits-for-compatibility-with-gcc.patch
now contained in squashed patch
- Add collected fixes from upstream master:
* 0001-Collected-fixes-from-master.patch
contains the original and many more fixes:
+ misalignment and wrong conflict resolutions when using manual
alignment markers
+ uninitialized variables causing crashes
+ hangs and crashes due to wrong loop conditions
+ wrong handling of new-line at end-of-file
+ spurious insertion of empty lines in merge result
+ access of uninitialized iterators causing crashes
+ wrong buffer length calculations causing out-of-bounds access
+ wrong bit-logic causing comments to always be treated as white-space
+ crashes when hitting a key on empty merge results
+ technical details allowing fixes to be cherry-picked

Loading...

Luca Beltrame's avatar

If possible, I'd rather ask upstream to make a new release.


Tilman Vogel's avatar
author source maintainer

Upstream master won't compile with Boost <1.69, i.e. not with Leap 15.2 (Boost 1.66). I wouldn't hold my breath. Also, what level of quality control is done before integrating upstream updates? kdiff3 1.8 is a lot more stable and given the refactorings and related regressions, I have seen between 1.8 and 1.9, I wouldn't be surprised about more crashes lurking in 1.9.


Christophe Giboudeaux's avatar

Quality control is supposed to be done upstream before a release with code review, unit tests... If that part is failing, there's not much that can be done downstream except blocking a release and/or dealing with users bug reports.

I don't remember seeing any recent report about kdiff3.

Also, don't worry about missing build dependencies for older Leap versions. This is expected and we disable build when we can't provide the missing build dependency without breaking other parts of the distro.


Tilman Vogel's avatar
author source maintainer

OK, in my patch set, I added fall-back logic for Boost < 1.69 (which was there for Windows already anyway). For your reference, find the list of individual patches here:

https://invent.kde.org/eijk/kdiff3/-/compare/1.9.2...1.9.2-fixed?from_project_id=8184


Tilman Vogel's avatar
author source maintainer

Hi @cgiboudeaux, I know there are reverts - that's unfortunately what upstream does and it is tedious the squash them pairwise. If you prefer, I can make a squashed patch but it will make it less evident which upstream commits are included.

About the changelog - you mean the added removed patches from the spec shall be named?

Request History
Tilman Vogel's avatar

tivo created request

The latest kdiff3 currently shipped with Tumbleweed is unsuitable for everyday use. I, for example, use it as my go-to `git mergetool` and I need that a lot. And it must be reliable and not messing up merge-output. Since the upgrade from 1.8.4 to 1.9.2, many regressions have to be experienced, please see the list of fixed issues below.

From a distribution point of view, I see two options: Fix-up 1.9.2 like proposed here, or (really!) downgrade to 1.8.5 until a new reliable 1.9 release comes out. I have contributed many fixes to upstream meanwhile.

- Remove GCC 11 build fix:
* 0001-Explicitly-include-limits-for-compatibility-with-gcc.patch
now contained in squashed patch
- Add collected fixes from upstream master:
* 0001-Collected-fixes-from-master.patch
contains the original and many more fixes:
+ misalignment and wrong conflict resolutions when using manual
alignment markers
+ uninitialized variables causing crashes
+ hangs and crashes due to wrong loop conditions
+ wrong handling of new-line at end-of-file
+ spurious insertion of empty lines in merge result
+ access of uninitialized iterators causing crashes
+ wrong buffer length calculations causing out-of-bounds access
+ wrong bit-logic causing comments to always be treated as white-space
+ crashes when hitting a key on empty merge results
+ technical details allowing fixes to be cherry-picked


Christophe Giboudeaux's avatar

cgiboudeaux accepted request

Thanks.

openSUSE Build Service is sponsored by