Talk:Trinity

From ArchWiki
Latest comment: 15 July 2020 by EdwardTheHazardous in topic Outdated?

TDM systemd service file

I wrote a systemd service file for starting TDM and put it on the TDE bug tracker. The report is at TDE Bug 1458. Piki (talk) 16:51, 15 May 2013 (UTC)Reply[reply]

Trinity Build

Section below may be outdated, but it should probably still be built in a chroot

You are welcome to investigate the effects of the build environment, but please do not suggest "should probably still" unless you know what you are talking about and have the data to back it up.

The "outdated" section to which you refer is effectively from 2011‎ February 7. It reads:

After many attempts to find a way to prevent cmake from using Qt4 includes, the current thought is that building Trinity on Arch must be done in a clean environment.

In the intervening five years, the Trinity maintainers have become the official repository for Qt3, while qt4 and qt5 includes and libraries are kept rigorously distinct. Similarly, in that time, Trinity has made changes to allow TDE to coexist with Qt4 and KDE4, and thereby, with later revisions also.

I am going to say that that "clean environment" section is obsolete. Thx1138 (talk) 01:24, 29 March 2016 (UTC)Reply[reply]

Building in a chroot helps in finding and preventing issues with PKGBUILDs, especially in complex package chains. As such, every package in the official repositories is expected to build inside one. Considering it takes 3 commands to do so (mkdir, mkarchroot, makechrootpkg), it's a good idea to encourage users into taking that approach. I'll try so myself and report my findings.
Either way, said section was mostly a duplicate, so I removed it. The article should include a link to DeveloperWiki:Building in a Clean Chroot though. -- Alad (talk) 04:36, 29 March 2016 (UTC)Reply[reply]
Well, with most of the make/depends missing in the PKGBUILDs, it already failed at tqt3. This might take some time ... -- Alad (talk) 04:53, 29 March 2016 (UTC)Reply[reply]
Uploaded a cleaned up version to the AUR: tde-tqt3AUR. The issue was that most of the dependencies were in the pkgname depends array, rather than the pkgbase one. I didn't see the point in the added complexity for some docs, so I made it a regular package. -- Alad (talk) 16:57, 29 March 2016 (UTC)Reply[reply]

Support for AUR packages is irrelevant if the version in the official repositories works

There are some similar issues though. tdebindings is not compatible with ruby2.2 or any later version of ruby, which would include, in particular, the "current" version from the "official" repositories. Do not suppose that somehow Trinity will support ruby version 2.3 when support for version 2.2 is being advertised as a new feature. For the moment, the official ruby package must be removed while tdebindings is being built and re-installed after, since Trinity is not compatible with the current ruby 2.3 package. Further, tdebindings does not currently have a configure switch to disable ruby support, but does build when ruby is not present. Thx1138 (talk) 01:24, 29 March 2016 (UTC)Reply[reply]

Yes, thanks for clarifying on that. Is there a bug report upstream? -- Alad (talk) 04:36, 29 March 2016 (UTC)Reply[reply]

replace ad-hoc script with link to makepkg and build order

You are welcome to write a single PKGBUILD file to build all of these separate tde packages. There are about thirty of them, in three separate catagories. In the meantime, don't make things more difficult for other people by removing this simple script. Eventually, maybe soon, there will be another TDE repository, and these build issues will not matter. Still, it is nice to have these PKGBUILD files for times when the repositories go away. There are still no "official" Arch TDE PKGBUILD files, and there are no AUR TDE PKGBUILD files. Thx1138 (talk) 01:24, 29 March 2016 (UTC)Reply[reply]

I've made some needed fixes to that script, but I'm still not convinced in keeping it. But in the end it's just a for loop with makepkg - which I assume you know before playing with experimental desktop environments - so I don't see how keeping it would make a great difference. Anyway, in its current state its not a deal-breaker to me. -- Alad (talk) 04:36, 29 March 2016 (UTC)Reply[reply]

Outdated?

I checked both the NasuTek repo and Manley's GitHub/PKGBUILD repository, and I noticed that both are behind the Trinity upstream. 13 months, to be exact. The version available in both methods seem to be R14.0.5 (last updated in 19th of June, 2019) while the Trinity upstream has R14.0.8, released in April 29th, 2020.

Something else to note: for the longest time, the NasuTek repo with the binary packages was unreachable for me. Only recently did I finally see that I can reach it again, but the NasuTek website itself keeps giving me the 500 error. Weird.

I'll probably still install them because I love Trinity that much, but this is something to keep in mind. Hope Manley gets around to updating it soon.

EdwardTheHazardous (talk) 08:58, 15 July 2020 (UTC)Reply[reply]