[MIR] grilo-plugins

Bug #1394731 reported by Jackson Doak
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grilo-plugins (Ubuntu)
Undecided
Didier Roche

Bug Description

Availability: In universe, builds on all archs

Rational: grilo-plugins is now a dependency of totem and is hard to patch out. See lp:1393067

Security: No known CVEs

Quality Assurance: No bugs in debian or ubuntu, most upstream bugs are feature requests. Active debian maintainer. Has watch file. Tests are run during build.

UI standards: The package is translated upstream.

Dependencies: All deps in main

Standards compliance: No issues

Maintenance: Actively maintained in debian. ubuntu-gnome team will subscribe in ubuntu.

Background info: Grilo is a framework focused on making media discovery and browsing easy for application developers. This package contains it's plugins, including the tracker one, which is now needed by totem

Related branches

Revision history for this message
Michael Terry (mterry) wrote :

See bug 1116098, where adding grilo-plugins to main has been discussed before. I'd really like to see a split into the plugins we care about in main and the ones we don't. This package currently is a mass of functionality and dependencies (although from universe, it actually only would need dleyna-server, though that has its own set of universe deps).

The Debian maintainer himself commented in the above bug that he'd like to do some sort of split in Debian.

Maybe at least split out the tracker plugin? That would solve the dep problem (dleyna-server is run time dep only) and let us avoid promoting the whole bundle of other plugins to main. Ideally in agreement with the Debian maintainer on package names so that if we do this ahead of Debian, we won't have conflicting names down the road.

Changed in grilo-plugins (Ubuntu):
status: New → Incomplete
Revision history for this message
Tim Lunn (darkxst) wrote :

Michael,
   Given tracker is in main these days, those specific comments seem obsolete now.

As far as a package split and totem goes, the following plugins would probably need to be in main
bookmarks
filesystem
local-metadata
metadata-store
optical-media

all other plugins are more or less optional but some that may be useful include
youtube
vimeo

most of the remote content on the "channels" tab is provided by
apple-trailers
blip.tv
lua-factory
rai.tv

Revision history for this message
Michael Terry (mterry) wrote :

OK, assigning to Didier for a fresh look.

Changed in grilo-plugins (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
status: Incomplete → New
Revision history for this message
Jackson Doak (noskcaj) wrote :

I've subscribe the debian maintainer in the hope he can split the package

Revision history for this message
Didier Roche (didrocks) wrote :

Also, can you ask to drop Recommends: dleyna-server to a suggests? Keep me posted on the outcome of the split that was discussed (I agree with Tim on the plugin split), then please, reassign the bug to me :)

Changed in grilo-plugins (Ubuntu):
status: New → Incomplete
assignee: Didier Roche (didrocks) → nobody
Revision history for this message
Didier Roche (didrocks) wrote :

finished to check up the packaging and code source, so apart from the comments above, that will be a +1 for me.

Revision history for this message
Alberto Garcia (berto) wrote :

Hello, and thanks for keeping me in the loop!

I think it's a good idea to split the packages. I still haven't had the chance to think about the optimal way to do so, though.

I guess we can follow an approach similar to that of gstreamer and have something like grilo-plugins-0.2-{base,standard,extra} (we would have to come up with some suitable names).

So plugins that don't pull any additional dependency (or very basic ones) would go directly to base, like these ones:

  appletrailers
  bliptv
  filesystem
  gravatar
  jamendo
  lastfm-albumart
  optical-media
  raitv
  shoutcast
  vimeo

What are the dependencies that concern you the most? Tracker?

About downgrading dleyna-server to Suggests, I don't have a strong opinion.

Revision history for this message
Tim Lunn (darkxst) wrote :

