2 Feb
2012
2 Feb
'12
2:01 p.m.
On Thu, 2 Feb 2012 10:52:39 +0100
"roman" <lists(a)hasnoname.de> wrote:
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.
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.
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.
Hey,
On Wed, February 1, 2012 16:57, E. Liddell wrote:
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.
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. 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? 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.;) 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. :( 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.