On Saturday 22 January 2011 23:04:20 Robert Xu wrote:

...

wow. that was a lot >_< I'll get the rest of the list done in a little bit, unless someone would be willing to finish it?

Can anybody please finish the list so I could to file a bugreport?

About what development one can be speaking if there is no KDE3 repository so far which inludes all useful stuff which was developed for KDE3? Even when KDE3 was officially "alive", no distro had all that software. Some distros had A,B, some B,C, and the third ones has A,C. OpenSUSE never included as much KDE3 software as KDE3 repo includes now, after the death of KDE3 was officially proclaimed. And the total amount of software ever made for KDE3 is so huge that this repository can be expanded for years without any new software developed.

I would like to see Tim's comment.

That maintaining all that software is too much for this project to handle?

I will need to see some triage on that list to weed out programs that: a.) Have no use whatsoever on modern systems b.) Have been fully replaced by more modern software c.) Rely on old unmaintained libraries with no modern replacement

Tim

On Tue, Jan 25, 2011 at 07:22, Ilya Chernykh neptunia@mail.ru wrote:

On Tuesday 25 January 2011 09:28:01 Timothy Pearson wrote:

...

I will need to see some triage on that list to weed out programs that: a.) Have no use whatsoever on modern systems

We usually do not keep such software.

That saves us some work.

...

b.) Have been fully replaced by more modern software

Yes, such packages exist. But only if to count Qt4-based software. Indeed, the whole KDE has been replaced... We usually keep the last Qt3-based version in KDE3 repo.

hm. Once tqt for qt4 is complete then we should drop the Qt3 versions that have a Qt4 maintained one. of course, that could take a while (so... much... hassle... (according to Tim xD))

...

c.) Rely on old unmaintained libraries with no modern replacement

The dependencies and descriptions could be found in the spec files following the links in the list.

Hm. Speaking of that... I shall finish that list... Then, when build.o.o is not bugging up all over the place (all my builds are failing/unresolvable/just not working, which is weird cause then all jpackage packages would fail too, according to sshaw and mrdocs o_O), I can take a look at the dependencies.

Now to the list! DUM DUM DUM ^^

kding NO kdirstat YES kdissert NO kdvdauth NO keep YES kftpgrabber NO kgit NO khtml2png NO kiax NO kima YES kinternet NO kio-locate YES kio_ipodslave NO kio_slp NO kirocker NO kiso NO kkbswitch NO klamav NO kleansweep NO kmess NO kmetabar NO kmhtconvert NO kmldonkey NO kmm_kbanking NO kmobiletools NO kmyfirewall YES kmymoney NO knetload YES knetstats YES knfoviewer NO knifty NO knights YES knoda NO knowit YES knutclient YES koctave3 NO koffice YES koffice-database-mdb subpkg? koffice-i18n subpkg? komparator NO kompile NO kompose NO konserve NO kooldock NO kopete-anyremote NO koverartist NO kpl NO kplayer NO kpodder NO kpopassistant NO kpowersave YES kprocout NO kradview NO krecipes NO krecord NO krep NO krpmbuilder NO kscpm NO kseg NO ksensors3 NO ksimus NO kslovar NO ksniffer NO ksociograma NO ksquirrel YES ksquirrel-libs subpkg? ksubtile NO ktoblzcheck NO ktranslator NO ktray NO kuftp NO kvim NO kvocabs NO kwatch NO kwin-decor-suse2 NO kwlan NO kxmleditor NO kxstitch NO kyamo NO kyum NO labplot NO labplot-handbook NO libakode NO libdbus-1-qt3-0 (this doesn't need to be ported to trinity, still works with QT3) libdjconsole NO libgmm++-devel NO libgpod3 NO libkdcraw4 YES libkexiv2-5 YES libkipi0 YES libnjb NO libpar2-0 NO libqtpod NO librapi2 NO libsensors3 NO libsidplay NO libsynce NO libvisual NO libvisual-plugins NO mnemosyne NO moodin NO noteedit NO omniORB NO opak NO oprofile NO pam_kwallet NO pdfedit NO pgcalc NO piklab NO polyester NO pwmanager NO python-chm NO python-kde3 YES python-qt NO (but you can still use this with QT3) python-sip NO qbankmanager NO qca NO qca-sasl NO qcad NO qjoypad NO qt3 YES NOTEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE please update this to 3.3.8c using the patch on the trinity wiki. Use patch level 2. qt3-devel-doc subpkg? qt3-extensions can stay as is qtc NO qtcurve-kde NO (but shouldn't need conversion, right?) qtparted NO qtsharp NO qtsmbstatus-client-qt3 NO qtsmbstatus-server-qt3 NO quadkonsole NO recoll-applet NO recoll-qt3 NO rekall NO releaseforge NO richclient NO schafkopf NO scim-qtimm_11.3 NO scpm NO scribus NO scribus-templates NO showimg NO sonik NO texmaker-qt3 NO thinkeramik NO tiblit NO tork NO tripod NO trix NO twinkle NO umtsmon NO unrtf NO unsermake NO valknut NO whiteline NO xapian-core NO xdrawchem NO xsidplay NO yast2-control-center-qt3 (SUSE Specific) yauap NO

