Skip to content

[mono] PR tracking the 2017-04 bump. #551

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 23 commits into from
May 12, 2017
Merged

[mono] PR tracking the 2017-04 bump. #551

merged 23 commits into from
May 12, 2017

Conversation

kumpera
Copy link
Contributor

@kumpera kumpera commented Apr 6, 2017

No description provided.

@dnfclas
Copy link

dnfclas commented Apr 6, 2017

@kumpera,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@jonpryor
Copy link
Contributor

jonpryor commented Apr 6, 2017

stderr: error: no such remote ref 3e5c484fe72f9d681206312d33a15f0f93e7dde7
14:58:25 Fetched in submodule path 'external/Java.Interop', but it did not contain 3e5c484fe72f9d681206312d33a15f0f93e7dde7. Direct fetching of that commit failed.

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 external/Java.Interop ref to instead refer to kumpera/Java.Interop, I imagine that would work.

...or we accept dotnet/java-interop#141 and then you can bump "normally."

That Cecil bump looks "big."

@kumpera
Copy link
Contributor Author

kumpera commented Apr 6, 2017

build

kumpera and others added 6 commits April 11, 2017 15:07
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
Copy link
Member

radical commented Apr 27, 2017

Can we rebuild this? The CI build is failing with

15:43:47  > git fetch --tags --progress git@github.com:xamarin/xamarin-android +refs/pull/*:refs/remotes/origin/pr/*
15:43:49 ERROR: Error fetching remote repo 'origin'

@radical
Copy link
Member

radical commented Apr 27, 2017

build

@radical
Copy link
Member

radical commented Apr 27, 2017

17:15:29 /mnt/jenkins/workspace/xamarin-anroid-linux-pr-builder/xamarin-android/build-tools/dependencies/dependencies.mdproj (default targets) ->
17:15:29 /mnt/jenkins/workspace/xamarin-anroid-linux-pr-builder/xamarin-android/build-tools/scripts/RequiredPrograms.targets (CheckForRequiredPrograms target) ->
17:15:29 
17:15:29 	/mnt/jenkins/workspace/xamarin-anroid-linux-pr-builder/xamarin-android/build-tools/scripts/RequiredPrograms.targets: error : Missing dependency detected. For Linux we do not know how to install program `mono`, version >= 5.2.0.

Could somebody look at this?

@jonpryor
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor Author

kumpera commented Apr 28, 2017

We ignore linux CI results when testing newer mono. Looks like everything is good now!

@radical
Copy link
Member

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
Copy link
Contributor

Is Mono master (5.3.x) usable, or does it need to be 5.2?

@kumpera
Copy link
Contributor Author

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
Copy link
Contributor Author

kumpera commented May 2, 2017

@directhex ugg, forget that, we'll need those packages to move this forward.

@jonpryor
Copy link
Contributor

jonpryor commented May 2, 2017

The current plans to address the linker conflict are for @radekdoulik to remove xamarin-android/external/linker and instead rely on mono's linker checkout. I believe this is intended to land this week.

@directhex
Copy link
Contributor

A prealpha repo now exists, with 5.2 packages. What am I doing with it?

@jonpryor
Copy link
Contributor

jonpryor commented May 4, 2017

@directhex: Do what you did with PR #445: when the Jenkins+Linux instance is started, have it install the pre alpha repo with 5.2 packages, then continue building.

This should be done for the xamarin-andorid-linux and xamarin-android-linux-pr-builder jobs:

@directhex
Copy link
Contributor

build

@directhex
Copy link
Contributor

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
Copy link
Member

@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?

akoeplinger and others added 4 commits May 4, 2017 14:36
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)
Revert "[linker] do not use separate linker submodule anymore"

This reverts commits 363f6cf and
465e609.

 - after discussion on slack we decided to keep our own linker
   submodule, so that linker fixes do not need to go thru mono team
   before reaching XA. it will allow us to fix linker issues faster
@@ -343,6 +343,12 @@
<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">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

linker/81007dfb does not contain a LoadException.cs there.

<Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\LoadException.cs">
<Link>Linker\Mono.Linker\LoadException.cs</Link>
</Compile>
<Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\MarkException.cs">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...ditto MarkException.cs

@jonpryor jonpryor merged commit 8cc4acb into master May 12, 2017
jonpryor pushed a commit that referenced this pull request Jan 7, 2020
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.
@github-actions github-actions bot locked and limited conversation to collaborators Feb 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants