Hi, On Fri, February 3, 2012 02:17, E. Liddell wrote: >> 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. Well, qt-meta, tqtinterface and dbus-tqt should be working fine from the github-repo. I ran into some other problem though with one or two other ebuilds not finding "tqglobals.h" or similar. Those tqt-header files are located in /usr/include/tqt and not /ust/qt/3/include. So the path needs to be added to the configure options but i am not sure what the best way is to do that... But currently this is only for trinity-misc/kshutdown ( just ran sed over the files, which seems very silly to me, there has to be a better way). > Automounting is itself optional, though--I don't use it. I always liked the automount feature;) > 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. Yes i think it's a good idea to include hal, but we should look out for blockers (there were some i think from pciutils if i remember correct) > 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. After looking closer at the eclasses... uhhmmm lets keep them around until they have absolutely no use. Diving in there might be hard and not get us very far... I did patch the following though to get rid of the kde3-dir (also some 'designer-plugins' weren't found) - export kde_widgetdir="$KDEDIR/$(get_libdir)/kde3/plugins/designer" + export kde_widgetdir="$KDEDIR/$(get_libdir)/trinity/plugins/designer" >> - 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. Ok, if you can take a look at the repository i think the stuff in there should be working for x86/amd64. There is also a Documentation/TODO with packages i haven't gotten around to or couldn't get working yet like kdeartwork or kde-i18n.. >> > 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". That should do it. >> 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. To be able to push into the repo i need to give you access and you need to upload your pubkey to github if i remember correct... >> 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). Fixed! I was missing the kdebase-kioslaves. >> 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. Also fixed, though i don't really know why it wasn't working before... firefox and urxvt were in the same PATH and only firefox worked... anyway i changed the startkde-script and now it seems working fine. >> 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. Oh linker.. i had fun with that getting kshutdown working it always complains about unknown option "--sort-common". Can't help you there much though. PS: kontact is next on my todo does it really hard-depend on knotes now? greetings, Roman --