DONEEEEE :D now back to your regularly emailed mailing list.

On Tue, Jan 25, 2011 at 11:42 AM, Ilya Chernykh neptunia@mail.ru wrote:

On Tuesday 25 January 2011 19:38:53 Robert Xu wrote:

...

...

...

b.) Have been fully replaced by more modern software

Yes, such packages exist. But only if to count Qt4-based software. Indeed, the whole KDE has been replaced... We usually keep the last Qt3-based version in KDE3 repo.

hm. Once tqt for qt4 is complete then we should drop the Qt3 versions that have a Qt4 maintained one. of course, that could take a while (so... much... hassle... (according to Tim xD))

Then you'll drop all the KDE: koffice, kaffeine, kmail, konq - anything.

I wouldn't mind konversation, it's my favorite IRC client, but the kde3 version is a bit outdated, and the kde4 version will likely get the new features (mostly looking for custom CTCP replies (other than the custom version reply and settng my real name to whatever) and the ability to reject DCC filetransfers and/or chat). Konq only needs a new HTML engine, or support for more engines and the option to choose one's preference. KOffice needs better M$ support (not that I use such stuff, but other people switching from Windows or using it at work might), though that's done through another library, right? So Koffice doesn't need updating except to support a newer library, or a better one.

Unless we actually plan to rewrite KDE3 to use Qt4, we shouldn't worry about dropping anything. Sometimes outdated stuff works better than newer stuff (my old 1997 IBM worked much better than my mother's 2000 HP or my 2003 Dell, and my current HP has a proprietary wifi card that apparently doesn't support scanning for wireless on 2.6.37 kernels).

Thank you.

So to sum it up:

