On Fri, 3 Feb 2012 00:19:14 +0100 "roman" <lists@...> wrote: > Hey, > > On Thu, February 2, 2012 15:01, E. Liddell wrote: > > 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. > qt-meta-3,3,8d should already be in the repository That's a step forward. I was looking at dbus-tqt and tqtinterface earlier today. I need to change the qt-3.3.8d dep to qt-meta-3.3.8d, but after that I should be able to test and upload. That should be everything we need to get started on kdebase. > > HAL is optional for everything except . . . was it knetworkmanager? > Ok, i thought it was still needed for automounting with konqueror or sth. > like that. Automounting is itself optional, though--I don't use it. > > Something I don't have installed, anyway. ksmserver can optionally > > use it, but doesn't have to. We need something like: > > > > src_configure() { > > mycmakeargs=( > > -DCMAKE_INSTALL_RPATH=/usr/tde/3.5/lib > > -DBUILD_KSMSERVER=ON > > `cmake-utils_use_with hal HAL` > > > > in the ksmserver ebuild and this appended to profiles/use.desc: > As far as i know we need just to add the inlcudes from hal? Could you > take a look at that as i am not really familar with that.. The above code is approximately what I used while installing my Trinity tester (just the path is different). If the hal use flag is on, it asks for HAL and compiles it in, or should (I don't think I ever actually took it as far as fetching/installing HAL, I just tested to make sure the dependency was working). If not, it doesn't ask and compiles anyway. Basically it's the same setup as KDE3 had before HAL was deprecated. I had intended to add some messages ("you are compiling this package without HAL support, and therefore automounting may not work"/"you are compiling this package with HAL support--please be aware that HAL is unmaintained and bugs caused by it will be ignored"), but never quite got that far. It's probably best to have the flag on by default, now that I think about it. The people who want to avoid HAL are more likely to read the fine print than those who just want automounting to work. > > I have the last hal ebuild from the main tree floating around here > > somewhere, if > > we want to include it in the overlay. > I already uploaded the latest hal/hal-info to the repo since it was gone > from the tree i had put it in kde-sunset also. > I think for now we can keep it around if we can get knetworkmanager > working... I don't think there's any harm in having the ebuild available--people can choose whether or not they want to install it. > >> 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. I did strip some stuff out of qt3.eclass earlier today that had been marked as deprecated--I think we can safely say that anything having to do with pre-slot versioning is obsolete. There may be a few other functions like that around. > Ok, then we just need to revisit the naming scheme;) What would be the > best way here? Or did we agree already on this: > > - renaming only the categories -> users have to "emerge > trinity-base/kdebase-startkde" > - Changing the prefix to /usr/tde/3.5/ > nothing more! I think that's probably the best way to go for this release. > >> > 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. > Uhm... whats that for again? It's mostly just a description of the category. We can probably steal the one for kde-base and do a search-and-replace on "KDE". > >> 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. > Ah ok, so scratch the above then;) tde-base or trinity-base then? I like trinity-base, for reasons previously given. > > 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. > Yes, we can lower the priority on that i guess.. and start replacing > automake in R14. That was my thought. > > 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.) > Hehe, if you can't get github working i can also setup a repo on my own > server.. I'm pretty sure it's my weird browser setup--the account exists, as I found out when I tried to recreate it, but my login attempts don't register. I'll try tomorrow with a different Firefox profile, and/or Chromium and/or the command-line git client. If none of those work, then we can worry. > For the basic kdebase-startkde i guess i do have probably most of the > ebuilds working. But i still do have 2 errors during runtime: > > 1. Only the first click on the K-Menu gives me a "Malformed URL"-Error. I haven't seen that one (I did have a hellish time when I first installed because environment variables weren't being set, but I eventually figured that out). > 2. via ALT+F2 Launcher i can run firefox, thunar, evince, gimp (i guess > all X11-progs), but cant seem to get a simple urxvt or other console-tool > running. Anyone know what this error could be? No clue. > > 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. > Very good! I don't know how much distro-differences are in the linker-part.;) None in the software itself as far as I know, but the default options chosen can be very different.