On Thu, 2 Feb 2012 10:52:39 +0100 "roman" lists@hasnoname.de 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.