MIR hupnp

pre-promoted to main for alpha 1

I looked at this, and it's mostly good. But a blocker for MIR sign-off is that there is no symbols file (or usage of dh_makeshlibs -V). This package's API is specifically not stable and subject to revision. To help with upgrade issues, I'd want to see a symbols file.

I'm also passing to security team for a check because this is a network protocol package.

(Additionally, I note that upstream has released a 0.8 release; might be nice to see an updated package.)

It seems strange that QtSoap is included in this package, but since it doesn't exist anywhere else, I guess that's fine.

For the audit, nothing jumps out quickly at me. I am curious, however, if running software with a UPNP server would violate the No Open Ports policy.

There are No Open Ports exceptions for the DHCP client and mDNS. This seems similar, but Kees, how do I get a formal answer from the security team about UPnP and the policy?

So I'm setting this to Incomplete for the symbols file issue and the UPnP question.

.symbols files added in 0.0~svn77-0ubuntu3

I've moved it back to universe pending the security decision

What portion of the code would be running the UPnP service? I.e. what would it look like for the default system? UPnP is similar to mDNS, so it may fall into the "network infrastructure" exception clause.

Failed to build on amd64/armel due to differing symbols files.

This package is in universe, and for some reason kde4libs (in paticular, the libsolid4 binary) already depends on it. This renders the entire Kubuntu uninstallable, so I promoted only the libhupnp0 binary to main to unbreak Alpha-2.

The code that uses it is in kde4libs solid/solid/backends/upnp. It gets run by the Plasma desktop device notifier which announces new devices on the system, or in this case the local network. It has actually been disabled in kdelibs 4.6.0 due for release tomorrow due to usability issues (http://websvn.kde.org/branches/KDE/4.6/kdelibs/solid/solid/CMakeLists.txt?view=log) making this MIR less urgent.

I'll take a look at the symbols issues

[Expired for hupnp (Ubuntu Natty) because there has been no activity for 60 days.]

So, it is almost 2 years and it is a big blocker for the whole UPnP on KDE. See also bug 975327 for details.

 * No Open Ports actually probably probably doesn't apply anymore (since Kubuntu is no longer an official Canonical flavor).

 * Really, kdelibs should be in universe. I note that a few packages in main build-depend on it though (libproxy, libreoffice, subversion), keeping it in main against its will. Which causes problems like this for the Kubuntu folks. (sorry!)

I'm looking at this again. Looks like we can even sync with Debian now.

Approved. I sync'ed from Debian. The symbols file got dropped, but we no longer block a package on that, especially a C++ one. It'd be nice to see a Kubuntu team subscribed to bugs.

This bug is marked fix-committed but hupnp is still in universe. http://packages.ubuntu.com/en/source/saucy/net/hupnp . What needs to be done for hupnp to become part of main?

Something in main should depend on it, then it will show up in the component-mismatches report, and then an archive admin will try to fix that, note this bug is fix committed, and promote it.

So the next step should be letting kdelibs depend on hupnp again (looks like you need to add a Build-Depend and set HUPNP_ENABLED to TRUE).

So, who has the power to make something in main (kde4libs, i suppose) depend on hupnp? It is rather unacceptable that this and #975327 are both stuck in ubuntu's bureaucratic limbo since 2012, if everything is already fixed and commited.

Am 02.02.2014 01:51, schrieb José Tomás Atria:
> So, who has the power to make something in main (kde4libs, i suppose)
> depend on hupnp? It is rather unacceptable that this and #975327 are
> both stuck in ubuntu's bureaucratic limbo since 2012, if everything is
> already fixed and commited.

there is no one hindering you to prepare an upload, test it and attach the
debdiff to this report.

  Matthias

kde4libs is no longer in main. I believe this is a result of the "universe build dependencies are allowed for packaging in main" change done shortly before the release of Ubuntu 16.04 LTS. Therefore, I am closing this bug.