CodeAnalyst NO Coin NO (not Qt, just needed for FreeCAD) DJPlay NO EulerTop NO FreeCAD NO HippoDraw NO OpenCascade NO (not Qt, just needed for FreeCAD) QtDMM NO Serenity NO SoQt NO (not Qt, just needed for FreeCAD) TTtrigger NO Universe NO Xerces-c NO (not Qt, just needed for FreeCAD) albumart NO albumshaper NO antiword NO apollon NO aqbanking NO autoq3d-ce-qt3 NO bookreader NO boson NO catdoc NO celestia NO crossvc NO crystal NO (window decoration) datakiosk NO dclib NO deKorator NO desktoptext-config  NO (kcm module) divxcalc NO djvulibre NO domino NO doxygen NO (build tool) dvdauthor NO esvn NO exiv2 NO f4l NO falf NO fftw NO flatknifty NO fleur2 NO fuse_kio NO gambas2 NO * Very important package * gift NO gpsim NO gts NO guarddog NO * This and the next is a nice suite of netwotk utilities * guidedog NO gwenhywfar NO hplip-qt3 NO hydrogen NO imgSeek NO indeview NO k3dsurf NO kalsatools NO kamix NO katalog NO kbiff NO kbudget NO kcfgcreator NO kcometen3 NO kconfigeditor NO kconnections NO kcpuload NO kdbg NO kdbus NO kde3-dolphin NO (D3lphin is a fork of this) kde3-kalarm NO kde3-kalgebra NO kde3-katesort NO kde3-kbackup NO kde3-kbibtex NO *A TeX editor, very well integrated with KDE* kde3-kblogger NO kde3-kcemirror NO kde3-kdar NO kde3-kdvdramtools NO kde3-keurocalc  NO kde3-kflickr NO kde3-kid3 NO kde3-kile NO kde3-kim NO kde3-kio_beagle NO kde3-kio_rapip NO kde3-kiosktool NO kde3-kndiswrapper NO kde3-kopete-antispam  NO kde3-kover NO kde3-kpar2 NO kde3-kphotoalbum NO kde3-kscope  NO kde3-kshutdown NO kde3-kssh NO kde3-kst NO kde3-ktrafficanalyzer NO kde3-kvpnc NO kde3-kwave NO kde3-licq NO kde3-mailody NO kde3-mplayerthumbs NO kde3-oxygen-icon-theme NO kde3-rpmxdgtool NO kde3-style-ia-ora NO kde3-style-wisdom NO kdebluetooth NO kdetv NO kding NO kdissert NO kdvdauth NO kftpgrabber NO kgit NO khtml2png NO kiax NO kinternet NO kio_ipodslave NO kio_slp NO kirocker NO kiso NO kkbswitch NO klamav NO * Very important package * kleansweep NO kmess NO kmetabar NO kmhtconvert NO kmldonkey NO kmm_kbanking NO kmobiletools NO kmymoney NO knfoviewer NO knifty NO knoda NO koctave3 NO komparator NO kompile NO kompose NO konserve NO kooldock NO kopete-anyremote NO koverartist NO kpl NO kplayer NO kpodder NO kpopassistant NO kprocout NO kradview NO krecipes NO krecord NO krep NO krpmbuilder NO kscpm NO kseg NO ksensors3 NO ksimus NO kslovar NO ksniffer NO ksociograma NO ksubtile NO ktoblzcheck NO ktranslator NO ktray NO kuftp NO kvim NO kvocabs NO kwatch NO kwin-decor-suse2 NO kwlan NO kxmleditor NO kxstitch NO kyamo NO kyum NO labplot NO labplot-handbook NO libakode NO libdjconsole NO libgmm++-devel NO libgpod3 NO libnjb NO libpar2-0 NO libqtpod NO librapi2 NO libsensors3 NO libsidplay NO libsynce NO libvisual NO libvisual-plugins NO mnemosyne NO moodin NO noteedit NO omniORB NO opak NO oprofile NO pam_kwallet NO pdfedit NO pgcalc NO piklab NO polyester NO pwmanager NO python-chm NO python-qt NO (but you can still use this with QT3) python-sip NO qbankmanager NO qca NO qca-sasl NO qcad NO qjoypad NO qtc NO qtcurve-kde NO (but shouldn't need conversion, right?) qtparted NO qtsharp NO qtsmbstatus-client-qt3 NO qtsmbstatus-server-qt3 NO quadkonsole NO recoll-applet NO recoll-qt3 NO rekall NO releaseforge NO richclient NO schafkopf NO scim-qtimm NO scpm NO scribus NO * Very important package * scribus-templates NO showimg NO sonik NO texmaker-qt3 NO thinkeramik NO tiblit NO tork NO tripod NO trix NO twinkle NO umtsmon NO unrtf NO unsermake NO valknut NO * DC++ client, Very important package * whiteline NO xapian-core NO xdrawchem NO yauap NO

On Tue, Jan 25, 2011 at 6:28 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:

a.) Have no use whatsoever on modern systems

Most of them do. Perhaps in need of updating to modernize them or add a few missing features, but quite a few do. In fact, there's a KDE 3.4 program called KGreetingKard that would be of use, AFAIK there aren't any other programs out there for Linux, the only other option is to hack wine to run programs like PrintShop, PrintMaster, and PrintArtist, which I'd imagine would be quite a hassle and apparently one of the main things that pushed people away from Linux (having to tweak stuff to make them work when they apparently work perfectly under the rather imperfect and crappy Windows). Perhaps we can add it to the list and update the dependencies at some point or another to use KDE 3.5?

b.) Have been fully replaced by more modern software

KDE3 has been replaced by more modern software. Problem is, KDE4 doesn't work very well, the visual styles aren't all that great, they added in too many fanciful features, and AFAIK have yet to readd some of the old stuff from KDE3 that people still want/need (I last used KDE4.5, haven't checked the site lately, so they probably came out with another release by now). Personally, I'm sticking with KDE3, and I hope that Trinity will be around for quite some time.

c.) Rely on old unmaintained libraries with no modern replacement

