Bug 429171

Summary: muine issues with mono(..) provides
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: muineAssignee: Sindre Pedersen Bjørdal <sindrepb>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: luis, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-28 11:26:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Bill Nottingham 2008-01-17 18:37:21 UTC
Description of problem:

A muine build provides:

mono(InotifyPlugin) =
mono(NDesk.DBus) =
mono(NDesk.DBus.GLib) =
mono(TrayIcon) =

Those look like things that should be only provided by ndesk-dbus, etc.

Version-Release number of selected component (if applicable):


Comment 1 Sindre Pedersen Bjørdal 2008-01-18 12:30:31 UTC
Using system ndesk-dbus and ndesk-dbus-glib packages instead of the bundled
removed the NDesk.Dbus provides. Which leaves me with:

mono(TrayIcon) =
mono(InotifyPlugin) =

Any tips on how to get rid of these?

Comment 2 Bill Nottingham 2008-01-18 16:18:03 UTC
Doesn't appear to be provided by anything else, so maybe they're not generic
bindings. If they aren't generic, they should probably be renamed so they're
something like mono(muine-TrayIcon). That's an issue for upstream, though.

Comment 3 Sindre Pedersen Bjørdal 2008-01-18 19:03:44 UTC
They aren't generic, but after talking to upstream I couldn't quite convince
them that the current names even existed, much less that they needed to be
changed. Seems this way of naming stuff is common, other mono apps have similar
issues, see banshee. 

How do I proceed from here?

Comment 4 Bill Nottingham 2008-01-18 19:18:48 UTC
If the mono APIs that it's exporting aren't actually for public
consumption/other apps to use, adding:

%define __mono_provides %{nil}

to the spec should remove them. Although, if that's the case, the mono-provides
script should probably be fixed (that would be an RPM bug.)

If they are for public consumption, then don't do anything.

Comment 5 Sindre Pedersen Bjørdal 2008-01-22 21:51:58 UTC
They aren't for public consumption, so I've removed them. As for fixing the
mono-provides script, I have no idea how, but agree something should be done.

Muine updates in devel and in F8 and F7 testing as soon as I get around to it.

Comment 6 Bill Nottingham 2008-01-23 15:30:29 UTC
Whoops, looking at the rawhide report, it appears that the provide for
mono(muine-plugin) needs kept, otherwise it can't install.

Comment 7 Sindre Pedersen Bjørdal 2008-01-24 12:20:49 UTC
How can I keep the muine-plugin provides while removing the unwanted ones?

Comment 8 Bill Nottingham 2008-01-24 16:14:17 UTC
Good question. Probably by overriding the mono provides and requires, and
filtering them via grep or something similar. (This is getting pretty ugly
pretty quick.) Maybe not filtering is best in the short run, and just making
sure that it uses things like the system ndesk-dbus where appropriate.

Comment 9 Luis Villa 2008-01-26 16:40:06 UTC
BTW, since this now blocks installation of the muine in updates-testing, this
should probably be prioritized as something other than low-low. (And maybe
retitled to make it easier to find.)

Comment 10 Luis Villa 2008-02-21 23:49:32 UTC
Also broken in F9a1, FWIW.

Comment 11 Sindre Pedersen Bjørdal 2008-02-22 09:16:24 UTC
How can I solve this issues?

Comment 12 Sindre Pedersen Bjørdal 2008-02-28 11:26:54 UTC
Issue finally resolved. Turned out commenting didn't do the trick, actually
removing the troubled mono provides line fixed it.