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

--