Uh oh!
There was an error while loading. Please reload this page.
[mono] PR tracking the 2017-04 bump. - #551
Conversation
dnfclas
commented
Apr 6, 2017
@kumpera, |
jonpryor
commented
Apr 6, 2017
That's probably because 3e5c484 is kumpera/Java.Interop/3e5c484f, not xamarin/Java.Interop/3e5c484f. If you create a branch from xamarin/Java.Interop and not kumpera/Java.Interop, this will presumably work. Or, if you "fix" the ...or we accept dotnet/java-interop#141 and then you can bump "normally." That Cecil bump looks "big." |
kumpera
commented
Apr 6, 2017
build |
The old project for System.Drawing.Primitives was removed in favor of building the assembly with the existing logic in Mono.
# Conflicts: # build-tools/dependencies/dependencies.projitems # external/mono # src/System.Drawing.Primitives/System.Drawing.Primitives.targets # src/netstandard/netstandard.targets
radical
commented
Apr 27, 2017
Can we rebuild this? The CI build is failing with |
radical
commented
Apr 27, 2017
build |
Could somebody look at this? |
jonpryor
commented
Apr 27, 2017
@directhex: wrt @radical's question, is there some preferred mechanism to convince "the" Linux builder to install Mono 5.2 instead of (presumably) the current 4.9? I think we're going to need some mechanism of specifying which mono version to install, and I'm not sure what that should be. Could we e.g. add a Linux lane specific to this PR so that it installs the correct Mono version until merged on master? Something else? |
directhex
commented
Apr 28, 2017
@jonpryor the preferred mechanism crumbles a bit when the request is for a version which isn't in alpha yet. I already added a mechanism to make it possible to add one-off builds as repositories, what I don't have is any package-related one-off builds of the 5.2 branch. I'll see what I can do. |
kumpera
commented
Apr 28, 2017
We ignore linux CI results when testing newer mono. Looks like everything is good now! |
radical
commented
Apr 28, 2017
I was looking at this because of https://bugzilla.xamarin.com/show_bug.cgi?id=55287 . Can the bug be closed now? |
directhex
commented
May 2, 2017
Is Mono master (5.3.x) usable, or does it need to be 5.2? |
kumpera
commented
May 2, 2017
@directhex I think 5.4 would do it, but it's not strictly needed. I think this PR is ready for merging as is once the linker conflict is resolved. |
kumpera
commented
May 2, 2017
@directhex ugg, forget that, we'll need those packages to move this forward. |
jonpryor
commented
May 2, 2017
The current plans to address the linker conflict are for @radekdoulik to remove |
directhex
commented
May 3, 2017
A |
jonpryor
commented
May 4, 2017
@directhex: Do what you did with PR #445: when the Jenkins+Linux instance is started, have it install the This should be done for the |
directhex
commented
May 4, 2017
build |
directhex
commented
May 4, 2017
OK, it's not finished building, but it's actually starting now, so my work here is done. |
- instead use mono's one in mono/external/linker
radekdoulik
commented
May 4, 2017
@marek-safar we are missing this commit here for XA: dotnet/linker@6e4e50c would you mind if I create a new branch on linker named mono-2017-04, cheery-pick the commit and let mono/2017-04 use the linker branch? |
It's another moved assembly.
- the emulators are now timeouting on wrench and it looks like this might fix it. I have tested it on my rodos-playground branch and wrench run the emulators fine there. fingers crossed :-) (cherry-picked from xamarin/monodroid@62278e4)
| <Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker.Steps\MarkStep.cs"> | ||
| <Link>Linker\Mono.Linker.Steps\MarkStep.cs</Link> | ||
| </Compile> | ||
| <Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\LoadException.cs"> |
There was a problem hiding this comment.
This is currently breaking the build:
13:27:12 CSC : error CS2001: Source file '/Users/builder/jenkins/workspace/xamarin-android-msbuild-pr-builder/external/linker/linker/Mono.Linker/LoadException.cs' could not be found.
| <Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\LoadException.cs"> | ||
| <Link>Linker\Mono.Linker\LoadException.cs</Link> | ||
| </Compile> | ||
| <Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\MarkException.cs"> |
Bump to mono/2017-04/24c4d616.
Context: https://github.com/xamarin/QualityAssurance/pull/3478 Context: https://xqa.blob.core.windows.net/gist/report-60e42aa322884cedbc8908438cc75dad.txt Changes: dotnet/java-interop@d61b329...476597b * dotnet/java-interop@476597b: [tests] Convert to Unix style line endings (#551) One of the Java.Interop unit tests was implicitly depending on line ending consistency, and would fail if the project was built on Windows after commit 130905e, which began executing those tests: 23) Java.InteropTests.JniValueMarshaler_SByte_ContractTests.JniValueMarshalerContractTests`1.CreateReturnValueFromManagedExpression (Java.Interop-Tests) Expected string length 112 but was 100. Strings differ at index 1. Expected: "{\r\n\tJniRuntime __jvm;\r\n\tsbyte __value;\r\n\r\n\ttry\r\n\t{\r\n\t\treturn ..." But was: "{\n\tJniRuntime __jvm;\n\tsbyte __value;\n\n\ttry\n\t{\n\t\treturn __valu..." -------------^ dotnet/java-interop@476597b normalizes line endings, fixing this failure.
No description provided.