inconsistency between sources at Fedora and upstream

[David Nielsen]

2009/10/4 Christian Krause <chkr at 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_packages
>
> 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).
>

This is given, the package is in conflict with the required parts of the
packaging guidelines, a serious issue which must be fixed.


>
> 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.


> 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,
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/mono/attachments/20091006/31e53236/attachment.html