Bug 1379508

Heh. If it was that easy.

Banshee moved to gtk3 with 2.9.1, but several of its dependent components did not. The C# support in GTK/GNOME is "crufty", and my best attempt to get Banshee 2.9.1 to compile results in a pile of :

error CS1703: An assembly `atk-sharp' with the same identity has already been imported. Consider removing one of the references
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll (Location of the symbol related to previous error)
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-3.0/atk-sharp.dll (Location of the symbol related to previous error)
error CS1703: An assembly `gdk-sharp' with the same identity has already been imported. Consider removing one of the references
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/gdk-sharp.dll (Location of the symbol related to previous error)
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-3.0/gdk-sharp.dll (Location of the symbol related to previous error)
error CS1703: An assembly `glib-sharp' with the same identity has already been imported. Consider removing one of the references
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/glib-sharp.dll (Location of the symbol related to previous error)
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-3.0/glib-sharp.dll (Location of the symbol related to previous error)
error CS1703: An assembly `gtk-sharp' with the same identity has already been imported. Consider removing one of the references
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll (Location of the symbol related to previous error)
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-3.0/gtk-sharp.dll (Location of the symbol related to previous error)
error CS1703: An assembly `pango-sharp' with the same identity has already been imported. Consider removing one of the references
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/pango-sharp.dll (Location of the symbol related to previous error)
/usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-3.0/pango-sharp.dll (Location of the symbol related to previous error)

Basically, patches accepted.

Can you please make a src.rpm available with your current status?
I had a quick look, but did not get that far as you described. And there is no point to repeat what you have already done...

(In reply to Timotheus Pokorra from comment #2)
> Can you please make a src.rpm available with your current status?
> I had a quick look, but did not get that far as you described. And there is
> no point to repeat what you have already done...

Sure.

https://spot.fedorapeople.org/banshee-2.9.1/

2.9.1 also sounds a lot like it's a development version; gnome stuff usually uses even/odd numbers to differentiate stable and development versions. May be worth checking what debian and other distros are doing and which version they are shipping.

(In reply to Kalev Lember from comment #4)
> 2.9.1 also sounds a lot like it's a development version; gnome stuff usually
> uses even/odd numbers to differentiate stable and development versions. May
> be worth checking what debian and other distros are doing and which version
> they are shipping.

This is why I'd originally held off on updating it, but since there hasn't been any other banshee release since 2014, this may be worth considering.

Debian is at 2.6.2.
Ubuntu is at 2.9.0+really2.6.2-2ubuntu2. $DEITY only knows what that means.

I have found the source of these problems:
> error CS1703: An assembly `atk-sharp' with the same identity has already
> been imported. Consider removing one of the references
> /usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll (Location of
> the symbol related to previous error)
> /usr/lib64/pkgconfig/../../lib/mono/gtk-sharp-3.0/atk-sharp.dll (Location of
> the symbol related to previous error)

libgpod brings in the reference to gtk-sharp-2.0.
To prove that, I modified the file /usr/lib64/pkgconfig/libgpod-sharp.pc and changed sharp-2.0 to sharp-3.0.
This would workaround that problem you described, and get further in the build process.

I tried to build libgpod properly against gtk3, but got to errors like this:
./Artwork.cs(75,10): error CS0104: `DateTime' is an ambiguous reference between `System.DateTime' and `GLib.DateTime'

I had to modify gudev-sharp-3.0.0-1.fc26.src.rpm as well, but that had no problems to switch to gtk3.
--- gudev-sharp.spec.orig	2016-09-29 16:48:26.000000000 +0200
+++ SPECS/gudev-sharp.spec	2016-09-30 21:43:25.000000000 +0200
@@ -13,9 +13,9 @@
 BuildRequires:  autoconf
 BuildRequires:  automake
 BuildRequires:  libgudev1-devel
-BuildRequires:  gtk2-devel
-BuildRequires:  gtk-sharp2-devel
-BuildRequires:  gtk-sharp2-gapi
+BuildRequires:  gtk3-devel
+BuildRequires:  gtk-sharp3-devel
+BuildRequires:  gtk-sharp3-gapi
 # Mono only available on these:
 ExclusiveArch: %mono_arches
 
You can find my srpms here:
https://tpokorra.fedorapeople.org/banshee/

and my copr for banshee: https://copr.fedorainfracloud.org/coprs/tpokorra/banshee

I was able to build libgpod against gtk: https://copr.fedorainfracloud.org/coprs/tpokorra/banshee/build/459974/

now I get errors like this when building banshee:
./Banshee.Hardware.Gio/LowLevel/Manager.cs(34,7): error CS0246: The type or namespace name `GUdev' could not be found. Are you missing an assembly reference?

I found a thread with the same issue: https://mail.gnome.org/archives/banshee-list/2015-March/msg00010.html
There is a suggestion with some patches later in that thread, in https://mail.gnome.org/archives/banshee-list/2015-March/msg00013.html

Looking at Ubuntu, how they package Banshee 2.9, they have lots of patches.
http://packages.ubuntu.com/xenial/banshee
http://archive.ubuntu.com/ubuntu/pool/universe/b/banshee/banshee_2.9.0+really2.6.2-7ubuntu2.debian.tar.xz see folder patches

I leave you with that for the moment, if you need further help please let me know.

Okay. I got farther. The Ubuntu patches were not helpful, because they appear to be patching random features into 2.6 backported from 2.9.1.

https://spot.fedorapeople.org/banshee-2.9.1/

The banshee package builds now, but does not run, it tracebacks almost immediately. There may be other changes in upstream git that are needed. I think the next step is to see if current git works, but I'm done for the day.

Well, another day down, more changes to report. I'm putting "fixed" srpms here:

https://spot.fedorapeople.org/banshee-2.9.1/

I switched to testing git master for banshee, and things seem... possibly better there? With the latest packages there, I can get banshee to open without crashing. Unfortunately, when I try to import files, it freezes. This is a known banshee bug that I do not know if there are any fixes for (https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/1533480). Disabling the "podcasts" plugin works around it, but on playback of the mp3s I imported into the library, I get a crash after a few seconds. Not sure if that is a Gstreamer1 issue or a banshee issue.

This whole stack is fragile and (honestly) mostly abandoned. I could not find anyone else attempting to support the current gtk-sharp3 code that banshee git needs. It is probable that bumping gtk-sharp3 to the package in my repo may cause other gtk-sharp3 dependent packages to need code changes in order to rebuild. 

The deeper I go down this particular rabbit hole, the less comfortable I am with upgrading banshee in Fedora. Timotheus, I'm leaving these pieces with you for now. If you make additional progress, let me know.

It seems upstream should do a proper 3.0 release of Banshee, and then we should look at upgrading it in Fedora.

I have to admit that I don't use Banshee myself, and don't have enough interest in it to join upstream to get it fixed.

Claudio? anyone else?

I wonder if I should downgrade gudev-sharp again so that Banshee 2.x builds again on Rawhide? I would use an epoch to do that? Any thoughts?

I upgraded gudev-sharp from version 0.1 to 3.0 because I thought that Banshee 2.9/3.0 was soon to be ready.
http://pkgs.fedoraproject.org/cgit/rpms/gudev-sharp.git/commit/?id=d99d3af46a35a1659d482723ea58728540b65ae7

I checked, no other package is using gudev-sharp or gudev-sharp-devel apart from Banshee.

So, this is never happening. I say never, because I suppose it is possible that the Banshee upstream could wake up and finish the 2.9 code branch into something that actually works, but that's probably never going to happen at this point.

I've done the best I can to fixup the 2.6 branch.