Update to a version of NuGet that understand .NET Standard and .NET Core 2.0 #935

dsplaisted · 2017-03-03T05:39:35Z

This mirrors the version of NuGet that the CLI is currently using: https://github.com/dotnet/cli/blob/4a0724e13641521ed0cf39ac0b72c6d7db666795/build/DependencyVersions.props#L8-L9

nguerrera · 2017-03-03T14:33:20Z

build/DependencyVersions.props

@@ -6,7 +6,8 @@
    <MsBuildPackagesVersion>0.1.0-preview-00028-160627</MsBuildPackagesVersion>
    <DependencyModelVersion>1.0.3</DependencyModelVersion>
    <PlatformAbstractionsVersion>1.0.3</PlatformAbstractionsVersion>
-    <NuGetVersion>4.0.0-rtm-2323</NuGetVersion>
+    <!-- non-official NuGet build taken from https://github.com/nuget/nuget.client/tree/release-4.1.0-netstandard2.0 to contain "2.0" TFMs -->


Do we need this comment? It is bound to get out of date as this version is bumped. What is non-official about it?

This build is from a branch that isn't an official NuGet dev branch. It is branched off of the official branch and then @ericstj made a change do do the netcoreapp2.0 => netstandard2.0 mapping.

The point of the comment is to tell people that we are using basically a "private" NuGet build and to not take a new NuGet build that doesn't have the netstandard2.0 mapping.

Maybe we could add a test that restoring a netcoreapp2.0 app that references netstandard2.0 works? That would ensure we don't take a "bad" NuGet build.

OK, please help me keep an eye on future updates so that when this version becomes official, we remove the comment.

When are we getting off a "private" branch and on to a proper vNext branch for nuget?

And, yes, please add a test.

We've asked the NuGet team multiple times.

/cc @rrelyea @emgarten @rohit21agrawal

I think we can remove the comment. @emgarten is getting the nuget changes merged into the 15.3 VS branch today

nguerrera · 2017-03-03T14:37:19Z

There are assembly loading failures on core. I think you may need to update the CLI we use to build and test as well.

nguerrera

Waiting for tests to pass

emgarten

There is an official build now with netstandard2.0 support. Use 4.3.0-beta1-2342

nguerrera · 2017-03-03T18:08:48Z

There is an official build now with netstandard2.0 support. Use 4.3.0-beta1-2342

:) You probably have to put that in CLI first, then integrate CLI version bump here because the issue with tasks loading different nuget than CLI is still not fixed in CLI.

emgarten · 2017-03-03T18:12:03Z

@nguerrera alright, I'll work on integrating it there also. Can we update this PR to target the new version? I'm trying to make sure this all goes in today.

nguerrera · 2017-03-03T18:12:07Z

https://github.com/dotnet/cli/issues/4214

emgarten · 2017-03-03T21:06:01Z

CLI PR is here dotnet/cli#5912 for reference

…ore 2.0

dsplaisted · 2017-03-03T23:08:03Z

@livarcocc @piotrpMSFT It looks like this is failing because the master branch of the CLI doesn't have the 1.1.1 shared framework. Can you update it to include 1.1.1?

eerhardt · 2017-03-03T23:13:53Z

DotnetCLIVersion.txt

@livarcocc @piotrpMSFT - looks like we got a bad change in the CLI. We are no longer padding our commit counts. We should fix that.

…, as the 2.0 CLI no longer does this

dsplaisted · 2017-03-04T01:12:57Z

It looks like the Ubuntu builds are failing due to NuGet/Home#4424. @eerhardt, is there any workaround we can apply?

emgarten

NuGet version looks good

…d as executable See NuGet/Home#4424

eerhardt · 2017-03-06T18:08:47Z

test/Microsoft.NET.Build.Tests/GivenThatWeWantToBuildASelfContainedApp.cs

+            string selfContainedExecutableFullPath = Path.Combine(outputDirectory.FullName, selfContainedExecutable);
+
+            //  Workaround for https://github.com/NuGet/Home/issues/4424
+            if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))


Can we put this in a common spot in the test framework?

Done, thanks

eerhardt · 2017-03-06T21:42:40Z

src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.CrossGen.targets

@@ -131,6 +131,9 @@ Copyright (c) .NET Foundation. All rights reserved.

    <Message Text="CrossgenCommandline: $(CrossgenCommandline)"/>

