On Sat, 4 Feb 2012 22:22:42 +0100 "roman" <lists@...> wrote: > 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. So long as they work, I don't think it matters who puts 'em there. > 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;) And so do many other people. It just doesn't suit my control-freak nature. ;) > > 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 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. > > 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... 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) >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. > 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. > >> > 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. We'll even get a Vietnamese translation as a bonus. 8) > >> 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... 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. > >> 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. 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. > 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.