#10 Update to 3.1.106/3.1.6
Merged 2 years ago by directhex. Opened 2 years ago by directhex.
rpms/ directhex/dotnet3.1 master  into  master

file modified
@@ -5,3 +5,4 @@ 




+ /dotnet-v3.1.106-SDK.tar.gz

file modified
+7 -4
@@ -27,10 +27,10 @@ 

  %global dotnet_cflags %(echo %optflags | sed -e 's/-fstack-clash-protection//' | sed -re 's/-specs=[^ ]*//g')

  %global dotnet_ldflags %(echo %{__global_ldflags} | sed -re 's/-specs=[^ ]*//g')


- %global host_version 3.1.5

- %global runtime_version 3.1.5

+ %global host_version 3.1.6

+ %global runtime_version 3.1.6

  %global aspnetcore_runtime_version %{runtime_version}

- %global sdk_version 3.1.105

+ %global sdk_version 3.1.106

  # upstream can update releases without revving the SDK version so these don't always match

  %global src_version %{sdk_version}

  %global templates_version %(echo %{runtime_version} | awk 'BEGIN { FS="."; OFS="." } {print $1, $2, $3+1 }')
@@ -69,7 +69,7 @@ 


  Name:           dotnet3.1

  Version:        %{sdk_rpm_version}

- Release:        5%{?dist}

+ Release:        1%{?dist}

  Summary:        .NET Core Runtime and SDK

  License:        MIT and ASL 2.0 and BSD and LGPLv2+ and CC-BY and CC0 and MS-PL and EPL-1.0 and GPL+ and GPLv2 and ISC and OFL and zlib

  URL:            https://github.com/dotnet/
@@ -532,6 +532,9 @@ 




+ * Tue Jul 21 2020 Jo Shields <joshield@microsoft.com> - 3.1.106-1

+ - Update to .NET Core Runtime 3.1.6 and SDK 3.1.106


  * Tue Jul 21 2020 Omair Majid <omajid@redhat.com> - 3.1.105-5

  - Fix up commented-out define for disabling LTO


file modified
+1 -1
@@ -1,1 +1,1 @@ 

- SHA512 (dotnet-v3.1.105-SDK.tar.gz) = c29caae388ace246af3003d8dd27b6e8255531970629b28b560c4ab2b580cf811f29abacb599f03e551e0a23842d7844226a19bb48ac51ba6fe8c934336fd5c0

+ SHA512 (dotnet-v3.1.106-SDK.tar.gz) = b9dbf4925c8c50611e42ca620697a1ee1c64ba1da2e1eb43c1bae75f2bbf7dc2fbc2f46e0967e342ce9e637e43e4ce0a2743c7ef51eb899db0cab4cb4fda7985

Thanks, looks good to me!

Please make sure to add the tarball to sources using fedpkg new-sources....

Bums, knew I'd forget something. Done

I don't know how to re-trigger CI

CI might not be working until mid-ish August due to datacenter move (or something) but you would do that with [citest]

Hrm, [2020-07-20T13:18:04.710Z] error: Bad source: /workDir/workspace/fedora-rawhide-pr-pipeline/dotnet3.1/dotnet-v3.1.106-SDK.tar.gz: No such file or directory still

What did I do wrong with my fedpkg new-sources?

What did I do wrong with my fedpkg new-sources?

You should see some changes in the sources file (these are important) and .gitignore (less important). You should commit the changes and push them as part of this PR. Otherwise CI wont see the new tarball you added via fedpkg new-sources.

1 new commit added

  • `Add changes fromfedpkg new-sources```
2 years ago

Oh, this is good. CI found a real bug.

If you head over to the Artifacts tab in the CI runner, you will see a lot of files.

Searching for "FAIL" on that page brings me to this file. That file includes these lines:

file-permissions                                            [FAIL]
Total: 46 Passed: 35 Failed: 1

If you go back to the "Artifacts" page, You should be able to see package-tests/logs/logfile-file-permissions.log. That shows the "error":

-rwxr--r-- /usr/lib64/dotnet/packs/NETStandard.Library.Ref/2.1.0/netstandard.library.ref/2.1.0/Debug/netstandard2.0/netstandard.library.ref.assets.cache
error: Missing some execute permissions on /usr/lib64/dotnet/packs/NETStandard.Library.Ref/2.1.0/netstandard.library.ref/2.1.0/Debug/netstandard2.0/netstandard.library.ref.assets.cache
Exit Code: 1

It seems like there's a Debug/netstandard2.0/netstandard.library.ref.assets.cache file with execute permissions only for root. But I think that file should not be part of source-build to begin with. It's not present in Microsoft's SDK:

$ tar tf dotnet-microsoft-built-sdk-3.1.106.tar.gz | grep Debug

We should probably delete the entire Debug directory instead of shipping it in the RPM package.

https://github.com/dotnet/source-build-reference-packages/pull/129 was the ref-packages fix for this. We can re-tag in source-build or patch the update in here.