+    <!-- Workaround for https://github.com/NuGet/Home/issues/4424 -->
+    <Exec Command="chmod 755 $(CrossgenExe)" Condition="'$(OS)' != 'Windows_NT'"/>


Can we log a tracking bug to take this out when the underlying issue is fixed? That way we remember to remove it.

In general, this is bad in our product because we don't know if we have access to do this or not.

eerhardt · 2017-03-06T21:43:13Z

test/Microsoft.NET.TestFramework/CommandExtensions.cs

@@ -0,0 +1,26 @@
+using FluentAssertions;


(nit) copyright.

omajid · 2017-03-08T14:54:56Z

FYI, this breaks the build on RHEL:

dotnet-install: Calling: machine_has curl
dotnet-install: Calling: calculate_vars 
dotnet-install: Calling: get_azure_channel_from_channel rel-1.0.0
dotnet-install: azure_channel=rel-1.0.0
dotnet-install: Calling: get_normalized_architecture_from_architecture <auto>
dotnet-install: Calling: get_machine_architecture 
dotnet-install: Calling: get_normalized_architecture_from_architecture x64
dotnet-install: normalized_architecture=x64
dotnet-install: Calling: get_specific_version_from_version https://dotnetcli.azureedge.net/dotnet rel-1.0.0 x64 2.0.0-alpha-5212
dotnet-install: specific_version=2.0.0-alpha-5212
dotnet-install: Calling: construct_download_link https://dotnetcli.azureedge.net/dotnet rel-1.0.0 x64 2.0.0-alpha-5212
dotnet-install: Calling: get_current_os_name 
dotnet-install: download_link=https://dotnetcli.azureedge.net/dotnet/Sdk/2.0.0-alpha-5212/dotnet-dev-rhel-x64.2.0.0-alpha-5212.tar.gz
dotnet-install: Calling: resolve_installation_path <auto>
dotnet-install: Calling: get_user_share_path 
dotnet-install: resolve_installation_path: share_path=/home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli
dotnet-install: install_root=/home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli
dotnet-install: Calling: check_pre_reqs 
ldconfig is not in PATH, trying /sbin/ldconfig.
dotnet-install: Calling: install_dotnet 
dotnet-install: Calling: is_dotnet_package_installed /home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli sdk 2.0.0-alpha-5212
dotnet-install: Calling: combine_paths /home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli sdk
dotnet-install: combine_paths: root_path=/home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli
dotnet-install: combine_paths: child_path=sdk
dotnet-install: Calling: combine_paths /home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli/sdk 2.0.0-alpha-5212
dotnet-install: combine_paths: root_path=/home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli/sdk
dotnet-install: combine_paths: child_path=2.0.0-alpha-5212
dotnet-install: is_dotnet_package_installed: dotnet_package_path=/home/dotnet-ci/.jenkins/workspace/dotnet-sdk-master/.dotnet_cli/sdk/2.0.0-alpha-5212
dotnet-install: Zip path: /tmp/dotnet.Yp6C2ATs0
dotnet-install: Downloading https://dotnetcli.azureedge.net/dotnet/Sdk/2.0.0-alpha-5212/dotnet-dev-rhel-x64.2.0.0-alpha-5212.tar.gz
dotnet-install: Calling: download https://dotnetcli.azureedge.net/dotnet/Sdk/2.0.0-alpha-5212/dotnet-dev-rhel-x64.2.0.0-alpha-5212.tar.gz /tmp/dotnet.Yp6C2ATs0
dotnet_install: Error: Download failed

eerhardt · 2017-03-08T16:16:53Z

@omajid and @dsplaisted,

The CLI's RHEL has been broken for a while now. @piotrpMSFT has a PR out to fix it dotnet/cli#5945.

The issue is there is no RHEL CLI build for version 2.0.0-alpha-5212.

When the CLI fixes the RHEL problem and has a new build out, we should update the version number here to a fully completed CLI build.

BTW - @omajid, maybe you know why this is happening. On our RHEL docker container (and only in the RHEL container), we are seeing git commands like git rev-list --count HEAD output warning information to stdout. For example, the output looks like this:

setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
5378

The docker container we are using is: microsoft/dotnet-buildtools-prereqs:rhel7_prereqs. I'm not sure if we didn't set something up correctly in that container. I don't know where the dockerfile is for it, maybe @MichaelSimons knows?

MichaelSimons · 2017-03-08T16:20:43Z

The Dockerfile is in an private repo. FWIW we have plans to move this to the open.

eerhardt · 2017-03-08T16:22:10Z

Here's the dockerfile:

