4 Feb
2012
4 Feb
'12
11:59 p.m.
On Sat, 4 Feb 2012 22:22:42 +0100
"roman" <lists(a)hasnoname.de> wrote:
And so do many other people. It just doesn't suit my control-freak nature. ;)
I think they were removed after HAL left the main tree. Anyway, the
worst known consequence of having both installed at once was that
device icons showed up twice in some applications, IIRC--an annoyance,
but not exactly a showstopping bug.
Trust me, if both the function of the code and its lack of usefulness for
modern Portage hadn't been clearly evident, I wouldn't have touched it.
(Anyway, I'm pretty sure that any Trinity build calling those bits would
have failed, since it didn't know about qt-3.3.8d)
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..
I have all of kdeartwork working (well enough for me to install it,
anyway) except kdeartwork-kworldclock, which
is dependent on one of the kdetoys applications that won't yet build.
Also all of kdegraphics except kdvi, kghostview, and kooka.
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.
We'll even get a Vietnamese translation as a bonus. 8)
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...
I was felled by a migraine yesterday and so am behind on doing anything about
this. Will try to sort things tomorrow if I can stay sitting up for long enough.
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.
We're starting to get things sorted out, thankfully. Just have to figure out
where the rest of the stray symbols are and amend the ebuilds (or the eclasses?)
to force both libraries into the linker.
Hi,
On Fri, February 3, 2012 02:17, E. Liddell wrote:
Well, qt-meta, tqtinterface and dbus-tqt should be
working fine from the
github-repo.
So long as they work, I don't think it matters who puts 'em there.
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. 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).
The default options for every merge will be in the eclasses, I think. For
single builds, the cmake-utils eclass has a couple of ways of passing options
back to emake, and probably to configure as well.
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"
Interesting. I wonder if that would fix the widget style ebuilds in x11-themes, too.
- 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.
Ah. We should
probably have a metadata.xml too.
Uhm... whats that for again? 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. 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. PS: kontact is next on my todo does it really
hard-depend on knotes now?
Could it be a plugin thing? There's a note about them in the old KDE3 ebuild.