[MIR] gupnp-dlna

Bug #1785649 reported by Sebastien Bacher on 2018-08-06

This bug report will be marked for expiration in 15 days if no further activity occurs. (find out why)

12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gupnp-dlna (Ubuntu)
Undecided
Unassigned

Bug Description

* Availability

Builds on all supported architectures in Ubuntu and on sync from Debian

* Rationale

We would like to enable dlna sharing of media files, which is a GNOME upstream feature and relying on rygel which depends on the gupnp libraries, including the gupnp-dlna one

* Security

No CVE/known security issue

* Quality assurance

- the desktop-packages team is subscribed to the package
- the bug lists in upstream, the Debian PTS and launchpad are empty
- upstream has a testsuit which is not being used during build, we are going to look at changing that

* Dependendies

The package uses standard desktop libraries that are already in main (gstreamer, glib)

* Standards compliance

the package is using standard packaging (dh10), the standards-version is 3.9.8, the package is in sync from Debian

* Maintainance

Upstream is active and the desktop team is going to look after the package in ubuntu

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gupnp-dlna (Ubuntu):
status: New → Confirmed
Changed in gupnp-dlna (Ubuntu):
status: Confirmed → New
Matthias Klose (doko) on 2018-09-13
Changed in gupnp-dlna (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
Didier Roche (didrocks) wrote :

* -doc package: I think we should promote it as well in main, if the -dev is promoted. If so, this dep should be fixed: Depends: lynx | www-browser (first is lynx, in universe, www-browser is a virtual package not fullfiled?). In addition, it ships the doc in devhelp format (despite symlink from doc/ to gtk-doc/).
I don't think anyway that those are needed, we don't tend to have -doc dep on a browser implementation.
* NEWS file has: 0.9.2 - Remove the old gupnp-dlna-1.1.pc.in file. / Remove gupnp and gstreamer-* dependencies from VAPI file generation. I think the build-dep on libgupnp-1.0-dev may thus be optional (only used for VAPI file, see "Note to self" below). Do you mind checking?
* Any progress on getting the usptream testsuite running during package build and autopkgtests?
* debian/copyright has some missing copyright notices:
Copyright: 2012-2013 Intel Corporation for instance in * as GPL-2.0+
I think that's the only missing one, but better to double check
* 2 of the 4 lintian warning worth fixing IMHO:
W: libgupnp-dlna-2.0-dev: gir-missing-typelib-dependency usr/share/gir-1.0/GUPnPDLNAGst-2.0.gir gir1.2-gupnpdlnagst-2.0 -> dep from the -dev on the gir*
W: gir1.2-gupnpdlna-2.0: typelib-package-name-does-not-match usr/lib/x86_64-linux-gnu/girepository-1.0/GUPnPDLNAGst-2.0.typelib gir1.2-gupnpdlnagst-2.0 <- this one worth only an override IMHO + an explanation.

Minor:
- VCS could be updated in debian/control*

Note to self/remarks:
* I was surprised to find the build-dep on libgupnp-1.0-dev on this universe package. I checked the binary packages though, and there is no dep on libgupnp-1.0-4. It's not statically linked either, but only used for generated the vapi file.

I think some of the stuff should be addressed like test running before I give my +1. Then, as this is a network protocole (as for the whole dlna stack), I will defer to the security team for a review from a security perspective. I didn't spot anything crazy in the code itself, but I prefer deferring to experts :)

Didier Roche (didrocks) wrote :

Tests are actually ran during package build (but one is skipped, as it needs a more complex setup). So, good in that regard. Should it ran as autopkgtests though?

Sebastien Bacher (seb128) wrote :

Thanks for the review, some of the fixes are commited now, also some tweaks still needed before upload (see question bellow)
https://salsa.debian.org/gnome-team/gupnp-dlna/commit/b161b805

> * -doc package: I think we should promote it as well in main ... If so, this dep should be fixed: Depends: lynx | www-browser

Done, changed to a Suggests: devhelp

> I think the build-dep on libgupnp-1.0-dev may thus be optional

Seems to be indeed, no difference without it, I removed it

> * debian/copyright has some missing copyright notices:
> Copyright: 2012-2013 Intel Corporation for instance in * as GPL-2.0+

Thanks, fixed now

> * 2 of the 4 lintian warning worth fixing IMHO:
> W: libgupnp-dlna-2.0-dev: gir-missing-typelib-dependency usr/share/gir-1.0/GUPnPDLNAGst-2.0.gir gir1.2-gupnpdlnagst-2.0 -> dep from the -dev on the gir*

That's a bit tricky, there is no corresponding gir (which is the cause for the other lintian warning), they preferred to bundle the gir in the same binary and use a provide, in that context I don't think adding the depends makes sense? would you be ok with a lintian override?

> W: gir1.2-gupnpdlna-2.0: typelib-package-name-does-not-match usr/lib/x86_64-linux-gnu/girepository-1.0/GUPnPDLNAGst-2.0.typelib gir1.2-gupnpdlnagst-2.0 <- this one worth only an override IMHO + an explanation.

k (not done yet, pending on what to do with the other warning)

> Minor:
> - VCS could be updated in debian/control*

done in the Debian vcs already so stagged for the next upload

Do you want autopkgtest for that specific component or would be one for the gunpn stack enough?

Didier Roche (didrocks) on 2019-02-12
Changed in gupnp-dlna (Ubuntu):
assignee: Didier Roche (didrocks) → nobody
Didier Roche (didrocks) wrote :

Let's turn those as incomplete to get off the list until we get over them again (probably next cycle).

Changed in gupnp-dlna (Ubuntu):
status: New → Incomplete
Didier Roche (didrocks) wrote :

on the autopkgtests question, I guess some for each components will be good to have a finer grained migration prevention. (even if those are testing the same thing, duplicated between packages).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers