28 дек. 2015 г. 4:15 пользователь "Nigel Taylor" < [email protected]> написал: > > On 12/27/15 20:50, Vadim Zhukov wrote: > > Hello all. > > > > At first, a small note for those who don't know: KDE nowadays consists > > three big collections of software: > > > > KDE Frameworks - mostly ex. kdelibs+kde-runtime. > > Plasma Workspaces - desktop components: KWin, panels, systray etc. > > KDE Applications - actual user applications and their more or less > > private components, including PIM stack, games, educational and so on. > > > > So here is a collection of ports used to build KDE Frameworks. It consists of: > > > > devel/kf5 - main stuff > > x11/kde-applications/Makefile.inc - contains additional tweaks for KF5 > > x11/kde-applications/gpgmepp - optional but useful dependency > > > > If you want to play, just unpack it under /usr/ports, go to devel/kf5 > > and type "make package". > > > > devel/kf5 directory in archive consists of a few additional files: > > > > * frameworks-list - list of all frameworks, including non-ported ones; > > at the present time there are exactly two non-ported frameworks, > > modemmanager-qt and networkmanager-qt, for obvious reasons. > > > > * test.pass, test.miss and test.fail - lists of frameworks currently > > passing, missing or failing their own tests, respectively. > > > > * calc_left - small script that lists sub-ports that are not packaged yet. > > > > I won't insist on comittin' those. I use them for automating my work. > > > > So the proposal is comitting files in this archive, and continuing > > work in-tree. The plan is to port Plasma, possibly adding something to > > x11/kde-applications if needed, and then start filling gaps in > > x11/kde-applications. I'm afraid that I'll be able to finish Plasma > > before lock, though. > > > > So... any okay to commit this piece of ...code? > > > > -- > > WBR, > > Vadim Zhukov > > > > > Just got attracted to bluez-qt. As first thing to look at, had to start > somewhere. > > COMMENT = Qt wrapper for BlueZ 5 DBus API > That didn't tell me much. > > A quick look, BlueZ appears to be a Linux Bluetooth stack, that's what > my search turned up. bluez-qt has a dependency on bluez, which I can't > see as a port. > > If there is no bluetooth - a qt wrapper around something that's not > there is not much use as a port. > > bluez-qt is in test.pass, that's pass for effectively returning "No > bluetooth devices avail" and skipping the rest of the tests. > > Maybe I just happened on the one bad example.
Yes, this framework is a stub. Like we had a kactivities stub for a long time, until KDE4 was switched to gcc4 module... I also laughed, like you, when I saw it compiling, passing tests and packaging happily. But some other software (I already found one Plasma component) links to it hardly. If, after porting the whole KDE5 stack, we'll find that bluez-qt framework is optional, I'll happily remove it, reducing further maintain pain. But now, it's more pain for me on skipping than on porting such easy frameworks. -- Vadim Zhukov
