https://bugs.kde.org/show_bug.cgi?id=393255
--- Comment #8 from Maximiliano Curia <[email protected]> --- (In reply to mbiebl from comment #5) > (In reply to Maximiliano Curia from comment #4) > > (In reply to mbiebl from comment #3) > > > Perhaps just dropping the Build-Depends, disabling the futile attempt > > > to use NetworkManager would be a better option than bothering with a > > > patch? > > That's my current plan. As soon as kdesignplugin leaves NEW, I'll upload > > 5.45, which drops the networkmanager build dependency. > I guess it would still make sense to fix this code upstream. If that is not > going to happen, maybe it > (In reply to Maximiliano Curia from comment #4) > > (In reply to mbiebl from comment #3) > > > Perhaps just dropping the Build-Depends, disabling the futile attempt > > > to use NetworkManager would be a better option than bothering with a > > > patch? > > That's my current plan. As soon as kdesignplugin leaves NEW, I'll upload > > 5.45, which drops the networkmanager build dependency. > > As lubo correctly noted, due to the bug in build system, the > networkmanagerstatus.cpp code was never compiled, as NM_0_7 was never set, > even if NetworkManager.pc was found. > So the question is, whether to rip out the NetworkManager code completely > (upstream) or fix it. Well kdelibs4support is a porting aid, a library that provides some interfaces that were available in kde4 but are not part of kde frameworks 5 (they have a suitable replacement in the kf5 family but it might not always be trivial to migrate to), as such it's highly disrecommended to use it. So, I wouldn't bet on upstream fixing, or even accepting a patch to fix, something that was always broken. It might make more sense to drop the dead code (as long as it doesn't break any api). Happy hacking, -- You are receiving this mail because: You are watching all bug changes.
