On Mon, Mar 16, 2015 at 01:59:16PM -, 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. Unfortuna
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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bu
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
h
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-tim
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
demoted grilo-plugins-0.2-extra, however grilo-plugins-0.2-dbg still
depends on extra. I'm demoting that too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1394731
Title:
[MIR] grilo-plugins
To man
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 migh
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
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 environm
@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...
--
You
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 comp
@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
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 pu
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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
grilo-plugins split has been uploaded now
** Changed in: grilo-plugins (Ubuntu)
Assignee: (unassigned) => Didier Roche (didrocks)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1394731
Title:
[
** Branch linked: lp:~noskcaj/ubuntu/vivid/grilo-plugins/split
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1394731
Title:
[MIR] grilo-plugins
To manage notifications about this bug go to:
https:/
>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
--
You received this bug notification because you are a member
Are you planning to do the split soon alberto (in debian or ubuntu) or
should we be taking it?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1394731
Title:
[MIR] grilo-plugins
To manage notificatio
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 pe
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,ext
finished to check up the packaging and code source, so apart from the
comments above, that will be a +1 for me.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1394731
Title:
[MIR] grilo-plugins
To m
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
** Changed in: gri
I've subscribe the debian maintainer in the hope he can split the
package
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1394731
Title:
[MIR] grilo-plugins
To manage notifications about this bug go
OK, assigning to Didier for a fresh look.
** Changed in: grilo-plugins (Ubuntu)
Status: Incomplete => New
** Changed in: grilo-plugins (Ubuntu)
Assignee: (unassigned) => Didier Roche (didrocks)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
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 optio
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 dleyn
26 matches
Mail list logo