To get rid of the unmaintained libraries, you'd need to rewrite KDE3 to use Qt4. The Trinity wiki mentions the last release from Trolltech (which handed Qt over to Nokia -- I wander what the people who use their tech who only support proprietary would think if they found out ;-)) was 3.3.8b, which was quite some time ago, and we are already on Qt4.7, so we'd definitely have a lot of work porting things over, and that's something I don't think that would happen until Trinity makes several more releases and starts pulling in more developers. I certainly couldn't do it though, I can barely do the Hello World example in the Qt4 tutorials, though it will be a consideration once I feel comfortable handling large chunks of code.

Tim

<snip>

...

KDE3 has been replaced by more modern software.

</snip> No it hasn't. A true replacement, which is what I was implying when I wrote my earlier message, would have all of the same functionality in an interface that is just as easy to use and powerful as the original was. KDE4 is not a replacement of KDE3, it is a re-imagining/reboot of KDE with completely different goals than KDE3.

If the applications have been reworked to use Qt4, and contain the same functionality, as long as maintained, i'm ok with the Qt4 version. If it's a KDE4 dependent application (uses KDE4 headers), stick with the older one.

Yes, these are my thoughts as well.

...

...

c.) Rely on old unmaintained libraries with no modern replacement

I am excepting Qt here. My original intent was to kick out software that relies on ancient, special purpose libraries that cannot feasibly be "resurrected" and maintained. For example, anything using deprecated and removed kernel calls, etc.

Um, Piki, you seem to be on a different page? I think? We have tQT for Qt4 in progress right now. Qt3 is at version 3.3.8c (use the patch on the trinity Wiki) We're not rewriting KDE3 to use Qt4 - we're just going to use tQT to have the missing Qt3 functions work in Qt4. So, like a Qt3 compataility layer on top of qt4

This is correct.

Ilya, we just don't have the manpower to maintain that entire set of applications. If you would like to step in and start TQt converting, build testing, and adding to SVN some of those applications, then I would assist wherever possible. But as it stands I have my hands full with TQt, Serghei has his hands full with CMake, and everyone else is busy with needed improvements to the system or distibution packaging. Please remember that I and other developer here do not make any money off of Trinity (any donations are being used to "feed" the servers with power and Internet) and therefore we all must spend some time on our day jobs as well! ;-)

Tim

On Tue, Jan 25, 2011 at 14:35, Ilya Chernykh neptunia@mail.ru wrote:

In that case one have to use Qt4 and Qt3 software in parallel. I know you are trying to port KDE3 to Qt3 but I think this work is still far from being complete. I also skeptical about that a fully functional port is possible: what about the much-beloved themes ant styles? Also I heared Qt4 has some differences from Qt3 which make complete similarity impossible.

tQT is supposed to fill those gaps. :)

Also note that Qt is going to renew on a regular basis: after Qt4 there will be Qt5 which will lack any Qt3 compatibility features. That's why I would suggest to stick with Qt3 and fork it.

Yes, and hopefully Nokia will be smarter than Trolltech and make the Qt4 -> Qt5 an undesirable move.

I do not know how to deal with TQt and so, and also there is no Trinity in OpenSUSE yet. Currently I maintain the KDE3 repository in OpenSUSE and this takes much effort. I also port/pack the missing packages.

Is there a guide to this? I think you mentioned to samelian sometime ago about this; I could be wrong.

On Tue, Jan 25, 2011 at 14:59, Ilya Chernykh neptunia@mail.ru wrote:

On Tuesday 25 January 2011 22:47:21 Robert Xu wrote:

...

...

In that case one have to use Qt4 and Qt3 software in parallel. I know you are trying to port KDE3 to Qt3 but I think this work is still far from being complete. I also skeptical about that a fully functional port is possible: what about the much-beloved themes ant styles? Also I heared Qt4 has some differences from Qt3 which make complete similarity impossible.

tQT is supposed to fill those gaps. :)

How tQt is supposed to fill the gaps with Qt styles? Native Qt4 apps will never use Qt3 styles, so the will always look ugly.

... OH, styles. Haha... I knew that ;)