I suppose the correct thing would be to update the dotnet-build-reference-packages package in Fedora? I can take care of that.

I have built dotnet-build-reference-packages in rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1544360

@directhex Can you re-trigger a build? Closing this PR and re-opening it should do it. As should making a change to the commit itself and force-pushing it to your branch.

Sorry, someone pushed a commit directly to the repo that breaks this PR due to conflicts.

Unfortunately, the commit was also incomplete :(

@directhex I am going to fix up that commit directly, then ask you to rebase this PR. The only conflict should be in the changelog section. Apologies in advance.

I have pushed the changes.

@directhex Can you please rebase this PR on top of master?

rebased onto c4407ef

2 years ago

And now everything's failing!

[2020-07-21T16:52:40.268Z]     createdump-aspnet                                           [FAIL]
[2020-07-21T16:52:40.268Z]     debugging-sos-lldb-via-core                                 [FAIL]
[2020-07-21T16:52:40.269Z]     libuv-kestrel-sample-app                                    [FAIL]
[2020-07-21T16:52:40.269Z]     telemetry-is-off-by-default                                 [FAIL]
[2020-07-21T16:52:40.269Z]     template-test                                               [FAIL]

Something's wrong in the build. I can't see why, though.

This is the scratch build produced by CI: https://koji.fedoraproject.org/koji/taskinfo?taskID=47572802

I grabbed the aspnetcore-targeting-pack package, installed it in a container and looked through its files:

# find /usr/lib64/dotnet/ | grep -i antifor

There's no Microsoft.AspNetCore.Antiforgery.dll :cry:

In the currently-live build, the dll exists:

# find /usr/lib64/dotnet/ | grep -i antifor

I am not sure why that dll got removed. Or what removes it.

Any ideas, @crummel ?

The build.log includes this line:

Copying file from "/builddir/build/BUILD/dotnet-v3.1.106-SDK/previously-built-dotnet/packs/Microsoft.AspNetCore.App.Ref/3.1.3/ref/netcoreapp3.1/Microsoft.AspNetCore.Antiforgery.dll" to "/builddir/build/BUILD/dotnet-v3.1.106-SDK/src/toolset.a7844b9e4a0db833265766e2af14dc7391371038/artifacts/bin/redist/Release/dotnet/packs/Microsoft.AspNetCore.App.Ref/3.1.3/ref/netcoreapp3.1/Microsoft.AspNetCore.Antiforgery.dll".

So the dll is getting produced at some point. But I don't see what happens to it.

@dagood says on IRC:

15:21 < dagood> The 3.1.106 Fedora PR is hanging when I try to add a comment, so I'll try to explain here if that's alright... dseefeld found that Microsoft.AspNetCore.App.Ref/3.1.3 is moving over to source-build-reference-packages 
                (SBRP) in 3.1.106, and I think this might be causing some precedence change potentially using the wrong copy in the build.
15:21 < dagood> Worth a sanity check of whether or not the SBRP build actually contains that DLL first though...
15:21 < dagood> PR in question: https://src.fedoraproject.org/rpms/dotnet3.1/pull-request/10
15:23 < dagood> If SBRP builds the right thing, then it's likely some non-SBRP package is being used, and the right fix would be to switch to SBRP. SBRP is where targeting packs should always come from, in source-build.
15:25 < dagood> (Something that needs to be found out is how to switch to SBRP if it turns out it's not being used, don't know that off the top of my head.)
15:26 < dagood> FYI omajid crummel ^
15:30 < dagood> Oh, I grabbed x86_64 from https://koji.fedoraproject.org/koji/buildinfo?buildID=1544360 and it's really really empty. Just a handful of xml files in this package. It may just be SBRP failure. Repro or binlogs are key now.
15:43 < dagood> Hrm, I might be wrong there, my download actually ended up with an invalid tar.gz on disk. I started a build though, locally.
15:57 < dagood> Ok, in my go-to CentOS container, it builds a Msft.AspNetCore.App.Ref/3.1.3 with only the XML files. 3.1.2 is fine.
15:59 < dagood> I wonder if it has to do with how there's a Microsoft.AspNetCore.App.Ref and microsoft.aspnetcore.app.ref at https://github.com/dotnet/source-build-reference-packages/tree/master/src/targetPacks/ILsrc , MSBuild doing some 
                things case-insensitively....

Thanks to @dagood this was fixed via https://github.com/dotnet/source-build-reference-packages/pull/130. I have updated dotnet-build-reference-packages in rawhide based on that: https://koji.fedoraproject.org/koji/buildinfo?buildID=1544678

@directhex Can you try re-triggering CI here?

That's more encouraging

Nice! Please to merge this into master and do a real build.

I am going to try and prep Fedora 32 version of dotnet-build-reference-packages so we can build there too.

Pull-Request has been merged by directhex

2 years ago