Bug 523938 - crash on startup caused by missing Requires: mono-nunit
Summary: crash on startup caused by missing Requires: mono-nunit
Status: CLOSED DUPLICATE of bug 523780
Alias: None
Product: Fedora
Classification: Fedora
Component: banshee
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michel Alexandre Salim
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-09-17 09:52 UTC by David Nielsen
Modified: 2009-09-20 01:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-09-20 01:25:56 UTC

Attachments (Terms of Use)

Description David Nielsen 2009-09-17 09:52:09 UTC
Description of problem:

[david@dawkins Hentet]$ banshee-1 --debug
** Running Mono with --debug   **
[Info  11:46:24.507] Running Banshee 1.5.1: [Fedora12-1.5.1-0.2.git20090831.fc12 (linux-gnu, x86_64) @ 2009-08-31 18:37:50 EDT]
pp SCAN: SetupDomain
[Debug 11:46:26.449] Bus.Session.RequestName ('org.bansheeproject.Banshee') replied with PrimaryOwner
[Debug 11:46:26.457] Core service started (DBusServiceManager, 0,001646s)
[Debug 11:46:26.459] Registering remote object /org/bansheeproject/Banshee/DBusCommandService (Banshee.ServiceStack.DBusCommandService) on org.bansheeproject.Banshee
[Debug 11:46:26.470] Core service started (DBusCommandService, 0,012819s)

** (Banshee:28803): WARNING **: The following assembly referenced from /usr/lib64/banshee-1/Hyena.dll could not be loaded:
     Assembly:   nunit.framework    (assemblyref_index=2)
     Public Key: 96d09a1eb7f44a77
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib64/banshee-1/).

** (Banshee:28803): WARNING **: Could not load file or assembly 'nunit.framework, Version=, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies.

** (Banshee:28803): WARNING **: Missing method .ctor in assembly /usr/lib64/banshee-1/Hyena.dll, type NUnit.Framework.TestFixtureAttribute

** (Banshee:28803): WARNING **: Can't find custom attr constructor image: /usr/lib64/banshee-1/Hyena.dll mtoken: 0x0a0004c9

Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Data.Sqlite.SqliteFunction ---> System.IO.FileNotFoundException: Could not load file or assembly 'nunit.framework, Version=, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies.
File name: 'nunit.framework, Version=, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77'
  at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool)
  at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x00000] in /builddir/build/BUILD/mono- 
  at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x00035] in /builddir/build/BUILD/mono- 
  at System.MonoType.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x00011] in /builddir/build/BUILD/mono- 
  at Mono.Data.Sqlite.SqliteFunction..cctor () [0x000c2] in /builddir/build/BUILD/banshee-20090831/src/Libraries/Mono.Data.Sqlite/Mono.Data.Sqlite/SQLiteFunction.cs:483 
  --- End of inner exception stack trace ---
  at Mono.Data.Sqlite.Sqlite3.Open (System.String strFilename) [0x0003d] in /builddir/build/BUILD/banshee-20090831/src/Libraries/Mono.Data.Sqlite/Mono.Data.Sqlite/SQLite3.cs:110 
  at Mono.Data.Sqlite.SqliteConnection.Open () [0x00162] in /builddir/build/BUILD/banshee-20090831/src/Libraries/Mono.Data.Sqlite/Mono.Data.Sqlite/SQLiteConnection.cs:833 
  at (wrapper remoting-invoke-with-check) Mono.Data.Sqlite.SqliteConnection:Open ()
  at Hyena.Data.Sqlite.HyenaSqliteConnection.ProcessQueue () [0x00026] in /builddir/build/BUILD/banshee-20090831/src/Libraries/Hyena/Hyena.Data.Sqlite/HyenaSqliteConnection.cs:416 

installing mono-nunit works around the issue, but the greater issue still seems to me to be rooted in building the unit tests for a production release at all.

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Michel Alexandre Salim 2009-09-18 19:20:24 UTC
In most other packages, running unit tests during the build do not cause the unit test framework to be referenced in the produced assemblies.. this is odd indeed.

The updated build I pushed when Boo was last updated (0.3) fixes this, though -- the dependency on mono-nunit is now automatically picked up. So this is not a severe issue anymore, more of a question of what's the right thing to do.

I'd say, given that this is pre-release software on a development distribution, we keep running unit tests, and disable them when 1.6 final comes out. Thoughts?

Comment 2 David Nielsen 2009-09-18 22:00:39 UTC
If we turn the unit tests off prior to the beta or some point from which updates to final is supportable (or at least something we can expect a considerable amount of users to do) then I am fine with it.

I worry about changing the dependency chain to late in the game and about letting upgraders have a dangling mono-nunit. Aside that I don't think in the years I have been involved with Banshee I have seen unit testing catch something for downstreamers like ourselves so I doubt the real value. 

Another concern if Banshee is ever to be considered for the LiveCD we need to operate with a fairly small dependency chain.

Regardless you are the maintainer, it is your call. 

Aside that thank you for fixing the problem, Banshee now runs like the beauty it is once more out of the box.

Comment 3 Michel Alexandre Salim 2009-09-20 01:25:56 UTC
Merging this with Paul Lange's report as he also mentions monodoc.

*** This bug has been marked as a duplicate of bug 523780 ***

Note You need to log in before you can comment on or make changes to this bug.