FROM rhel7
MAINTAINER Matt Ellis <matell@microsoft.com>

# Install the base toolchain we need to build anything (clang, cmake, make and the like)
# this does not include libraries that we need to compile different projects, we'd like
# them in a different layer.

# Our toolchain is CMake 3.3.2 from GhettoForge; LLVM 3.6.2 built from source ourselves; wget,
# which, and make (from RHEL).
RUN yum install -y https://matell.blob.core.windows.net/rpms/jsoncpp-0.10.5-1.el7.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/cmake-3.3.2-1.gf.el7.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/clang-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/clang-libs-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/lldb-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/lldb-devel-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/llvm-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/llvm-libs-3.6.2-1.el7.centos.x86_64.rpm \
        wget \
        which \
        make && \
    yum clean all

# Install tools used by the VSO build automation.  We use NodeJS from nodesource.com.
RUN yum install -y https://rpm.nodesource.com/pub_0.10/el/7/x86_64/nodesource-release-el7-1.noarch.rpm && \
    yum updateinfo && \
    yum install -y git \
        zip \
        tar \
        nodejs \
    yum clean all && \
    npm install -g azure-cli

# Dependencies of CoreCLR and CoreFX.  Everything except lttng is present in RHEL, for lttng we
# get the development packages from EfficiOS.
RUN wget -P /etc/yum.repos.d/ https://packages.efficios.com/repo.files/EfficiOS-RHEL7-x86-64.repo && \
    rpmkeys --import https://packages.efficios.com/rhel/repo.key && \
    yum updateinfo && \
    yum install --enablerepo=rhel-7-server-optional-rpms -y libicu-devel \
        libuuid-devel \
        libcurl-devel \
        openssl-devel \
        libunwind-devel \
        lttng-ust-devel && \
    yum clean all

# Define the en_US.UTF-8 locale (without this, processes MSBuild trys to launch complain about
# being unable to use the en_US.UTF-8 locale which can cause downstream failures if you capture
# the output of a run)
RUN localedef -c -i en_US -f UTF-8 en_US.UTF-8

eerhardt · 2017-03-08T16:24:33Z

@ellismg - I see you added the last line in that dockerfile:

# Define the en_US.UTF-8 locale (without this, processes MSBuild trys to launch complain about
# being unable to use the en_US.UTF-8 locale which can cause downstream failures if you capture
# the output of a run)
RUN localedef -c -i en_US -f UTF-8 en_US.UTF-8

Do you know why executing git commands in our build is outputting the following?

setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
5378

ellismg · 2017-03-08T18:37:43Z

@eerhardt I understand the context, I'll take a look. I would have expected this would have fixed it...

omajid · 2017-03-08T18:40:45Z

I just built/tested the dockerfile and I can not reproduce this with plain git:

FROM rhel7
MAINTAINER Matt Ellis <matell@microsoft.com>

# Install the base toolchain we need to build anything (clang, cmake, make and the like)
# this does not include libraries that we need to compile different projects, we'd like
# them in a different layer.

# Our toolchain is CMake 3.3.2 from GhettoForge; LLVM 3.6.2 built from source ourselves; wget,
# which, and make (from RHEL).
RUN yum install -y https://matell.blob.core.windows.net/rpms/jsoncpp-0.10.5-1.el7.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/cmake-3.3.2-1.gf.el7.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/clang-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/clang-libs-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/lldb-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/lldb-devel-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/llvm-3.6.2-1.el7.centos.x86_64.rpm \
        https://matell.blob.core.windows.net/rpms/llvm-libs-3.6.2-1.el7.centos.x86_64.rpm \
        wget \
        which \
        make && \
    yum clean all

# Install tools used by the VSO build automation.  We use NodeJS from nodesource.com.
RUN yum install -y https://rpm.nodesource.com/pub_0.10/el/7/x86_64/nodesource-release-el7-1.noarch.rpm && \
    yum updateinfo && \
    yum install -y git \
        zip \
        tar \
        nodejs \
    yum clean all && \
    npm install -g azure-cli

# Dependencies of CoreCLR and CoreFX.  Everything except lttng is present in RHEL, for lttng we
# get the development packages from EfficiOS.
RUN wget -P /etc/yum.repos.d/ https://packages.efficios.com/repo.files/EfficiOS-RHEL7-x86-64.repo && \
    rpmkeys --import https://packages.efficios.com/rhel/repo.key && \
    yum updateinfo && \
    yum install --enablerepo=rhel-7-server-optional-rpms -y libicu-devel \
        libuuid-devel \
        libcurl-devel \
        openssl-devel \
        libunwind-devel \
        lttng-ust-devel && \
    yum clean all