As far as I'm aware, we might have to throw that out. tqtinterface can't put Qt3 styles on Qt4 dialogs, unless a miracle happens.

On Tue, Jan 25, 2011 at 15:15, Ilya Chernykh neptunia@mail.ru wrote:

On Tuesday 25 January 2011 23:06:49 Robert Xu wrote:

...

OH, styles. Haha... I knew that ;)

As far as I'm aware, we might have to throw that out. tqtinterface can't put Qt3 styles on Qt4 dialogs, unless a miracle happens.

Since there is not a one good-looking Qt4 style, I will never Qt4. Besides this Qt4 has other bad things in appearance.

Qt4 is banned from my system in package manager.

Hm. We'll have to find something that can make Qt3 styles work on Qt4... /me grrrs at the qt4 developers for making this release so <honky>.

On Tuesday 25 January 2011 21:59:10 Timothy Pearson wrote:

I am excepting Qt here. My original intent was to kick out software that relies on ancient, special purpose libraries that cannot feasibly be "resurrected" and maintained. For example, anything using deprecated and removed kernel calls, etc.

If they used removed calls they would not build.

By the way, how do you solve the problem of hal removal? I think we will be in necessity to add hal to our KDE3 repo once hal is removed from tha base system.

On Tue, Jan 25, 2011 at 3:08 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:

...

By the way, how do you solve the problem of hal removal? I think we will be in necessity to add hal to our KDE3 repo once hal is removed from tha base system.

I'm working on a replacement using udev/upower.  It's a ways off though.

I don't know how hard this would be to do (I'm not quite there as far as learning how to program, nor am I a hadware expert), but an idea I came up with yesterday, haven't posted yet, is to replace calls to HAL (or other hardware system) with a few lines of code that can allow for plugging of a hardware system during compile. Also separate HAL from the main code and make it pluggable to this system, as well as udev and upower. Not all distros will use udev or HAL -- Ark is planning to make an interim release with HAL and udev, and use a custom replacement for HAL in the next release, we're just not using the custom replacement because of problems with KDE4. The pluggable system would make it easier to simply write libraries for Trinity for any new project that may exist in the future for hotplugging hardware without having to replace entire suggestions of code within KDE itself. Hopefully that makes sense and won't be too much effort.

On Tue, Jan 25, 2011 at 17:05, Kristopher Gamrat pikidalto@gmail.com wrote:

I was under the impression that tqt was to make Qt4 apps work with Qt3 apps and that therefor we would need tohave Qt4 libs installed on a Qt3 based system, and not the other way around? I am not on a different page but going based on what I have read.

No, you're on a different page... TQt is to help Trinity applications run on Qt4 and beyond. See my announcement for details.

On Tuesday 25 January 2011 21:59:10 Timothy Pearson wrote:

...

Ilya, we just don't have the manpower to maintain that entire set of applications. If you would like to step in and start TQt converting, build testing, and adding to SVN some of those applications, then I would assist wherever possible. But as it stands I have my hands full with TQt, Serghei has his hands full with CMake, and everyone else is busy with needed improvements to the system or distibution packaging. Please remember that I and other developer here do not make any money off of Trinity (any donations are being used to "feed" the servers with power and Internet) and therefore we all must spend some time on our day jobs as well! ;-)

This is pity. As I recall sometimes ago you asked which Qt3/KDE3 apps are missing and was inviting people to make bugreports for missing apps...

Yes, before HAL deprecation etc. Maybe in the future, if/when more developers are associated with the project, we can get those apps packaged.

Tim

On Wednesday 26 January 2011 10:07:52 Timothy Pearson wrote:

...

...

This is pity. As I recall sometimes ago you asked which Qt3/KDE3 apps

are

...

missing and was inviting people to make bugreports for missing apps...

Yes, before HAL deprecation etc. Maybe in the future, if/when more developers are associated with the project, we can get those apps packaged.

How Trinity is compatible with older apps not ported to tqtinterface? Probably we could combine the Trinity and KDE3 repos in one in OpenSUSE or add all those apps to the Trinity repo? What do you think?

Very close to 100% source compatible. I would like to see them in the Trinity SVN and then in the QuickBuild PPA, but I don't have the time right now. Would anyone here like to work on this?

Tim

On Wednesday 26 January 2011 10:43:16 Timothy Pearson wrote:

