On Mon, 4 Jan 2016 23:47:33 +0300
Fat-Zer <fatzer2(a)gmail.com> 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(a)googlemail.com>om>:
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