# Define the en_US.UTF-8 locale (without this, processes MSBuild trys to launch complain about
# being unable to use the en_US.UTF-8 locale which can cause downstream failures if you capture
# the output of a run)
RUN localedef -c -i en_US -f UTF-8 en_US.UTF-8

RUN export LC_ALL="en_US.UTF-8"
CMD mkdir foo && cd foo && git config --global "user.name" "anonymous" && git config --global "user.email" "anonymous" && git init && echo "Hello World" > ignore && git add ignore && git commit -m "first" && git rev-list --count HEAD

When I run the above, I just get "1" as the output and no error messages.

$ sudo docker run --rm -ti dea9c7679a57
Initialized empty Git repository in /foo/.git/
[master (root-commit) 4b84508] first
 1 file changed, 1 insertion(+)
 create mode 100644 ignore
1

I also tried with LANG instead of LC_ALL and that didn't make a difference.

ellismg · 2017-03-08T18:51:59Z

The problem is something specific to how MSBuild Exec stuff worked inside the container (which sort of meshes with what I remember from back when I added that line in the to the dockerfile). Like @omajid I don't repo the issue inside the container when running straight git commands, but I do see it when I invoke MSBuild. I'm continuing to investigate and hope to have a resolution later today.

ellismg · 2017-03-09T00:12:18Z

MSBuild essentially generates a file that looks like this, which it then invokes with #!/bin/sh (the logic is a little more convoluted):

#!/bin/sh

export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

git rev-list --count HEAD

If you run that inside the container, you see the output you might expect:

[root@76250420ec8d cli]# ./repro.sh
./repro.sh: line 4: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
./repro.sh: line 4: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
5387

Interestingly enough, in the container I see this:

[root@76250420ec8d cli]# locale -a
C
POSIX

Once I run localedef -c -i en_US -f UTF-8 en_US.UTF-8 then the locale shows up in locale -a and running the shell script doesn't produce any warning output.

Maybe the image we have on docker hub doesn't match that Dockerfile for some reason? @MichaelSimons

ellismg · 2017-03-09T00:17:31Z

Maybe the image we have on docker hub doesn't match that Dockerfile for some reason? @MichaelSimons

Note that previously we we were managing this stuff without @MichaelSimons's oversite we didn't have great operational hygine on ensuring the dockerfiles were always checked in somewhere sane and published from that location. So I could totally imagine that the image that made it's way to dockerhub did not match what we have in the dockerfile today.

rainersigwald · 2017-03-09T14:51:02Z

@ellismg Should we (MSBuild) do something else in this situation? We were trying to approximate our Windows behavior (to allow commands with high Unicode characters) but I'd totally believe we're doing it wrong . . .

MichaelSimons · 2017-03-09T15:23:19Z

@ellismg, @eerhardt - I think I see what is happening. @eerhardt stated here that microsoft/dotnet-buildtools-prereqs:rhel7_prereqs is being used. This is not the most recent version of the rhel7 image that we have - microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2 is. The checked in Dockerfile is for the latest version.

FYI the docker history command can be of great help in situations like this. If a Docker images was built with a Dockerfile, it will tell you exactly how it was created. The formatting isn't always the easiest to read because of indentation included in the Dockerfile but you can get what you need especially if you specify the --no-trunc option.

docker history microsoft/dotnet-buildtools-prereqs:rhel7_prereqs
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
ffb8aa5a02ca        14 months ago       /bin/sh -c wget -P /etc/yum.repos.d/ https...   141 MB
<missing>           14 months ago       /bin/sh -c yum install -y https://rpm.node...   518 MB
<missing>           14 months ago       /bin/sh -c yum install -y https://dl.fedor...   290 MB
<missing>           14 months ago       /bin/sh -c #(nop) MAINTAINER Matt Ellis <m...   0 B
<missing>           15 months ago                                                       202 MB              Imported from -

docker history microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
6030370d4d83        11 months ago       /bin/sh -c localedef -c -i en_US -f UTF-8 ...   1.61 MB
<missing>           14 months ago       /bin/sh -c wget -P /etc/yum.repos.d/ https...   141 MB
<missing>           14 months ago       /bin/sh -c yum install -y https://rpm.node...   518 MB
<missing>           14 months ago       /bin/sh -c yum install -y https://dl.fedor...   290 MB
<missing>           14 months ago       /bin/sh -c #(nop) MAINTAINER Matt Ellis <m...   0 B
<missing>           15 months ago                                                       202 MB              Imported from -

You can clearly see the V2 version of the image added the localedef -c -i en_US -f UTF-8 en_US.UTF-8 logic. Update the image being used to microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2

eerhardt · 2017-03-09T15:25:57Z

Thanks so much for tracking this issue down, @ellismg @MichaelSimons.

Update the image being used to microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2

I can update our VSTS build def.

…906.2 (dotnet#935) - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19456.2

dnfclas added the cla-already-signed label Mar 3, 2017

livarcocc approved these changes Mar 3, 2017

View reviewed changes

nguerrera reviewed Mar 3, 2017

View reviewed changes

nguerrera approved these changes Mar 3, 2017

View reviewed changes

nguerrera suggested changes Mar 3, 2017

View reviewed changes

emgarten requested changes Mar 3, 2017

View reviewed changes

dsplaisted added 2 commits March 3, 2017 14:41

Update to a version of NuGet that understand .NET Standard and .NET C…

aa14851

…ore 2.0

Update to .NET CLI with .NET Standard 2.0 and .NET Core 2.0 support

5075667

dsplaisted force-pushed the update-nuget branch from 6600fd1 to 5075667 Compare March 3, 2017 22:42

eerhardt reviewed Mar 3, 2017

View reviewed changes

Update build scripts to explicitly install shared framework for 1.1.1…

689a05c

…, as the 2.0 CLI no longer does this

emgarten approved these changes Mar 4, 2017

View reviewed changes

Work around issue where executables from NuGet packages are not marke…

8e489b8

…d as executable See NuGet/Home#4424

eerhardt reviewed Mar 6, 2017

View reviewed changes

Put workaround for executable-ness in common code

2924f0a

nguerrera approved these changes Mar 6, 2017

View reviewed changes

eerhardt approved these changes Mar 6, 2017

View reviewed changes

Add copyright notice to new file

94ac823

dsplaisted mentioned this pull request Mar 6, 2017

Take out workarounds which mark files from NuGet packages as executable once NuGet starts doing this #946

Closed

dsplaisted merged commit ddfd75c into dotnet:master Mar 6, 2017

eerhardt mentioned this pull request Mar 9, 2017

Migration from MSEng to DevDiv - release/1.1.0 dotnet/core-setup#1603

Merged

eerhardt mentioned this pull request May 4, 2017

Debian and Ubuntu docker files warning "setlocale: LC_ALL: cannot change locale (en_US.UTF-8)" dotnet/buildtools#1471

Closed

mmitche pushed a commit to mmitche/sdk that referenced this pull request Jun 5, 2020

Update dependencies from https://github.com/dotnet/arcade build 20190…

edc530d

…906.2 (dotnet#935) - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19456.2

Update to a version of NuGet that understand .NET Standard and .NET Core 2.0 #935

Update to a version of NuGet that understand .NET Standard and .NET Core 2.0 #935

Conversation

dsplaisted commented Mar 3, 2017

nguerrera Mar 3, 2017 • edited Loading

Choose a reason for hiding this comment

eerhardt Mar 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera Mar 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nguerrera commented Mar 3, 2017

nguerrera left a comment

Choose a reason for hiding this comment

emgarten left a comment

Choose a reason for hiding this comment

nguerrera commented Mar 3, 2017

emgarten commented Mar 3, 2017

nguerrera commented Mar 3, 2017

emgarten commented Mar 3, 2017

dsplaisted commented Mar 3, 2017

Choose a reason for hiding this comment

dsplaisted commented Mar 4, 2017

emgarten left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

omajid commented Mar 8, 2017

eerhardt commented Mar 8, 2017

MichaelSimons commented Mar 8, 2017

eerhardt commented Mar 8, 2017

eerhardt commented Mar 8, 2017

ellismg commented Mar 8, 2017

omajid commented Mar 8, 2017

ellismg commented Mar 8, 2017

ellismg commented Mar 9, 2017

ellismg commented Mar 9, 2017

rainersigwald commented Mar 9, 2017

MichaelSimons commented Mar 9, 2017

eerhardt commented Mar 9, 2017

nguerrera Mar 3, 2017 •

edited

Loading

eerhardt Mar 3, 2017 •

edited

Loading

nguerrera Mar 3, 2017 •

edited

Loading