https://bugzilla.redhat.com/show_bug.cgi?id=1360389
Bug ID: 1360389
Summary: Upgrade to NUnit 3.x
Product: Fedora
Version: rawhide
Component: nunit
Assignee: timotheus.pokorra(a)solidcharity.com
Reporter: timotheus.pokorra(a)solidcharity.com
QA Contact: extras-qa(a)fedoraproject.org
CC: claudiorodrigo(a)pereyradiaz.com.ar,
mono(a)lists.fedoraproject.org,
timotheus.pokorra(a)solidcharity.com
Current version in Fedora Rawhide is NUnit 2.6.4
There is currently NUnit 3.4.1 available at
https://github.com/nunit/nunit/releases/tag/3.4.1
This is also required for MonoDevelop 6.0
Problem is that the NUnit gui has been split from NUnit 3.x, and the current
state is not stable yet. see https://github.com/nunit/nunit-gui
So we cannot just replace NUnit 2.x with NUnit 3.x plus a new nunit-gui package
yet.
The suggestion from Claudio was to add a package nunit2 for compatibility.
https://bugzilla.redhat.com/show_bug.cgi?id=1313236#c4
--
You are receiving this mail because:
You are on the CC list for the bug.
Hi,
we would need some help in the Mono SIG with the game OpenRA ¹, a clone
of the once famous C&C strategy games. There is already a bunch of
requests waiting for package review of the dependencies, please look
into the tracker bug ².
It would be nice if we can get further here with all the unbundling work.
Thanks in advance!
~R.
¹ http://www.openra.net
² https://bugzilla.redhat.com/1159091
Am 20.07.2016 um 01:33 schrieb Justin W. Flory:
> Hello all!
>
> I know this mailing list has been mostly inactive for quite some time
> and a lot of the initial inertia for the tasks that this SIG was
> responsible have fallen by the wayside over the years.
>
>
> == Bringing back the SIG ==
>
> Today, some extended discussion happened across #fedora-games /
> #fedora-join on IRC for how to bring back some life to this SIG. bkeys
> and I had discussed ideas about bringing information and tools in the
> open source gaming world into Fedora and communicate that with users.
>
>
> == Roll call ==
>
> To help get things rolling here once again, I'd like to propose a
> "sound-off" or roll call of everyone in this mailing list who is still
> interested in contributing or participating to efforts to help this
> SIG begin to move again. This will help us get an idea of who is
> around, what your skill sets are, and how you would be able to
> contribute.
>
>
> == Resources ==
>
> To help get any interested members onto the same page, there are some
> resources available to us now to help organize plans, thoughts, and
> communication. Obviously, this mailing list is a resource, but here
> are some more:
>
> * IRC: #fedora-games on irc.freenode.net
> * FAS: https://admin.fedoraproject.org/accounts/group/view/games-sig
> (apply after (re-)sending an introduction to the list)
> * Wiki page: https://fedoraproject.org/wiki/SIGs/Games
>
> It would be great to see some more people hang out in the IRC channel
> as well.
>
> Thanks everyone! Hoping to see where things go from here. :) My own
> introduction will be coming shortly...
>
>
>
> _______________________________________________
> games mailing list
> games(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/games@lists.fedoraproject.org
https://bugzilla.redhat.com/show_bug.cgi?id=1255741
Bug ID: 1255741
Summary: nunit fails to build on ppc64le
Product: Fedora
Version: 23
Component: nunit
Assignee: timotheus.pokorra(a)solidcharity.com
Reporter: rdossant(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: claudiorodrigo(a)pereyradiaz.com.ar,
mono(a)lists.fedoraproject.org,
timotheus.pokorra(a)solidcharity.com
Blocks: 1051573 (PPC64LETracker), 1185763
Description of problem: nunit fails to build with the following error message:
/usr/lib/mono/4.5/Microsoft.Common.targets: error : Tool exited with code: 1.
Output: Error: Exception has been thrown by the target of an invocation.
Inner exception: A null reference or invalid value was found [GDI+ status:
InvalidParameter]
Tool /usr/lib/mono/4.5/resgen.exe execution started with
arguments: /useSourcePath /compile
"TestTree.resx,obj/Debug/NUnit.UiKit.TestTree.resources"
Tool /usr/lib/mono/4.5/resgen.exe execution started with
arguments: /useSourcePath /compile
"TextOutputSettingsPage.resx,obj/Debug/NUnit.UiKit.TextOutputSettingsPage.resources"
Tool /usr/lib/mono/4.5/resgen.exe execution started with
arguments: /useSourcePath /compile
"TipWindow.resx,obj/Debug/CP.Windows.Forms.TipWindow.resources"
Tool /usr/lib/mono/4.5/resgen.exe execution started with
arguments: /useSourcePath /compile
"TreeBasedSettingsDialog.resx,obj/Debug/NUnit.UiKit.TreeBasedSettingsDialog.resources"
/usr/lib/mono/4.5/Microsoft.Common.targets: error : Tool exited with code: 1.
Output: Error: Exception has been thrown by the target of an invocation.
Inner exception: A null reference or invalid value was found [GDI+ status:
InvalidParameter]
Task "GenerateResource" execution -- FAILED
Done building target "GenerateResources" in project
"/builddir/build/BUILD/nunitv2-2.6.4/src/GuiComponents/UiKit/nunit.uikit.dll.csproj".--
FAILED
Done building project
"/builddir/build/BUILD/nunitv2-2.6.4/src/GuiComponents/UiKit/nunit.uikit.dll.csproj".--
FAILED
Task "MSBuild" execution -- FAILED
Done building target "ResolveProjectReferences" in project
"/builddir/build/BUILD/nunitv2-2.6.4/src/GuiRunner/nunit-gui/nunit-gui.csproj".--
FAILED
Done building project
"/builddir/build/BUILD/nunitv2-2.6.4/src/GuiRunner/nunit-gui/nunit-gui.csproj".--
FAILED
Build FAILED.
Errors:
/builddir/build/BUILD/nunitv2-2.6.4/src/GuiRunner/nunit-gui/nunit-gui.csproj
(default targets) ->
/usr/lib/mono/4.5/Microsoft.Common.targets (ResolveProjectReferences target) ->
/builddir/build/BUILD/nunitv2-2.6.4/src/GuiComponents/UiKit/nunit.uikit.dll.csproj
(default targets) ->
/usr/lib/mono/4.5/Microsoft.Common.targets (GenerateResources target) ->
/usr/lib/mono/4.5/Microsoft.Common.targets: error : Tool exited with code:
1. Output: Error: Exception has been thrown by the target of an invocation.
Inner exception: A null reference or invalid value was found [GDI+ status:
InvalidParameter]
/usr/lib/mono/4.5/Microsoft.Common.targets: error : Tool exited with code:
1. Output: Error: Exception has been thrown by the target of an invocation.
Inner exception: A null reference or invalid value was found [GDI+ status:
InvalidParameter]
0 Warning(s)
2 Error(s)
Time Elapsed 00:00:07.7548090
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.qjZa6L (%build)
Version-Release number of selected component (if applicable): 2.6.4-9
How reproducible: ppc-koji build nonunit on ppc64le
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1051573
[Bug 1051573] ppc64le tracker bug
https://bugzilla.redhat.com/show_bug.cgi?id=1185763
[Bug 1185763] smuxi fails to build on ppc64le
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NByEbd61Df&a=cc_unsubscribe
Hi,
Have you ever seen something like that? It's a bombshell you have to see! Look at it here <http://hitawysy.mauichiromax.com/aedsl>
My Best, paul(a)all-the-johnsons.co.uk
Hello Mono SIG,
I thought I write a short update, to keep everyone on the same page.
* Fedora 24 will have the latest Mono 4.2 packages, see
https://releases.xamarin.com/stable-release-cycle-6-service-release-4/
The package will be submitted to updates after the F24 Freeze.
* Fedora 24 MonoDevelop: There is still no tarball for the latest
MonoDevelop, version 5.10.3.51 from Cycle6SR3
https://releases.xamarin.com/stable-release-cycle-6-service-release-3/
Jo at Xamarin/Microsoft is having trouble with his Jenkins server
which should build the tarball. He is working on it.
* Fedora Rawhide: has the final Mono 4.4 package. see
https://releases.xamarin.com/stable-release-cycle-7/. I want to keep
Mono 4.4 there until F25 is branched off. Then we can "experiment"
again with Alpha releases in rawhide.
* MonoDevelop 6: I would be good if we could get that into Fedora 25.
There are still some issues, the main issue that there is no tarball
provided yet. I did experiment with a tarball of an alpha version. We
would need a couple of new packages. see for details
https://bugzilla.redhat.com/show_bug.cgi?id=1313236
Help is certainly appreciated, or if someone wants to take the lead in
that task, you are very welcome!
* Epel7: I am still thinking how to do this best. I see that Ubuntu
16.04 LTS comes with Mono 4.2: see
http://packages.ubuntu.com/search?keywords=mono-complete and
https://packages.debian.org/search?keywords=mono-complete
I wonder if we should get Mono 4.2 into Epel7, and hope we can use any
security fixes that Debian/Ubuntu has. Still the life cycle of Ubuntu
16.04 only goes up to April 2021, while CentOS7 is supported till June
2024, according to https://linuxlifecycle.com/
Or should we just retire Mono 4.2 in Epel7 at some point, when we
cannot provide security updates anymore, in April 2021? Or upgrade to
the version we are using in Epel8 by then.
* Epel5: I suggest we retire Mono 1.2 (!!!) from Epel5.
* Epel6: I guess we have both options: retiring Mono 2.10, or updating
to Mono 4.2 as well, depending how much work it is in Epel7.
Let me know what you think! Any help appreciated, as always!
My wife will give birth to our first child within the next week, so I
don't know how much time will be available for packaging...
All the best,
Timotheus
https://bugzilla.redhat.com/show_bug.cgi?id=1259328
Bug ID: 1259328
Summary: docky-2.2.1 is available
Product: Fedora
Version: rawhide
Component: docky
Keywords: FutureFeature, Triaged
Assignee: i(a)cicku.me
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: i(a)cicku.me, mono(a)lists.fedoraproject.org
Latest upstream release: 2.2.1
Current version/release in rawhide: 2.2.0-6.fc23
URL: https://launchpad.net/docky
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hYmOz9LwSq&a=cc_unsubscribe
Hello,
just to let you know:
We now have Mono 4.3.2 in Rawhide. It is called Cycle 7 Alpha. In the
#mono IRC I was told that it should have been named Mono 4.4, and the
next Alpha release will be from the Mono 4.4 branch.
Here are the first drafts of the release notes:
http://www.mono-project.com/docs/about-mono/releases/4.4.0/
One bigger change is this: "Our build system has been reconfigured to
become a 4.x setup, as opposed to 4.5 only and it’s now tracking .NET
4.6.1 APIs."
It seems the reference assemblies are taking a more prominent place.
We are not using them for Fedora. So we can only target the latest
4.6.1 APIs. I have added symlinks for 4.0 and 4.5 to point at the
latest API. That way we don't need to change the TargetFramework in
the csproj files of all the packages depending on Mono in Fedora.
See the changes here:
http://pkgs.fedoraproject.org/cgit/rpms/mono.git/tree/mono-4.0.0-ignore-ref…
I also had quite an issue with mscorlib and other dlls not included in
the rpm package.
I am glad that I was still able to run koji untag-pkg as suggested in
fedora-devel.
So in the future, we need to build Mono packages first in copr, and
then see if we can still compile other packages depending on Mono, and
Mono itself with that new version.
The reason for the problems in this release is that less assemblies
are in the GAC by default. Even not System.IO.dll. I don't fully
understand that, but I guess it works. We just need to make sure that
mono-find-provides still picks those dlls up even though they are not
in the GAC. I have fixed that here:
http://pkgs.fedoraproject.org/cgit/rpms/mono.git/tree/mono-4.3.2-find-provi…
The Xamarin rpms have manual mention of each Provide, which we don't
want in our spec file:
https://github.com/mono/linux-packaging-mono/blob/centos/mono-core.spec
We are not able to build MonoDevelop 6 Alpha, because there are no
tarballs released yet.
Please let me know if you find any issues with Mono in Rawhide.
Have a nice weekend,
Timotheus