Hi,
Sorry for the lengthy mail, but I have observed something strange in our mono packages: some of the tarballs we use in Fedora for packaging differ from upstream:
During the last days I've searched a bug in f-spot where it sometimes crashed with really weird backtraces like this (Fedora 10, mono 2.2):
ERROR:mini-exceptions.c:768:get_exception_catch_class: assertion failed: (class->generic_class->container_class == method_container_class) Stacktrace:
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0x00004> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0xffffffff>2
I've found some upstream bug reports about the problem: https://bugzilla.novell.com/show_bug.cgi?id=459285 and they claimed that it got fixed in mono 2.2.
Currently, F10 uses mono-core-2.2-2.fc10.i386 I've checked out the corresponding tag (mono-2_2-2_fc10) and did a "make local" which retrieved the tarball as it is in Fedora's packaging system:
md5sum mono-2.2.tar.bz2 a311545a0003f1a599297d57e4e27916 mono-2.2.tar.bz2
cat sources a311545a0003f1a599297d57e4e27916 mono-2.2.tar.bz2
Then I've downloaded the official 2.2 tarball as it is linked on mono's web page: http://ftp.novell.com/pub/mono/sources/mono/mono-2.2.tar.bz2
md5sum mono-2.2.tar.bz2 da147e24d14a73d8ad52775dd4a3d165 mono-2.2.tar.bz2
The (unified) diff between both mono versions is around 500kByte and the upstream version also contains the claimed bug fix.
I have seen the same problem with mono-tools: dc96a311a8fed1a3807fed92a99b6cf8 mono-tools-2.4.2.tar.bz2-upstream 49252ede8bec6e0b244f2a34712a067e mono-tools-2.4.2.tar.bz2-fedora
If I read the changelogs correctly (here mono-tools latest version update: "- Bump to 2.4.2 preview 1") then we've packaged previews of official mono releases which unfortunately use the same name of the tarball as the official release. I suggest if we package previews, then we have to use the correct version/release scheme for pre-release packages: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_package...
For mono-2.2 the spec file doesn't mention that a pre-release was packaged.
I'm convinced that not marking the pre-releases as such is highly risky: It is not obvious when you just look at the NVR itself and so the chance is quite high that we stick to the pre-releases even in the stable Fedora releases and miss so important bug fixes from upstream.
If it is OK with you, I'd like to do the following:
1. I'll just fix mono-tools (devel).
2. Regarding mono in F10: F10 is already in deep maintenance mode and so I believe we should _not_ update mono in F10 to 2.4 although the spec files are already updated. But if there is not strong reason to do it, we should do only critical bug fixes now to mono 2.2.
But I would also suggest to update F10's mono package to the official 2.2 release since it would solve problems as I was looking for at the beginning and most likely it will contain also some more bug fixes from upstream.
Since I'd like to get this bug fixed in F10 as fast as possible, I'd like to volunteer to do it (if somebody could approve my commit permissions ;-) ).
3. If I see it in other packages where I can commit and if there is already an official release, I'll just update them too. If I'm not sure, I'd ask for clarification on the list.
Does this sound acceptable to all you?
Best regards, Christian
2009/10/4 Christian Krause chkr@fedoraproject.org
Hi,
Sorry for the lengthy mail, but I have observed something strange in our mono packages: some of the tarballs we use in Fedora for packaging differ from upstream:
During the last days I've searched a bug in f-spot where it sometimes crashed with really weird backtraces like this (Fedora 10, mono 2.2):
ERROR:mini-exceptions.c:768:get_exception_catch_class: assertion failed: (class->generic_class->container_class == method_container_class) Stacktrace:
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0x00004> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0xffffffff>2
I've found some upstream bug reports about the problem: https://bugzilla.novell.com/show_bug.cgi?id=459285 and they claimed that it got fixed in mono 2.2.
Currently, F10 uses mono-core-2.2-2.fc10.i386 I've checked out the corresponding tag (mono-2_2-2_fc10) and did a "make local" which retrieved the tarball as it is in Fedora's packaging system:
md5sum mono-2.2.tar.bz2 a311545a0003f1a599297d57e4e27916 mono-2.2.tar.bz2
cat sources a311545a0003f1a599297d57e4e27916 mono-2.2.tar.bz2
Then I've downloaded the official 2.2 tarball as it is linked on mono's web page: http://ftp.novell.com/pub/mono/sources/mono/mono-2.2.tar.bz2
md5sum mono-2.2.tar.bz2 da147e24d14a73d8ad52775dd4a3d165 mono-2.2.tar.bz2
The (unified) diff between both mono versions is around 500kByte and the upstream version also contains the claimed bug fix.
I have seen the same problem with mono-tools: dc96a311a8fed1a3807fed92a99b6cf8 mono-tools-2.4.2.tar.bz2-upstream 49252ede8bec6e0b244f2a34712a067e mono-tools-2.4.2.tar.bz2-fedora
If I read the changelogs correctly (here mono-tools latest version update: "- Bump to 2.4.2 preview 1") then we've packaged previews of official mono releases which unfortunately use the same name of the tarball as the official release. I suggest if we package previews, then we have to use the correct version/release scheme for pre-release packages:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_package...
For mono-2.2 the spec file doesn't mention that a pre-release was packaged.
I'm convinced that not marking the pre-releases as such is highly risky: It is not obvious when you just look at the NVR itself and so the chance is quite high that we stick to the pre-releases even in the stable Fedora releases and miss so important bug fixes from upstream.
If it is OK with you, I'd like to do the following:
- I'll just fix mono-tools (devel).
This is given, the package is in conflict with the required parts of the packaging guidelines, a serious issue which must be fixed.
- Regarding mono in F10: F10 is already in deep maintenance mode and so
I believe we should _not_ update mono in F10 to 2.4 although the spec files are already updated. But if there is not strong reason to do it, we should do only critical bug fixes now to mono 2.2.
2.4 is long term support from upstream, there are benefits from going there just in terms of it being a product Novell is commited to support for a number of years. I would support such a push especially as it would make for a good base for F11 as well. F12 and beyond can target current Mono releases till the next LTS Mono release.
But I would also suggest to update F10's mono package to the official 2.2 release since it would solve problems as I was looking for at the beginning and most likely it will contain also some more bug fixes from upstream.
Since I'd like to get this bug fixed in F10 as fast as possible, I'd like to volunteer to do it (if somebody could approve my commit permissions ;-) ).
- If I see it in other packages where I can commit and if there is
already an official release, I'll just update them too. If I'm not sure, I'd ask for clarification on the list.
Does this sound acceptable to all you?
Best regards, Christia
Thank you for catching this and for your offer of fixing the issue.
I personally have no objection to any plan to address this but I think you should talk to Michel as he is planning a big Mono push I believe.
Hi,
David Nielsen wrote:
1. I'll just fix mono-tools (devel).This is given, the package is in conflict with the required parts of the packaging guidelines, a serious issue which must be fixed.
Ok, I will adjust the Source0: URL to actually point to the correct tarball (in this case preview of mono 2.6) and add a proper release tag so that it is obvious that a preview version is packaged. For the mono I'll create a bug report.
Unfortunately it doesn't look like that the mono projects uses any kind of versioning for the pre-releases - the URL for mono-tools-2.6 preview release looks like this:
http://mono.ximian.com/monobuild/preview/sources/mono-tools/mono-tools-2.6.t...
So I suggest we put the date where we've downloaded the preview into the release tag.
2. Regarding mono in F10: F10 is already in deep maintenance mode and so I believe we should _not_ update mono in F10 to 2.4 although the spec files are already updated. But if there is not strong reason to do it, we should do only critical bug fixes now to mono 2.2.2.4 is long term support from upstream, there are benefits from going there just in terms of it being a product Novell is commited to support for a number of years. I would support such a push especially as it would make for a good base for F11 as well. F12 and beyond can target current Mono releases till the next LTS Mono release.
Hm, probably there was a misunderstanding here. I spoke only about F10. I fully agree that F11 should use the most recent mono 2.4 and F12 may use later 2.6. But for F10 which lifetime will be over in 4 months I would really not increase the mono version right now.
I do only ask for an update in F10 to the official most recent version of mono 2.2, so that we got the latest bug fixes for this mono release (and we'll make some f-spot users happy).
But I would also suggest to update F10's mono package to the official 2.2 release since it would solve problems as I was looking for at the beginning and most likely it will contain also some more bug fixes from upstream. Since I'd like to get this bug fixed in F10 as fast as possible, I'd like to volunteer to do it (if somebody could approve my commit permissions ;-) ).
Michel, Paul:
Does the following list is also your view of Fedora's mono support:
F12: mono 2.4, and later mono 2.6 when it's ready F11: mono 2.4 F10: mono 2.2
Would it be also OK with you if I would update F10's mono to the official 2.2 version? In this case I would have to revert the 2.4 update in CVS in the F-10 branch, but this should not be a problem.
Thanks!
Best regards, Christian
Hi,
Christian Krause wrote:
I do only ask for an update in F10 to the official most recent version of mono 2.2, so that we got the latest bug fixes for this mono release (and we'll make some f-spot users happy).
But I would also suggest to update F10's mono package to the official 2.2 release since it would solve problems as I was looking for at the beginning and most likely it will contain also some more bug fixes from upstream. Since I'd like to get this bug fixed in F10 as fast as possible, I'd like to volunteer to do it (if somebody could approve my commit permissions ;-) ).Michel, Paul:
Does the following list is also your view of Fedora's mono support:
F12: mono 2.4, and later mono 2.6 when it's ready F11: mono 2.4 F10: mono 2.2
Would it be also OK with you if I would update F10's mono to the official 2.2 version? In this case I would have to revert the 2.4 update in CVS in the F-10 branch, but this should not be a problem.
Just a small heads-up:
Since no objection was raised, I'm going to do the mentioned update in F10 from mono 2.2 pre-release to the official release of mono 2.2.
I've created the following bug report to track the issue: https://bugzilla.redhat.com/show_bug.cgi?id=530170
Best regards, Christian
mono@lists.stg.fedoraproject.org
-
Christian Krause -
David Nielsen