...

...

How Trinity is compatible with older apps not ported to tqtinterface? Probably we could combine the Trinity and KDE3 repos in one in

OpenSUSE

...

or add all those apps to the Trinity repo? What do you think?

Very close to 100% source compatible.

Whay about binary compatinility? I.e. if one installs Trinity and then adds a KDE3 repo to install some apps from there?

No. The two are NOT binary compatible. kdelibs has changed too much.

...

I would like to see them in the Trinity SVN and then in the QuickBuild PPA, but I don't have the time right now. Would anyone here like to work on this?

I meant the Trinity repo in OBS. Probably if the apps compatible wi can combine the repos so peple had only to add one.

If you (or another RedHat/OpenSUSE person) want to do that please feel free to do so. Personally I use Ubuntu and Debian and am therefore completely unfamiliar with the RedHat/Fedora/OpenSUSE way of doing things. The only thing I would ask is that the packager please send me a .tar.gz file that compiles against Trinity 3.5.12 so that I may add the new application to SVN.

Thanks!

Tim

On Wed, Jan 26, 2011 at 11:34 AM, Ilya Chernykh neptunia@mail.ru wrote:

By the way, what do you do with packages which require external dependencies (i.e. those which are part of the distro itself and not included in Trinity)? Can such packages be included in Trinity?

I hear most RedHat/Fedora puts selinux as dependencies in their apps, which isn't actually a dependency, more an added security type of thing. PCLOS puts a lot of GNOME stuff as dependencies for Firefox that have nothing to do whatsoever with Firefox. You'll need to see what is actually needed first, and see what Tim thinks of adding those.

<snip>

I think Tim should get an account on build.o.o and try it out... It does help to have everything in one place.

Sorry, I use Ubuntu/Debian, and there is only one of me, so I don't have the time to start learning the RedHat way of doing things.

The central Trinity source repository is the combination of SVN and any source tarballs available on the Trinity website. I encourage each distribution to use the package build/distribution system that suits them best, but the packages available on those systems should be built from the sources in the aforementioned Trinity source repository. In other words, if you need to alter the code to make it work, please let us know on-list so that we can make the change in SVN. ;-)

Tim

On Wed, Jan 26, 2011 at 6:08 PM, Ilya Chernykh neptunia@mail.ru wrote:

...

I think Tim should get an account on build.o.o and try it out... It does help to have everything in one place.

You meant OBS or what?

Build.o.o is build.opensuse.org. I haven't use it myself, it doesn't include my distros of choice, but it supports more than just openSuSE. I think the idea here is to test Trinity on more targets than just Debian/Ubuntu. If they include Ark and Yoper (the only two that have ever truly worked well for me), I'll consider using it.

On Wednesday 26 January 2011 18:28:13 Timothy Pearson wrote:

...

If you (or another RedHat/OpenSUSE person) want to do that please feel free to do so. Personally I use Ubuntu and Debian and am therefore completely unfamiliar with the RedHat/Fedora/OpenSUSE way of doing things. The only thing I would ask is that the packager please send me a .tar.gz file that compiles against Trinity 3.5.12 so that I may add the new application to SVN.

So having tgz and the patches is enough to have it ported to Trinity? In that case the most of the applications we discussed recently can be ported. They build well for the upcoming OpenSUSE 11.4 and if you say Trinity is source-compatible with KDE 3.5.10, nearly all of them are also compatible with Trinity.

By the way, what do you do with packages which require external dependencies (i.e. those which are part of the distro itself and not included in Trinity)? Can such packages be included in Trinity?

External dependencies (e.g. non-Trinity libraries) stay at the distribution level.

Yes, you are correct; if it builds against 3.5.12 I will put it into SVN. However, you will likely find that there are minor tweaks that must be done to the source code due to slight API changes in the Trinity core. No, I don't have a list handy at the moment. ;-)

Tim

On Wednesday 26 January 2011 10:16:36 Ilya Chernykh wrote:

On Tuesday 25 January 2011 19:42:56 Robert Xu wrote:

...

Um, Piki, you seem to be on a different page? I think? We have tQT for Qt4 in progress right now. Qt3 is at version 3.3.8c (use the patch on the trinity Wiki)

Your patch does not work, sorry:

Nevermind went Ok with -p2.