Alberto,
   Tracker is not a problem anymore, the only dependency that is not in main be would dleyna-server.

 Packages in main have much higher requirements, than universe, so I think the concern is really pulling in a mass of random plugins just to get the few plugins required. So from that perspective, it would be good to have -base containing all the plugins really required by GNOME and perhaps a few of the more common/useful services such as youtube (i.e atleast the first 2 sections listed in comment #2). The rest of the the plugins for more obscure services could then go in -extra which would live in universe.

Or another logical way to split might be to have local plugins and web plugins, local would go into main, and at least satisfy the required by GNOME to function.

Revision history for this message
Jackson Doak (noskcaj) wrote :

Are you planning to do the split soon alberto (in debian or ubuntu) or should we be taking it?

Revision history for this message
Tim Lunn (darkxst) wrote :

From discussions on IRC -base will have:
bookmarks
filesystem
local-metadata
metadata-store
 appletrailers
  bliptv
  filesystem
  gravatar
  jamendo
  lastfm-albumart
  optical-media
  raitv
  shoutcast
  tracker
  youtube
   vimeo

Revision history for this message
Tim Lunn (darkxst) wrote :

grilo-plugins split has been uploaded now

Changed in grilo-plugins (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
Revision history for this message
Didier Roche (didrocks) wrote :

ack with 0.2.13-3ubuntu3, please upload something depending on it and I'll promote the needed parts.

Changed in grilo-plugins (Ubuntu):
status: Incomplete → Fix Committed
Revision history for this message
Steve Langasek (vorlon) wrote :

This MIR bug report says that the ubuntu-gnome team will be subscribed to the bugs. But Ubuntu GNOME is not a Canonical-supported flavor, and the ubuntu-gnome team is not responsible to Canonical for maintenance of packages. I do not think that we can consider ubuntu-gnome an "owning team" for purposes of an MIR.

Perhaps the MIR team could clarify this on <https://wiki.ubuntu.com/UbuntuMainInclusionRequirements>?

Revision history for this message
Didier Roche (didrocks) wrote :

@Steve: this should be agreed and written that way then. AFAIK, for things where a canonical team wasn't interesting but an official flavor was depending on, we agreed that trusted flavor would be in charge (or report) critical bugs to us.

In that specific case, should we reject the MIR then? The canonical desktop team wouldn't look for bugs in grilo-plugins if I'm correct and I don't see other Canonical team being interested into it.

Revision history for this message
Tim Lunn (darkxst) wrote :

I don't think this can be rejected now, its a hard depends from totem which has been updated (and that is essentially owned by the -desktop team). Given that I suspect the -desktop team would take ownership of this MIR?

However this leads to a much bigger issue what happens when flavours need components in main? tracker is a prime example of a package that provides core functionality to the GNOME experience and that no Canonical team is going to look after. It needs to be in main so that nautilus can build against it, so that we get our file seach in the gnome-shell overview.

Admittedly most likely only affects Ubuntu GNOME due to the large overlap with Ubuntu packageset, but still doesn’t seem reasonable to just reject our MIR's based on the fact we are not Canonical. All the packages we have MIR'ed are very well maintained in debian and for the most part syncs, and we work upstream on these, if there is a CVE I can get the upstream maintainers to make a new release with the fix.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@Steve, where is the "Canonical supported" requirement coming from? It's not in the currently MIR documentations/rules and has not been enforced, so it looks like it's not a defined rule at the moment. That might be a discussion worth having though if you think thing should be that way...

Revision history for this message
Iain Lane (laney) wrote :

The tracker case is quite interesting. It's code which is only conditionally executed on GNOME shell sessions, but has to be in main because the library is linked to nautilus.

It's at least unusual that Canonical might have to support codepaths which can never be executed in our supported environments.

Revision history for this message
Didier Roche (didrocks) wrote :

On another note, it will be great that every archive admin members follow the same procedure when promoting a package to main. The bug is still opened and not fixed release, I was not even aware then that it's been promoted already. I don't think I handle that promotion on the 04 of march, which is quite recent (my logs and command doesn't show this). Sad that we don't have in the UI launchpad logs showing who originated the request.

What I personally do when promoting a package is that I tend to copy/paste the promote command output on the bug itself when changing the status. That's also a way to ensure the archive admin checked that a MIR was filled if needed. (I also always separate the "Fix committed/Fix released" in 2 separates steps when I'm handling both in one run). Can we move the archive admin process around this?

Revision history for this message
Steve Langasek (vorlon) wrote :

I am not asking for this MIR to be rejected, nor am I asking that the desktop team monitor the bug mail. What I am looking for is clarity about who is ultimately responsible for addressing any problems with this package with respect to the main inclusion requirements - including any MIRs that might be required for further future dependencies. This was the intent from my side when we had the discussion that led to listing this as a requirement on the wiki page; I'm sorry if that intent didn't come through clearly.

Logically, I don't think it makes sense for the development team for a universe flavor to be ultimately responsible for a package with respect to main. Would you agree?

FWIW the context for why I care about this is basically <http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html>. It's important to have an escalation path for bugs on packages in main, and I believe it's a bug to have "unowned" packages in main. (I think it's also a bug that lubuntu and xubuntu are considered "owners" on that page, since like ubuntu-gnome they are universe flavors; but note that they each only have one package subscription listed, for a package that is co-owned by the desktop team.)

Anyway, this isn't a problem that's specific to this MIR bug, so I'm happy to take the general discussion to email with the MIR team. Would the desktop team be happy marking ~desktop-packages as a subscriber for grilo and grilo-plugins?

> On another note, it will be great that every archive admin members
> follow the same procedure when promoting a package to main. The
> bug is still opened and not fixed release, I was not even aware then
> that it's been promoted already. I don't think I handle that promotion
> on the 04 of march, which is quite recent (my logs and command
> doesn't show this). Sad that we don't have in the UI launchpad logs
> showing who originated the request.

Yes, agreed on all points. It's clearly incorrect to promote a package to main without updating the bug, and it's very unfortunate that we don't have audit logs to show who promoted the package. I will address this with the archive admin team.

Revision history for this message
Matthias Klose (doko) wrote :

demoted grilo-plugins-0.2-extra, however grilo-plugins-0.2-dbg still depends on extra. I'm demoting that too.

Revision history for this message
Michael Terry (mterry) wrote :

Steve, I'll continue to comment on this bug, since grilo is the proximate cause of this discussion.

So you are correct that main implies Canonical support. In the case of a flavor-only package, Canonical presumably doesn't want to depend on a community flavor team, nor does that community flavor team presumably want to be depended on by Canonical in that way.

I think the confusion is partly historical. Back in the day, flavors were much more "in the fold" and Canonical *was* willing to offer support for them (like Kubuntu/GNOME). So having a flavor team look after packages in main wasn't odd.

After Canonical dropped support for Kubuntu/GNOME, they were demoted from main. But there are still shared packages that cause problems like this grilo bug. Where for purely technical/packaging reasons, Canonical gets asked to support a feature they don't use and may end up blocking that feature from being offered in a community flavor. Which neither side is thrilled with.

Is there no way to mark a package in main as 'not supported?' I remember that we have some way to mark a universe package as supported. Can we do the inverse? That would let us promote grilo without putting Canonical on the hook.

In any case, historically the MIR team did not *require* a team looking after the package. Only recently have we started blocking promotion based on that. And even then, we haven't required that the team be from Canonical. Should we loop someone from Canonical's support team in? See how they handle flavor packages like this?

Revision history for this message
Didier Roche (didrocks) wrote :

Just a note: grilo itself isn't an issue as per see, but we have multiple examples of those instances I guess throughout the archive (even kubuntu things).

As Steve told, let's focus on the main issue (actually I see many):
1. what to do in similar case where we have a build-dep/dep for build-time requirements where only community flavors are interested in?
2. how to ensure that the strict binary separation are not overlooked in the future? For instance, we have from the tracker source the libs in main, but not the tracker/miner services.
-> The canonical desktop team are ok to "support" the libs, but not the services.
-> What if one day, something starts to recommends/deps on the service. Then, an archive admin runs check-mir on the package and see " * tracker is in universe, but its source tracker is already in main; file an ubuntu-archive bug for promoting the current preferred alternative". The AA will then just promote it, without having the background info that the canonical desktop team didn't want to support the service, and we end up in the same situation.
3. what procedure to require the AA to follow in case of promotion/demotion so that we can get the historical context easily on launchpad?

Revision history for this message
Michael Terry (mterry) wrote :

I thought for #2/#3, the AA is supposed to look up the old MIR bug and read the relevant history. At least, that's the only procedure we can follow with current tools, to my knowledge.

Revision history for this message
Matthias Klose (doko) wrote :

had to add the -dbg package to the extra-excludes in the seeds, depends on the extra package

Changed in grilo-plugins (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1394731] Re: [MIR] grilo-plugins

On Mon, Mar 16, 2015 at 01:59:16PM -0000, Michael Terry wrote:
> Is there no way to mark a package in main as 'not supported?' I
> remember that we have some way to mark a universe package as supported.
> Can we do the inverse?

This, in effect, is what the archive reorg spec was about. Unfortunately,
to date it has not been implemented. So no, there's no way to do this
currently.

> In any case, historically the MIR team did not *require* a team looking
> after the package. Only recently have we started blocking promotion
> based on that. And even then, we haven't required that the team be from
> Canonical. Should we loop someone from Canonical's support team in?
> See how they handle flavor packages like this?

As far as I'm aware this isn't really a commercial support question. From
my POV this is about development support.

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

Other bug subscribers