Re: [Kde-hardware-devel] upnp backends, what to do with them?
On Tuesday 09 October 2012 19:35:04 Alex Fiestas wrote: For some weeks/months now the upnp backend as not been building with this error: libHUpnp.a(hmulticast_socket.o): (.data.rel.ro._ZTVN5Herqq4Upnp16HMulticastSocketE[_ZTVN5Herqq4Upnp16HMultica stSocketE]+0xe8): undefined reference to `QAbstractSocket::writeData(char const*, long long)' Odd, it never stopped building for me... Just tried again and it just build. That's a linking error BTW, so could be your copy of HUPnP being busted. I remember that we were super close to have it working but we failed to finish the last mile :/ Well, it wasn't super close... at some point I had it working in production! Nowadays I lost track of the upnp ioslave though, so it's not super useful... So I can't stop wondering what to do with those backends. kupnp is already disabled in cmake, what's its status? upnp is not working, but I'm quite sure we almost got it working at some point. Is anyone willing to step up and try to gix it? Paulo, Kossebau, do you feel like giving this another try ? I'd really love to see this moving forward, upnp support is quite important :/ Agreed, we might need new blood for it though, they are good targets for an attract contributors program. Paulo is pretty much MIA lately, and Friedrich is super busy... My main concern is that the dependencies of both backends are under maintained as well. HUPnP is still a one man show, and it didn't see a release in a long while (there's still activity in the repository though). Cagibi is mainly Friedrich baby (did I say he was super busy?). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[Kde-hardware-devel] upnp backends, what to do with them?
For some weeks/months now the upnp backend as not been building with this error: libHUpnp.a(hmulticast_socket.o): (.data.rel.ro._ZTVN5Herqq4Upnp16HMulticastSocketE[_ZTVN5Herqq4Upnp16HMulticastSocketE]+0xe8): undefined reference to `QAbstractSocket::writeData(char const*, long long)' I remember that we were super close to have it working but we failed to finish the last mile :/ So I can't stop wondering what to do with those backends. kupnp is already disabled in cmake, what's its status? upnp is not working, but I'm quite sure we almost got it working at some point. Is anyone willing to step up and try to gix it? Paulo, Kossebau, do you feel like giving this another try ? I'd really love to see this moving forward, upnp support is quite important :/ Cheerz ! ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] upnp backends, what to do with them?
Hi, Am Dienstag, 9. Oktober 2012, 19:35:04 schrieb Alex Fiestas: For some weeks/months now the upnp backend as not been building with this error: libHUpnp.a(hmulticast_socket.o): (.data.rel.ro._ZTVN5Herqq4Upnp16HMulticastSocketE[_ZTVN5Herqq4Upnp16HMultica stSocketE]+0xe8): undefined reference to `QAbstractSocket::writeData(char const*, long long)' I remember that we were super close to have it working but we failed to finish the last mile :/ So I can't stop wondering what to do with those backends. kupnp is already disabled in cmake, what's its status? KUPnP was a small wrapper around the Cagibi SSDP daemon and only could report which devices are available and their static properties, but not interact with them to e.g. query dynamic states or even invoke actions. That is why the solid plugin was redone with Hupnp, from what I understood. I was not involved and have no clue about Hupnp. upnp is not working, but I'm quite sure we almost got it working at some point. Is anyone willing to step up and try to gix it? Paulo, Kossebau, do you feel like giving this another try ? As I still do not own a single device where I need UPnP to work (like mediaservers as the most important application) I am sorry but must say that this stuff moved pretty low on my overcrowded TODO list, so nothing to expect here from me the next months. The only thing I might have interest to fix is that the latest Cagibi does not correctly work on the system D-Bus, but I never had enough of feedback to fix it properly. Possibly the Amarok UPnP plugin might also still rely partly on Cagibi and thus does not work with the latest version. As well as the network:/ kio-slave for UPnP devices, which relies for that on Cagibi as well and currently just lists zeroconf ones. So if anyone needs Cagibi working and is seeing into fixing it, I can and will assist. Cheers Friedrich ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
