MIR hupnp

Bug #682404 reported by Jonathan Riddell on 2010-11-28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
hupnp (Ubuntu)

Bug Description

hupnp is needed in main for kde4libs. I've checked the checklist and don't see any problems.

Jonathan Riddell (jr) wrote :

pre-promoted to main for alpha 1

Michael Terry (mterry) wrote :

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.)

Changed in hupnp (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Kees Cook (kees) wrote :

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.

Changed in hupnp (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
Michael Terry (mterry) wrote :

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.

Changed in hupnp (Ubuntu):
status: New → Incomplete
Jonathan Riddell (jr) wrote :

.symbols files added in 0.0~svn77-0ubuntu3

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

Kees Cook (kees) wrote :

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.

Martin Pitt (pitti) wrote :

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.

Jonathan Riddell (jr) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in hupnp (Ubuntu Natty):
status: Incomplete → Expired
Peter Antoniac (pan1nx) wrote :

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

Changed in hupnp (Ubuntu):
status: Expired → Confirmed
milestone: none → ubuntu-13.04-month-3
Michael Terry (mterry) wrote :

 * 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.

Michael Terry (mterry) wrote :

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.

Changed in hupnp (Ubuntu):
status: Confirmed → Fix Committed
carlosd (carlos-demaine) wrote :

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?

Michael Terry (mterry) wrote :

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).

José Tomás Atria (jtatria) wrote :

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.


Jeremy Bicha (jbicha) wrote :

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.

Changed in hupnp (Ubuntu):
status: Fix Committed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers