On Thu, 2 Feb 2012 10:52:39 +0100
"roman" <lists@...> wrote:

> Hey,
> 
> On Wed, February 1, 2012 16:57, E. Liddell wrote:
> >> Mhh my guess is we need to put qt3 in a seperate directory (or should be
> >> keep it in /usr/qt/3 ?) otherwise there will be tons of complications.
> >
> > With the next version, we should be able to go to /usr/tqt, but moving to
> > there with 3.5.13 might be a bit premature.
> I agree, lets stick with the default place. I do have an ebuild for
> qt-3.3.8d and removed all patches that I didn't need to get it working.
> For some i couldn't find the bug-id since it was long gone on
> bugs.gentoo.org or didn't apply against the latest version.

I believe I used the ebuild for 3.3.8d from Serghei's overlay while setting up
my test machine.  Basically, his kdebase ebuilds are functional, they just
have to have filename changed to 3.5.13-only and SRC_URI changed to 
pull from the Trinity mirrors.

> > Okay, so the first step is to get tde-base, its dependancies, and the
> > eclasses (I think cmake only uses -functions and maybe qt3) in
> > there. Then ebuilds for the other stuff that's already been moved
> > to cmake. After that, we can look at the rest.
> Yes, i am currently trying to get the dependencies in-line so they can be
> used by anyone. Hal is still required right?

HAL is optional for everything except . . . was it knetworkmanager?
Something I don't have installed, anyway.  ksmserver can optionally 
use it, but doesn't have to.  We need something like:

RDEPEND="trinity-base/kdelibs:${SLOT}
    dev-libs/dbus-tqt
    hal? ( sys-apps/hal )"
DEPEND="${RDEPEND}"

S=${WORKDIR}/kdebase

src_configure() {
	mycmakeargs=(
		-DCMAKE_INSTALL_RPATH=/usr/tde/3.5/lib
		-DBUILD_KSMSERVER=ON
		`cmake-utils_use_with hal HAL`
	)

	cmake-utils_src_configure
}

in the ksmserver ebuild and this appended to profiles/use.desc:

#added for Trinity 3.5.13 as a stopgap measure
hal - Activates functionality depending on HAL, the obsolete Hardware Abstraction Layer

I have the last hal ebuild from the main tree floating around here somewhere, if
we want to include it in the overlay.

> In kde-*.eclass i think it might be wise to comment/remove all functions
> und reenable the ones that are still needed for the remaining non-cmake
> ebuilds on a as-needed basis.

Mmph.  I think most of them are used--those eclasses provide their own
pkg_config, src_configure, etc. that replace the standard ones.  The cmake
ebuilds only use -functions and qt3, anyway--the other two will be going
away once we have no more autotools, so it isn't worth spending more time
on them than we absolutely have to.

> >> > how adding whole categories works.  I'm also looking at changing the
> >> > names of the eclasses (kde-functions -> tde-functions or
> >> > trinity-functions,
> >> > etc.)
> >> Definitly! I would go with tde-* it's less typing.;)
> >
> > I'm a bit worried about it being too similar to kde-, though.  Doesn't
> > matter
> > for the eclasses or directories, but for stuff end-users are going to have
> > to
> > type on a regular basis, I'd like to be as distinct as possible.
> Adding new categories is easy, just create the folder-structure and
> portage will complain that you need to add your own categories into
> profiles/categories.;)

Ah.  We should probably have a metadata.xml too.

> About it being too similar... unless we change the actual ebuild-name
> (like kdebase-startkde -> tdebase-starttde) they have to emerge it via
> 'emerge trinity-base/kdebase-startkde' since the package exists in another
> category as well).
> So how far do you wanna go with the renaming?

For this iteration not very far, because it messes with $P and its relatives--
only the category should change.  For R14, follow the parent project, which
would give us, frex, tdelibs and twin, but not tonqueror.

> >> Yes, i think there is at least a cmake-option or variable in the eclass
> >> that specifies the moc-location or the kde-prefix to use.
> >
> > I'm more worried about the non-cmake packages in that regard, but
> > they're screwed up anyway. Since no one on the trinity-dev list seems
> > interested in helping me sort out the linker problem that seems to exist
> > in half the packages, I may need to go to gentoo-dev for help, which is
> > something I'm not looking forward to. :(
> Ok, but lets try to get the cmake-parts in there first and worry about
> that later. Maybe then we have a tqt3 and just have to ask Serghei.;)

Serghei is more intent on attacking the R14 source in git than the current
release, though.  Not that there's anything wrong with that (and live ebuilds
might be a nice-to-have), but it isn't what I had in mind as a first step.

> PS: I hope i will have the cleaned eclasses and dependencies in git until
> Saturday since i am currently quite busy with work etc.. but i want to get
> this finally working on gentoo/funtoo and will have to take my time.

I'll probably have a couple of hours to put into this between now and then.
If I can get a github account actually set up (last attempt failed because I
didn't realize I was blocking their cookies), I'll see about uploading what
I have for kdebase/kdeartwork/kdegraphics and their deps once I've
cleaned and sorted everything.  (At the moment, I'm using a really messy
local overlay that mixes Serghei's stuff, kde-sunset, and my own work,
but I obviously can't upload that.)

> BTW i am not really running gentoo but funtoo, so i might ask there for
> some additional help. It's easier to ask for some help there since even
> D.Robbins is idling there sometimes. And who else knows portage better?;)

True--and from what little I know of him, he seems like a nice guy.
The Gentoo devs are more of a mixed bag, from what I've seen--some nice,
others really abrasive.

I have had an offer of assistance in sorting out the linker problem, but the
person involved is, I believe, with a different distro.  Still, we'll see what 
we can do.