> * There are a lot of crash reports in launchpad. Those are several years old 
> and shouldn't apply anymore. 
> Maybe a little bit of cleanup of really old one, and looking at more recent 
> ones will help once supported 
> to review real new crashes (between launchpad and errors.ubuntu.com)?

Done, the launchpad bugs are down to 7 & e.u.c is looks without real
issues.


> * What is going to pull rygel on the iso: directly seeded or a 
> recommends/deps somewhere? 
> Note that there is as well rygel-tracker which shouldn't be promoted until 
> tracker situation is deciphered.

gnome-control-center has the sharing UI, we plan to add the Recommends
to the service there


> * Some lintian warnings would be great to looked at, namely:
> - W: rygel-2.6-dev: pkg-config-unavailable-for-cross-compilation (multiple of 
> thm)

That's because the package is not using a multiarch location, do you
consider that a pre-requirement to get the MIR approved? It's probably
not too difficult to change the build but it requires some testing, etc.


> - W: rygel: uses-implicit-await-trigger interest /usr/lib/rygel-2.6 (line 1)
> - W: rygel: uses-implicit-await-trigger interest rygel-restart (line 2)

Fixed in 0.36.2-2 just uploaded to Debian (autosync to come)


> * I guess rygel-preferences isn't going to be promoted, correct? 
> (maybe we should list exactly the packages that are going to be promoted). It 
> has a dep as linking on libgssdp-1.0-3, which is in universe.

Correct, gnome-control-center is the UI to control the service in our
usecase


> * However rygel binary package has some dep issues as well:
>  - dep on libgssdp-1.0-3 (gssdp source in universe) and libgupnp-1.0-4 (gupnp 
> source in universe), which are not listed in the current MIR for the stack.

Right, those used to be in main but new MIRs filed now to have a new look 
before re-promoting
https://bugs.launchpad.net/ubuntu/+source/gupnp/+bug/1799974
https://bugs.launchpad.net/ubuntu/+source/gssdp/+bug/1799977


> - 2 recommends with its source in universe and not listed to be MIRed. 
> They should be downgraded to Suggests, if possible: gstreamer1.0-libav and 
> gstreamer1.0-plugins-ugly

Right, those needs to be demoted but let's keep the package in sync for
now it's going to lower the work until the other MIRs and this one are
approved.


> * If we want to promote rygel-2.6-dev to main, there is again the 
> libgupnp-1.0-dev dep as well which needs to be sorted out.

I don't think we need the -dev in main since we can build on universe.
Also gupnp has a MIR in review.


> * librygel-server-2.6-2 is a dep of rygel, and depends as well on 
> libgssdp-1.0-3 and libgupnp-1.0-4
> * librygel-renderer-2.6-2 is a dep of rygel, and depends as well on 
> libgupnp-1.0-4
> * librygel-core-2.6-2 is a dep of rygel, and depends as well on 
> libgssdp-1.0-3 and libgupnp-1.0-4

Right, those 2 MIRs are pre-requirements now


> * some copyright are missing:
>  - 2008-2009 Florian Brosch
>  - 2012 Choe Hwanjin <choe.hwan...@gmail.com>
>  - 2013 Cable Television Laboratories, Inc.
>  - 2014 Jens Georg <m...@jensge.org>
>  - 2014 Atlantic PuffinPack AB.
>  - 2017 Samuel CUELLA]
>  - Intel Corporation copyright should be extended to 2013
>  - Jens Georg copyright should be extended to 2016
> I may have missed others but that should be about it.

Thanks for listing those, I had a look and I think your list looks good,
I updated it in 0.36.2-2


> Opened question:
> - tests are ran during package build, do we want autopkgtests (unsure if 
> those are just unit tests or not, but it would maybe prevent at least vala 
> regression)?

The test just exercice the code indeed, no integration test, so not
really useful as autopkgtest by themself. You have a good point about
vala though, let's have a look at adding them then.


> - the doc is in the -dev package. That's ok with me, weird to have different 
> standards considering debian maintainer is the same than the other packages 
> though.

Right, a bit weird but probably not worth pushing for that change.


> I think there is a bunch of work to be done before going to another review or 
> give a conditional +1 on that one. I'll defer also to the security team once 
> the package is a little bit more ready from the pure MIR perspective.

Security team has been adding the review to their backlog but they would
prefer for the MIR team to state that it's likely to be ok from a MIR
perspective before starting, hopfully with the uploaded tweaks and the
replies we are good for bouncing to them while we sort out the
multiarch/pkgconfig & autopkgtest questions?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1786489

Title:
  [MIR] rygel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rygel/+bug/1786489/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to