On Mon, 4 Jan 2016 23:47:33 +0300 Fat-Zer <fatzer2@...> wrote: > Hi, nice to see yet another gentoo person here... I've been here for a long time--I just don't talk very much. ;) > 2015-12-29 22:00 GMT+03:00 E. Liddell <ejlddll@...>: > > I'm embarking once again on my periodic quixotic quest to corral all ebuilds > > (Gentoo packages) for Trinity and combine them into a usable overlay. > > > > Is anyone else (Fat-Zer?) still working on this? > > > > If not, does anyone know of any old overlays with substantial material that > > isn't in the following? > > > > https://github.com/serghei/gentoo-trinity-overlay/ (Serghei's--long dead) > > https://github.com/Fat-Zer/trinity/ (Fat-Zer's--still on 3.5.13) > Just to be noted it also contains live ebuilds which work well enough... > I don't really want to maintain releases because, firstly, I > personally use git versions... secondly it will require to solve some > problems about visioning since migration to R14 numeration etc... and > thirdly, I doubt that there are anybody really interested in them... I hadn't intended working with live ebuilds or anything before 14.0.0, since I'd also noticed a lot of little problems coming out of the change in version number styles. I've actually been using your live ebuilds as a starting point for working with the applications that aren't part of tdebase. So far they've all worked for 14.0.0 with minimal changes, except for kiconedit and tdegraphics-tdefile-plugins (one failed to compile, the other to install, I think). > > https://bitbucket.org/mgebert/gentoo-trinity (dropped by author as of July) > > (plus the one I was working on with Roman back in 2011, for which I > > ironically have the materials but not the URL) > > > I was noticed about the overlay before... But AFAIR firstly it removed > the older version from the git (which I didn't like), so it has > required a manual merge; and secondly, I didn't like something about > the ebuilds themselfs (some extra DEPs AFAIR) so I was gonna to give > them a review before the merge... so after a while I forgot about that > and so one.... *blah* my apologies to Martin... If I get anywhere with this, I'm going to have to email him, since he doesn't seem to be hanging around here. Just as a courtesy, to let him know I may be incorporating some of his work. I know his KEYWORDS don't match yours (he had ~x86 only for all ebuilds). Now that you've warned me, I'll check his DEPs against yours and against kde-sunset. > If you still have the material, please push it somewhere to have it around... For all I know, it might still be on github (it was under Roman's account, not mine). I can't find any trace of it now, though. I'll have to sort through my old email one of these days to see if I can find the messages I exchanged with him. > I'm not aware about anybody else still working on it... I didn't think there was, but I figured I'd ask. > > In particular, I'm looking for better post-kde-sunset support for the > > packages still building with autotools. > > > There is nothing ready to use and gentoo-specific if you ask about > that... I myself won't support it, because IMHO It should have been > dropped years ago... I spent three days on it and got nowhere useful. I can get the packages to configure, but the ones I tried errored out during the actual build. I suspect there's an issue with the portage sandbox. Either that, or I mangled the supporting eclasses while I was ripping out code for obsolete KDE3 (and KDE2!) versions. Or some of the old patches built into the eclasses are doing something evil. Too many possibilities, and I'm not knowledgeable enough to sort through them. > If you have some wishes on porting some specific packages to cmake and > adding them to the overlay, I can handle it, but take into account > that my human powers are limited... You've already packaged everything I use myself except k3b, filelight, kmix, and a couple of things from tdegames. I can live without the games, but I may ask you to do k3b and filelight if I can't get them to work any other way. After I gave up on the autotools build system, I decided to try my hand at doing the cmake ports for the remaining base packages myself. We'll see how that goes. I've got a tentative set of files for kdat, but I've been too chicken to actually try to use them yet. ;) Even if I can get this to work, it's going to take a very long time. I'm also only human, after all. I've spent most of my programming career up to this point avoiding C, C++, and their associated build systems. I should have known I was building up karma. > > I keep hoping that someone else will take up the torch on this, but everyone > > who's tried seems to lose interest within a year or two, so I'm reluctantly > > going to give it another shot. The intention here is to: > > > > 1. collect existing materials in one location > > 2. do appropriate version bumps as new versions of Trinity come out > > (I'll be automating this as much as I can) > > 3. try to get *something* into the official overlays list and the Gentoo > > wiki, so that people at least know it's there (an unfun but necessary step) > > 4. centralize efforts so that people interested in working on this don't > > get mired down in version-bumping old ebuilds > > So all in all: > 1/2: If you still think that version bumping of releases will be > appreciated by somebody (at least more than two persons) I'll try to > manage myself to do it (but no promises here)... > There are not a lot to collect beyond that.. I suppose the furtherer > maintaining will be likely peace a cake... Only the testing may be > quite painful... Depends on how thorough the testing needs to be. I've already figured out how to version-bump, re-manifest, and build all the ebuilds in the overlay with a Perl script (it helps that everything that needs to be bumped has the same target version number). I've just got to smoothe out a few more details, and then I'll use it to bump everything I've got from 14.0.0 to 14.0.2 and see if it works. Testing all the packages thoroughly with one or two people isn't possible, period. I'm checking each new ebuild I add to make sure that the program starts and a sensible-looking GUI comes up (where appropriate). After that, I intend to do the same check in rotation for the packages I don't actually use, looking at one or two meta-packages each version-bump. I mean, there isn't much more I *can* do. > 3. I don't really think it should be listed in it's current state > (with or without version bumps) among other (semi)official gentoo > mirrors, because it really incomplete (at least doesn't contains all > base modules) and, fairly speaking, quite crappy (e.g malformed > desktop files)... But I can easily reconsider that... The desktop files are only a concern if they're so malformed they don't work. Otherwise, the average user (and even many developers) won't care. Likewise, other problems only matter at this stage if something is broken in a way that would upset the users. Being up to the same standards as the main portage tree would be nice, but I don't think that's practical without more manpower. The missing base modules, on the other hand, are a problem. That's why I'm trying to fix it. tdeaddons has already been ported to cmake and I've already thrown together ebuilds for a couple of the packages (kate-plugins works quite nicely, but I had less luck with kicker-applets). However, if I can't get at least most of tdeadmin, tdepim, and tdemultimedia to work, I won't be trying to make this an official overlay. That's about 50 more ebuilds. Ugh. Having the other packages in there too would be nice, but tdegames isn't a necessity and edu, webdev, and accessibility are only of use to small subsets of users. > 4. IMHO there are not a lot what to centralize... I suspect that one of the problems with TDE on Gentoo is that most Gentoo users haven't even heard of it. Making access easier will (I hope) draw the attention of some people. If even one of them pitches in to write and test ebuilds, it would be a huge help. At that point, the centralization and the version-bumping system will become more useful. Maybe I'm just dreaming, but I'll see if I can keep things moving forward for long enough this time to actually get somewhere. E. Liddell