Bug #2023531 “[MIR] dotnet6” : Jammy (22.04) : Bugs : dotnet6 package : Ubuntu

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2023-06-12:

#1

$ lintian --pedantic dotnet6_6.0.116-0ubuntu3.dsc
E: dotnet6 source: source-contains-prebuilt-ms-help-file [src/source-build/src/newtonsoft-json901/Tools/7-zip/7-zip.chm]
E: dotnet6 source: source-ships-excluded-file src/source-build/src/humanizer/samples/Humanizer.MvcSample/Content/Site.css [debian/copyright:4]
E: dotnet6 source: source-ships-excluded-file src/source-build/src/humanizer/samples/Humanizer.MvcSample/Content/themes/base/images/ui-bg_flat_0_aaaaaa_40x100.png [debian/copyright:4]
E: dotnet6 source: source-ships-excluded-file src/source-build/src/humanizer/samples/Humanizer.MvcSample/Content/themes/base/images/ui-bg_flat_75_ffffff_40x100.png [debian/copyright:4]
E: dotnet6 source: source-ships-excluded-file ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
W: dotnet6 source: superfluous-file-pattern src/runtime/src/libraries/Common/tests/System/Net/Prerequisites/Servers/CoreFxNetCloudService/WebServer/Properties/* [debian/copyright:205]
P: dotnet6 source: redundant-globbing-patterns (*eng/common/* src/symreader/eng/*.props src/symreader/eng/common/internal/*) for src/symreader/eng/common/internal/Directory.Build.props [debian/copyright:205]
P: dotnet6 source: redundant-globbing-patterns (*eng/common/* src/symreader/eng/common/internal/*) for src/symreader/eng/common/internal/Tools.csproj [debian/copyright:205]
P: dotnet6 source: redundant-globbing-patterns (*eng/common/* src/test-templates/eng/common/internal/*) for src/test-templates/eng/common/internal/Directory.Build.props [debian/copyright:205]
P: dotnet6 source: redundant-globbing-patterns ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: dotnet6 source: source-contains-autogenerated-visual-c++-file [src/aspnetcore/src/Servers/IIS/AspNetCoreModuleV2/AspNetCore/aspnetcoremodule.rc]
P: dotnet6 source: source-contains-autogenerated-visual-c++-file [src/aspnetcore/src/Servers/IIS/AspNetCoreModuleV2/AspNetCore/resource.h]
P: dotnet6 source: source-contains-autogenerated-visual-c++-file [src/aspnetcore/src/Servers/IIS/AspNetCoreModuleV2/InProcessRequestHandler/HtmlResponses.rc]
P: dotnet6 source: source-contains-autogenerated-visual-c++-file ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: dotnet6 source: source-contains-prebuilt-javascript-object [src/aspnetcore/src/Components/Web.JS/dist/Release/blazor.server.js]
P: dotnet6 source: source-contains-prebuilt-javascript-object [src/aspnetcore/src/Components/Web.JS/dist/Release/blazor.webview.js]
P: dotnet6 source: source-contains-prebuilt-javascript-object [src/aspnetcore/src/Components/benchmarkapps/Wasm.Performance/TestApp/wwwroot/benchmarks/jsonHandlingData.js]
P: dotnet6 source: source-contains-prebuilt-javascript-object ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: dotnet6 source: source-contains-prebuilt-wasm-binary [src/runtime/src/tests/BuildWasmApps/testassets/native-libs/native-lib.o]
P: dotnet6 source: source-contains-prebuilt-wasm-binary [src/runtime/src/tests/BuildWasmApps/testassets/native-libs/variadic.o]
P: dotnet6 source: trailing-whitespace [debian/changelog:39]

Dominik Viererbe (dviererbe) on 2023-06-27

description:

updated

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-06-27:

#2

Clarifications from the MIR meeting:
- There is dotnet7, but only even numbered releases like dotnet6 are an LTS release and only that is meant to get promoted to main.
- there is a more complex support strategy, but not all even numbered dotnets will be supported all the time; dviererbe will write a comment about this
- The plan after upstream support (3 years) is also complex, and they mentioned a transitional package that deinstalls dotnet when it reaches EOL

We are waiting for those details to be added - thanks in advance.

Changed in dotnet6 (Ubuntu):
assignee:	nobody → Christian Ehrhardt  (paelzer)

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2023-06-27:

#3

Terminology:
- .NET LTS = free support and patches for 3 years
- .NET STS = free support and patches for 18 months
See more here: https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

- even numbered .NET release are LTS versions
(e.g. dotnet6 & dotnet8)

- uneven numbered .NET release are STS versions
(e.g. dotnet7)

- Every .NET LTS release (even numbered release) will be
  generally available in an odd numbered year (e.g. dotnet8
  in Nov 2023). Therefore a .NET LTS release needs to be
  supported on Ubuntu LTS from one year ago (22.04), from the
  next year (24.04) and the one after that (26.04), with a
  clear indication of the MS end of support date in the
  package itself.

- At the EoL of the .Net release, both STS and LTS, we will
remove the package from the archive (by providing a
transitional package that uninstalls all binaries).

- We will not MIR .NET STS versions (e.g. dotnet7);
see also https://bugs.launchpad.net/ubuntu/+source/dotnet7/+bug/2023530/comments/2.

TL;DR: dotnet6 and dotnet8 needed for >= 22.04

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-07-03:

#4

Download full text (10.8 KiB)

Review for Source Package: dotnet6

[Summary]
Given the size and complexity of this package and the implication of supporting
the language environment this is in a better state than I expected. Sure I found
some rough edges, but not too bad IMHO.
=> MIR team ACK under the constraint to resolve the below listed TODOs

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: dotnet6 dotnet-host dotnet-hostfxr-6.0 dotnet-runtime-6.0 aspnetcore-runtime-6.0 dotnet-templates-6.0 dotnet-sdk-6.0 dotnet-targeting-pack-6.0 netstandard-targeting-pack-2.1 aspnetcore-targeting-pack-6.0 dotnet-apphost-pack-6.0

Specific binary packages built, but NOT to be promoted to main: dotnet-sdk-6.0-source-built-artifacts
This is only needed for future builds and an aspect of the bootstrapping process.

Notes:
TODO: - add todos, issues or special cases to discuss
Required TODOs:
#1a
- Please further clarify the future handling of updates
  Thanks Dviererbe for sharing more details on what happens after EOL.
  Is there a prior example of "providing a transitional package that uninstalls
  all binaries". While I totally understand the motivation it is also
  rather rude.
  People might say "I didn't care for detail X" but now I can't use it
  anymore - or similar.
  Is that approach an established pattern that I missed so far?
  If not we should probably run this by the SRU team (and they decide if also by the TB).
#1b
- And just to be double sure, you do not intent to e.g. move them
  dotnet6 -> dotnet8, but uninstall it right?
#1c
- Finally, generally and given the impact of the above, is there a draft
  of that "with a clear indication of the MS end of support date in the
  package itself" content? Because with the plan of removal it isn't just
  "the MS end of support" it is "the MS and Ubuntu end of support
  and existence".
#3a
- You mentioned to need lld and llvm. Please be aware that I've only seen
  build time dependencies to those which since a long time you no more
  strictly need in main. Even then runtime dependencies of things embedding
  llvm features are usually just needing libllvm13/14/15... and those are
  in main already. So do you need to correct your template or have I missed
  how you depend on them?
#3b
- If I somehow missed them, even then the MIRs for lld and llvm should not
  be in this bug (it is complex enough) but a new one each and refer to here.
  Just like with the versions here (dotnet6, dotnet7, ...) please ensure you
  keep the list of fully supported releases at a well selected minimum. For
  example rustc pulls llvm-13 into jammy. You use the default which is v14
  on jammy - which would imply two versions in main. I do not even mind on
  which side this is sorted out, but it would help to use the same
  where possible.
#4
- Please point me to the build time tests (More details below in the
  [Common blockers] section.

Recommended TODOs:
#2
- I understand that this oddity of needing .git structures is unavoidable
  right now. But it would be great if you would find a way to patch this
  out in a nice way or at least chime in and adopt upstream issue 3359
  once reso...

Review for Source Package: dotnet6

[Summary]
Given the size and complexity of this package and the implication of supporting
the language environment this is in a better state than I expected. Sure I found
some rough edges, but not too bad IMHO.
=> MIR team ACK under the constraint to resolve the below listed TODOs

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: dotnet6 dotnet-host dotnet-hostfxr-6.0 dotnet-runtime-6.0 aspnetcore-runtime-6.0 dotnet-templates-6.0 dotnet-sdk-6.0 dotnet-targeting-pack-6.0 netstandard-targeting-pack-2.1 aspnetcore-targeting-pack-6.0 dotnet-apphost-pack-6.0

Specific binary packages built, but NOT to be promoted to main: dotnet-sdk-6.0-source-built-artifacts
This is only needed for future builds and an aspect of the bootstrapping process.

Notes:
TODO: - add todos, issues or special cases to discuss
Required TODOs:
#1a
- Please further clarify the future handling of updates
  Thanks Dviererbe for sharing more details on what happens after EOL.
  Is there a prior example of "providing a transitional package that uninstalls
  all binaries". While I totally understand the motivation it is also
  rather rude.
  People might say "I didn't care for detail X" but now I can't use it
  anymore - or similar.
  Is that approach an established pattern that I missed so far?
  If not we should probably run this by the SRU team (and they decide if also by the TB).
#1b
- And just to be double sure, you do not intent to e.g. move them
  dotnet6 -> dotnet8, but uninstall it right?
#1c
- Finally, generally and given the impact of the above, is there a draft
  of that "with a clear indication of the MS end of support date in the
  package itself" content? Because with the plan of removal it isn't just
  "the MS end of support" it is "the MS and Ubuntu end of support
  and existence".
#3a
- You mentioned to need lld and llvm. Please be aware that I've only seen
  build time dependencies to those which since a long time you no more
  strictly need in main. Even then runtime dependencies of things embedding
  llvm features are usually just needing libllvm13/14/15... and those are
  in main already. So do you need to correct your template or have I missed
  how you depend on them?
#3b
- If I somehow missed them, even then the MIRs for lld and llvm should not
  be in this bug (it is complex enough) but a new one each and refer to here.
  Just like with the versions here (dotnet6, dotnet7, ...) please ensure you
  keep the list of fully supported releases at a well selected minimum. For
  example rustc pulls llvm-13 into jammy. You use the default which is v14
  on jammy - which would imply two versions in main. I do not even mind on
  which side this is sorted out, but it would help to use the same
  where possible.
#4
- Please point me to the build time tests (More details below in the
  [Common blockers] section.

Recommended TODOs:
#2
- I understand that this oddity of needing .git structures is unavoidable
  right now. But it would be great if you would find a way to patch this
  out in a nice way or at least chime in and adopt upstream issue 3359
  once resolved. I say "a nice way" because if the alternative makes it worse
  there is no benefit.
#5
- have a look at filtering d/watch to only one major version (more see in the
  [Packaging red flags] section below)
#6
- while classic symbols tracking isn't very applicable this has way too many
  shared objects that not thinking about it would be ok. More details about
  this request below the [Packaging red flags] section.
#7
- In the context of tests (#4) and ABI tests (#6) I've seen mentioning of a
  JIT test (https://github.com/dotnet/runtime/issues/68837) which refers to
  https://github.com/dotnet/runtime/blob/main/docs/project/jit-testing.md
  I've not seen that on build not autopkgtest time.
  They mention running on Ubuntu 18.04 so it should generally work, could
  adding that to autopkgtests could be a great addition? Please have a look
  at that. Only recommended as I'm not having enough experience on this, the
  request might be unfulfillable.

[Duplication]
There is no other package in main providing the same functionality.
There are different versions served and Foundations has outlined how they
intent to not duplicate all of it so that we do not end up supporting
all versions for all time.

I still want to clarify further what users can rely on and what to expect,
for that I've added a few more questions to the required tasks.

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems:
- depending on git entries, I know you tried and you are aware. But please
  never stop trying to get rid of this dependency. Even if it happens
  (https://github.com/dotnet/source-build/issues/3359) it won't apply to
  dotnet6, but you should try to chime in and poke on trying to make this
  package more normal. It is complex enough without this.
  => see recommended todo #2
- other Dependencies to MIR due to this
  you've written "There are further dependencies that are not yet in main,
  the MIR process for them is handled as part of this bug here." but (so far)
  there isn't content for it in this bug. OTOH I didn't see why you need them.
  => See required todo #3

[Embedded sources and static linking]
OK:
- no embedded source present, although this is hard to answer right in this
  case. dotnet6 as packaged and release by upstream is a conglomerate of
  many repositories. So in a way it has embedded sources, many of them.
  But OTOH a selection of all those repos is what makes dotnet6 and gladly
  AFAICS none of these components is used for anything else which would imply
  the demand for separating them.
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)

Problems:
- history of CVEs does not look concerning, but because it is such a complex
  thing always will have something. Also for the chance of toolchain bug that
  affect anything built with it it would be a high value attack target.
- does deal with cryptography (en-/decryption, certificates, signing, ...).
  While it tries to delegate to system libraries where possible, due to
  platform differences there is crypto code in dotnet and in any case the
  calls flow through the wrappers even if delegated to system libraries.
- does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...), but we can consider
  it mostly from a trusted source.

=> Overall it seems clear, this needs a security review as well

[Common blockers]
OK:
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest
- This does not need special HW for build or test
- no new python2 dependency

Problems:
- You stated in your report "The package runs a test suite on build time,
  if it fails it makes the build fail". But I was looking and I'm unsure
  about that. I only found the "Detailed Build Summary". I asked a bit around
  and learned that running the intended smoke tests can not be done in the
  build env (https://github.com/dotnet/source-build/issues/3386)
  I might only be blind and that is fine, would you point me to where/which
  tests run in a build log please so I can give you a pass or request
  for more testing?
  Note: in some cases build time tests are too hard, but I see you have added
  plenty of autopkgtest already and worst case you might add more there
  as this environment is a bit more flexible.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta as this is only packaged in Ubuntu
- Upstream update history is good
- Debian/Ubuntu update history is good (While there is no help from Debian as
  it only exists in Ubuntu, it has a team behind it and due to that updates
  are good so far)
- the current release is packaged (relatively, you are one week too old, but
  there is a limit to updates - this is not "too old")
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings and mostly overridden and documented
  what the reason is or which bug you wait on to get rid of them.
- debian/rules is rather clean given how complex it is

Problems:
- debian/watch is present and works, but it does not filter main versions
  so 6.x warns about v7.0.305 and such. Maybe have a look if that can be
  improved.
- symbols tracking is not in place and you might say "that is not applicable".
  But it provides 13 .so files and 509 DLLs which are libs just as much.
  I'm sure with such complexity they will already need to have some symbols
  tracking in place, could you check if that runs in our build, provide an
  example of it failing on patching things badly (simulating a future SRU
  upload). I've found that e.g. libcoreclr.so isn't meant for that
  https://github.com/dotnet/runtime/issues/12281: "We consider the set of
  APIs exported by libcoreclr.so to be internal implementation detail and
  changing it frequently". But is that also true for all the other .so files?
  Is it also true for all the DLLs? It would be great if you could do some
  research and either link&state why it isn't needed or how you will cover it.
- It is not on the lto-disabled list, but locally has LTO disabled. I think
  there is not much we can do other than maybe asking for an upstream issue
  to be filed, but even that is unlikely to be acted - not filing a TODO
  for this.

[Upstream red flags]
OK:
- no Errors/warnings during the build that caught my attention
- I must state that on I feel unable to state if there are incautious use
  of malloc/sprintf. But this needs to go to security review anyway
  and the scanner tools there are much better at finding those anyway.
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (only in tests and docs)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- translations are somewhat present in the source using the dotnet style
  with resx files. But there is only a small portion translated. So small
  that it would not help to package that up. OTOH this isn't for the
  unexperienced user, it is part of a developer story where going untranslated
  isn't perfect but acceptable

Problems: None

Changed in dotnet6 (Ubuntu):
assignee:	Christian Ehrhardt  (paelzer) → Ubuntu Security Team (ubuntu-security)

Steve Beattie (sbeattie) on 2023-07-03

tags:

added: sec-2331

Revision history for this message

Nishit Majithia (0xnishit) wrote on 2023-08-11:

#5

Download full text (5.8 KiB)

I reviewed dotnet6 6.0.120 as checked into Mantic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

dotnet6 is an open-source platform for building desktop, web, and mobile
applications that can run natively on any operating system. The dotnet
system includes tools, libraries, and languages that support modern,
scalable, and high-performance software development.

- CVE History:
  - CVE-2022-38013: Fixed in 6.0.109
  - CVE-2022-41032: Fixed in 6.0.110
  - CVE-2023-21538: Fixed in 6.0.113
  - CVE-2023-24936: Fixed in 6.0.118
  - CVE-2023-28260: Fixed in 6.0.116
  - CVE-2023-29331: Fixed in 6.0.118
  - CVE-2023-29337: Fixed in 6.0.118
  - CVE-2023-32032: Fixed in 6.0.118
  - CVE-2023-33128: Fixed in 6.0.118
  - CVE-2023-33170: Fixed in 6.0.120
- Build-Depends?
  - clang
  - cmake
  - bash-completion
  - debhelper-compat (= 13)
  - dotnet-sdk-6.0
  - dotnet-sdk-6.0-source-built-artifacts
  - git
  - libicu-dev
  - libkrb5-dev
  - liblttng-ust-dev
  - libssl-dev
  - libunwind-dev
  - lld
  - llvm
  - locales-all
  - python3
  - zlib1g-dev
- pre/post inst/rm scripts?
  - None
- init scripts?
  - None
- systemd units?
  - None
- dbus services?
  - None
- setuid binaries?
  - no `suid` or `sgid` binaries
- binaries in PATH?
  - dotnet6, dotnet-host, dotnet-hostfxr-6.0, dotnet-runtime-6.0,
    aspnetcore-runtime-6.0, dotnet-templates-6.0, dotnet-sdk-6.0,
    dotnet-targeting-pack-6.0, netstandard-targeting-pack-2.1,
    aspnetcore-targeting-pack-6.0, dotnet-apphost-pack-6.0
- sudo fragments?
  - None
- polkit files?
  - None
- udev rules?
  - None
- unit tests / autopkgtests?
  - Yes, autopkgtests runs fine locally passing all the tests
- cron jobs?
  - None
- Build logs:
  - same lintian errors described in https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug/2023531/comments/1

- Processes spawned?
  - Yes, it is mainly in the `src/runtime` directory which is responsible
    for dotnet runtime infrastructure. Most of the process spawn
    instructions are found in `coreclr` which is the execution engine for
    dotnet applications. It includes the JIT compiler, garbage collector,
    and other low-level components that manage the execution of dotnet code.
  - It also exists in many test files in `fsharp` directory, which is
    expected
- Memory management?
  - Heavy usage of memory-related functions in `runtime` directory, is
    expected from a framework
- File IO?
  - File IO operations are heavily used in `src/aspnetcore` and
    `src/runtime` dirs
  - Specifically, it is being used in the `src/runtime/src/libraries` directory
    which provides fundamental functionality for .NET applications, such
    as data types, collections, input/output, and more.
  - This looks okay
- Logging?
  - Error format looks fine
  - It majorly uses `Trace.TraceError()`, `std::system_error()` and
    `std::runtime_error()` in various situations, which is expected
- Environment variable usage?
  - Env variables use in `src/runtime/src/mono/mono/eventpipe` dir look
    fine. EventPipe is a feature that collects diagnostic and
    telemetry information from dotnet applications at runtime. It's used
    for profiling, debuggin...

Response to the review for Source Package: dotnet6

First of all, thanks Christian (~paelzer) & Nishit (~0xnishit) for the extensive review!

Required TODOs:
> #1a
> - Please further clarify the future handling of updates
>   Thanks Dviererbe for sharing more details on what happens after EOL.
>   Is there a prior example of "providing a transitional package that uninstalls
>   all binaries". While I totally understand the motivation it is also
>   rather rude.
>   People might say "I didn't care for detail X" but now I can't use it
>   anymore - or similar.
>   Is that approach an established pattern that I missed so far?
>   If not we should probably run this by the SRU team (and they decide if also by the TB).
I discussed the EoL Strategy again with Security, Foundations & Microsoft. I documented the outcome in the README.source [1]. TL;DR: We keep the package as is in the archive and demote it to universe. We asked Microsoft to warn the User about EoL. Note that this is also the RedHat EoL strategy for .NET.
You can also find more context about the discussion in the JIRA ticket FR-4855 [2]

> #1b
> - And just to be double sure, you do not intent to e.g. move them
>   dotnet6 -> dotnet8, but uninstall it right?
We (Foundations – Toolchains) discussed this approch and rejected it, because this may break some users' use-case or may change the behavior of .NET applications. Especially for users that install multiple runtimes/sdks in parallel.

> #1c
> - Finally, generally and given the impact of the above, is there a draft
>   of that "with a clear indication of the MS end of support date in the
>   package itself" content? Because with the plan of removal it isn't just
>   "the MS end of support" it is "the MS and Ubuntu end of support
>   and existence".
As mentioned in the answer for #1a above; this is now documented in the README.source [1].

> #3a
> - You mentioned to need lld and llvm. Please be aware that I've only seen
>   build time dependencies to those which since a long time you no more
>   strictly need in main. Even then runtime dependencies of things embedding
>   llvm features are usually just needing libllvm13/14/15... and those are
>   in main already. So do you need to correct your template or have I missed
>   how you depend on them?
> #3b
> - If I somehow missed them, even then the MIRs for lld and llvm should not
>   be in this bug (it is complex enough) but a new one each and refer to here.
>   Just like with the versions here (dotnet6, dotnet7, ...) please ensure you
>   keep the list of fully supported releases at a well selected minimum. For
>   example rustc pulls llvm-13 into jammy. You use the default which is v14
>   on jammy - which would imply two versions in main. I do not even mind on
>   which side this is sorted out, but it would help to use the same
>   where possible.
This was an error on my side. lld and llvm are not needed. I just thought that they are needed, because the check-mir tool pointed out that they aren't in main.

#4
> - Please point me to the build time tests (More details below in the
>   [Common blockers] section.
This was also a confusion on my side. There are no build time tests and I don't know if we want  to automatically run the tests during build time, because a build of .NET or running the autopkgtest suite can take hours. There are multiple occasions were a coupled execution of the autopkgtest suite would have slowed down our ability to iterate.
I think this is fine, because we always trigger the autopkgtests in a PPA when a change occurs and the autopkgtests in the proposed pocket have to pass before a new version is deployed to end-users.

Recommended TODOs:
> #2
> - I understand that this oddity of needing .git structures is unavoidable
>   right now. But it would be great if you would find a way to patch this
>   out in a nice way or at least chime in and adopt upstream issue 3359
>   once resolved. I say "a nice way" because if the alternative makes it worse
>   there is no benefit.
Robie Basak also suggested this to us, because the need for the .git folder interferes with git-ubuntu. I don't know if we are able to patch this for .NET 6 before EoL, but this is definitely on our TODO for .NET 8.

> #5
> - have a look at filtering d/watch to only one major version (more see in the
>   [Packaging red flags] section below)
I "fixed" the watch file. It now can tell correctly if a new upstream version exists, but it will intentionally fail. The reason is also explained in the README.source [3] and there is a comment
in the watch file [4]. TL;DR: The .NET 6 source code is distributed over several public repositories and has no single public place to download the source from. This will change with .NET 8.

> #6
> - while classic symbols tracking isn't very applicable this has way too many
>   shared objects that not thinking about it would be ok. More details about
>   this request below the [Packaging red flags] section.
> #7
> - In the context of tests (#4) and ABI tests (#6) I've seen mentioning of a
>   JIT test (https://github.com/dotnet/runtime/issues/68837) which refers to
>   https://github.com/dotnet/runtime/blob/main/docs/project/jit-testing.md
>   I've not seen that on build not autopkgtest time.
>   They mention running on Ubuntu 18.04 so it should generally work, could
>   adding that to autopkgtests could be a great addition? Please have a look
>   at that. Only recommended as I'm not having enough experience on this, the
>   request might be unfulfillable.
I have to read up on these topics, but I agree that both should be added if they are fulfillable

[Summary of our TODO-List]
1. Integrate (upstream) smoke tests into autopkgtest suite.
2. Investigate embedded third party dependencies that should/can be patched out of dotnet packages.
3. Patch out need for .git folder.
4. Investigate symbols tracking for .so and .dll files.
5. Investigate enabling LTO.
6a. Investigate state of JIT Tests.
6b. Investigate feasibility of integration into autopkgtest suite

Note: These should not block the main inclusion as the TODOs are all non trivial and not strictly required.

[1] https://git.launchpad.net/ubuntu/+source/dotnet6/tree/debian/README.source?id=1d83c4e1f527adcc0f9a30a39ad55c64260ef6bd#n39
[2] https://warthogs.atlassian.net/browse/FR-4855
[3] https://git.launchpad.net/ubuntu/+source/dotnet6/tree/debian/README.source?id=1d83c4e1f527adcc0f9a30a39ad55c64260ef6bd#n55
[4] https://git.launchpad.net/ubuntu/+source/dotnet6/tree/debian/watch?id=1d83c4e1f527adcc0f9a30a39ad55c64260ef6bd#n5

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-08-24 (last edit on 2023-08-24):

#8

#1a
> TL;DR: We keep the package as is in the archive and demote it to universe.
> We asked Microsoft to warn the User about EoL.
> You can also find more context about the discussion in the JIRA ticket FR-4855 [2]

Thanks for clarifying, that is at least a bit more comfortable to the users (compared to removing).
I like this new approach more.
But as I already hinted before, I think you really want/need also an SRU exception for this as well as it doesn't seem purely a MIR team decision.
Link the approved exception here please once done.
=> https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases

#1b - thanks, ok with it, thanks for spelling it out
=> Ack on this aspect

#1c - thanks, ok with it, thanks for documenting
=> Ack on this aspect

#3* llvm lld
Thanks for the clarification
=> Ack on this aspect

#4 only testing in autopkgtests

I'd prefer to have something not as gigantic in build time tests (read = "I agree to not add the huge thing, but something small maybe", just a reasonable sanity check).
But that isn't a hard requirement if there are good autopkgtests and there are.
You have lots of good "make the autopkgtest even better" and that might be where the time is indeed spend better now.
=> Ack on this aspect

#2 .git dir
Thanks for not giving up, I'm ok if this is solved in the mid-term
=> Ack on this aspect

#5 d/watch
Thanks for explaining, fixing and documenting.
I'm pleased to learn this will improve in the future
=> Ack on this aspect

The optional #6 / #7 will be covered by your longer list of known things you work on.
"""
1. Integrate (upstream) smoke tests into autopkgtest suite.
2. Investigate embedded third party dependencies that should/can be patched out of dotnet packages.
3. Patch out need for .git folder.
4. Investigate symbols tracking for .so and .dll files.
5. Investigate enabling LTO.
6a. Investigate state of JIT Tests.
6b. Investigate feasibility of integration into autopkgtest suite
"""

Thanks for stating this so clearly here.

#1a
> TL;DR: We keep the package as is in the archive and demote it to universe.
> We asked Microsoft to warn the User about EoL.
> You can also find more context about the discussion in the JIRA ticket FR-4855 [2]

Thanks for clarifying, that is at least a bit more comfortable to the users (compared to removing).
I like this new approach more.
But as I already hinted before, I think you really want/need also an SRU exception for this as well as it doesn't seem purely a MIR team decision.
Link the approved exception here please once done.
=> https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases

#1b - thanks, ok with it, thanks for spelling it out
=> Ack on this aspect

#1c - thanks, ok with it, thanks for documenting
=> Ack on this aspect

#3* llvm lld
Thanks for the clarification
=> Ack on this aspect

#4 only testing in autopkgtests

I'd prefer to have something not as gigantic in build time tests (read = "I agree to not add the huge thing, but something small maybe", just a reasonable sanity check).
But that isn't a hard requirement if there are good autopkgtests and there are.
You have lots of good "make the autopkgtest even better" and that might be where the time is indeed spend better now.
=> Ack on this aspect

#2 .git dir
Thanks for not giving up, I'm ok if this is solved in the mid-term
=> Ack on this aspect

#5 d/watch
Thanks for explaining, fixing and documenting.
I'm pleased to learn this will improve in the future
=> Ack on this aspect

The optional #6 / #7 will be covered by your longer list of known things you work on.
"""
1. Integrate (upstream) smoke tests into autopkgtest suite.
2. Investigate embedded third party dependencies that should/can be patched out of dotnet packages.
3. Patch out need for .git folder.
4. Investigate symbols tracking for .so and .dll files.
5. Investigate enabling LTO.
6a. Investigate state of JIT Tests.
6b. Investigate feasibility of integration into autopkgtest suite
"""

Thanks for stating this so clearly here.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-08-24:

#9

TL;DR the above - ATM left open to be clarified, answered or resolved:

#1a - Please get and link an SRU exception approval for this new behavior of treating active releases.

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2023-09-04:

#10

#1a

The SRU Page [1] now has an entry for the .NET EOL behaviour:
> Not strictly a standard SRU exception, but due to the way dotnet is handled
> upstream and the lifespan of its LTS status, the dotnet packages in the
> Ubuntu archives require special EOL rules. The EOL of various dotnetX packages
> will be handled in accordance with the rules outlined in dotnetEOLException.
> This stable release exception has been approved by LukaszZemczak for the SRU
> team as of 2023-09-01.

You can see the wiki page that describes the .NET EOL behaviour here [2]

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
[2] https://wiki.ubuntu.com/dotnetEOLException

#4

We like the idea and added it to our Roadmap. We intend to compile and run a
hello world application after a successfull build.

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2023-09-04 (last edit on 2023-09-04):

#11

I have to backtrack on #1a. Łukasz pulled it off the wiki (for now), because Robie Basak had issues with it.

TL;DR: SRU exception still not approved

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2023-09-12:

#12

Time is running short -- can we reach a consensus on how this will reach a graceful end of life before all the other packages?

Thanks

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2023-11-21 (last edit on 2023-11-21):

#13

Hi, since the last time we had multiple discussions with Microsoft, the SRU Team, the Security Team, Oliver Smith and Lech Sandecki.

We will backport security patches after the upstream support ends as part of the Ubuntu LTS and Ubuntu Pro story, but we still recommend users to switch versions after the upstream support ends. Therefore we no longer need an exception.

Additionally our support/distribution strategy has changed (see #3 [1] for details about the old strategy):
- We will ship the latest .NET LTS (e.g. .NET 6, 8, 10) to the latest Ubuntu LTS and backport to the -1 Ubuntu LTS and Interim releases.
- We will ship .NET STS releases (.NET 7, 9, 11) only to Ubuntu Interim releases.

e.g.
- .NET 8 LTS will be on 22.04 LTS, 23.10 and 24.04 LTS
- .NET 9 STS will be on 24.10, 25.04, 25.10
- .NET 10 LTS will be on 24.04 LTS, 25.04, 25.10 and 26.04 LTS

With this change we would like to have all .NET packages in main. The only exception is .NET 7 in jammy that we want to keep in universe.

I will open seperate MIR requests for the dotnet7 and dotnet8 package.

FYI:
- I am currently backporting .NET 8 to jammy
- We will not backport .NET 8 to lunar, because of the limited lifespan left.
- .NET 6 and 7 is currently in noble, but we will remove it over the next weeks.

[1] https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug/2023531/comments/3

Revision history for this message

Łukasz Zemczak (sil2100) wrote on 2023-11-24:

#14

I have not been part of the SRU discussions per-se, but I know Robie has been and that the current plan does not require an SRU exception anymore. So if the MIR is blocked on that, I think it can proceed.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-11-27:

#15

Thank you all for the ongoing discussions and clarifications.
As discussed in the MIR meeting, I'm checking if all past requirements are fulfilled.

- Of the required TODOs we've had major updates to #1* due to making this more similar to other toolchain packages. Therefore this former need is satisfied and acknowledged
- Thanks also to Łukasz for stating the SRU POV while Robie is out.

- The other required TODOs, #3 has already been resolved before.

- Multiple recommended TODOs have been addressed or are still in the making - thanks.

- Finally the one required TODO that is open is #4 - at least some testing
  - that was split out to bug 2032945
  - put onto the teams roadmap
  - already started
  - and stated to be available soon

=> Once that (#4) is completed there are no more required steps left for the needs of the MIR review and this can pass

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2024-04-02:

#16

> 17:46:03 - cpaelzer: just tests to be added, then it is good
> 17:46:08 - cpaelzer: long things are finally good
(See https://irclogs.ubuntu.com/2023/11/28/%23ubuntu-meeting.html#t15:46)

The latest updates (LP: #2057982, #2057699) added minimal build time tests and extended the autopkgtest coverage by integrating the RedHat test suite.

Therefore, the final requirement for the .NET MIR should be fulfilled.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-02:

#17

Thank you Dominik, yes - by that it seems complete now.
Ready for you to change seeds to pull it into main.

Changed in dotnet6 (Ubuntu):
status:	Incomplete → In Progress

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2024-04-02:

#18

As discussed in the MIR meeting I created a dotnet8 MIR bug; see LP: #2060056

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2024-04-10:

#19

Just FYI: Comment #13 states "[...] we would like to have all .NET packages in main. The only exception is .NET 7 in jammy that we want to keep in universe."

.NET 7 will go EoL on May 14, 2024 and mantic will go EoL in July 2024. Therefore it does not make a lot of sense to MIR the dotnet7 package for mantic.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-11:

#20

v6 exists in Jammy, Mantic - promoting it there would be ok, although for mantic there isn't much time left

For Noble forward we only want v8 IIUC, that seems fine as you need to let go of the old at some point - or will that change again later?

Changed in dotnet6 (Ubuntu Noble):
status:	In Progress → Invalid
Changed in dotnet6 (Ubuntu Mantic):
status:	New → In Progress
Changed in dotnet6 (Ubuntu Jammy):
status:	New → In Progress

Lukas Märdian (slyon) on 2024-04-11

Changed in dotnet6 (Ubuntu Mantic):
status:	In Progress → Fix Committed
Changed in dotnet6 (Ubuntu Jammy):
status:	In Progress → Fix Committed

Revision history for this message

Dominik Viererbe (dviererbe) wrote on 2024-04-11 (last edit on 2024-04-11):

#21

> For Noble forward we only want v8 IIUC, that seems fine as you need to let go of the old at some point - or will that change again later?

Correct and this* should™ not change in the near/medium distant future. FYI: dotnet6 and dotnet7 was removed from noble for that reason (see LP: #2044511, #2044513).

Should not be relevant for the MIR, but just FYI: We will provide dotnet6 and dotnet7 for noble in a PPA, with best effort support limited to the upstream lifespan. Microsoft even wants to stops providing builds in there own PPA starting with noble.

EDIT:
* the strategy described in comment 13

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-18:

#22

For Mantic I see it is pulled in via the seeds as expected now [1].
For jammy that is not there, but that is because it was not updated for two months which is a different problem - the change is the very same and is ok.

The case is approved, it was meant to also go back to Jammy and where the reports run it confirms that the seed changes worked.
Promoting ...

[1]: https://ubuntu-archive-team.ubuntu.com/germinate-output/ubuntu.mantic/all

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-18:

#23

Download full text (11.3 KiB)

Sorry for the delay, I didn't want to mess this up doing it in between meetings.

The one in mantic-release is a bit older and misses quite some of the good work done over the last half year.
On Jammy (and in general the latest push to -security) is not too old only 2 months ago. For the change that someone only uses -security I think it is fine to promote those two (but not mantic-release).

That will also ensure both pockets that will be further changed are on the right component.
And from here on any further upload and change will be on top of that latest version anyway.

Comparing to the new releases we had no s390x support yet - ok.
These older releases did not create -dbg (not -dbgsym, those are there).
I found a meant to be new "Added new binary packages for debug symbols." - so that makes sense

With all that confirmed it matches the dry-run preview ...
Going on:

Override component to main
dotnet6 6.0.128-0ubuntu1~22.04.2 in jammy: universe/devel -> main
aspnetcore-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
aspnetcore-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-host 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-host 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.128-0ubuntu1~22.04....

Sorry for the delay, I didn't want to mess this up doing it in between meetings.

The one in mantic-release is a bit older and misses quite some of the good work done over the last half year.
On Jammy (and in general the latest push to -security) is not too old only 2 months ago. For the change that someone only uses -security I think it is fine to promote those two (but not mantic-release).

That will also ensure both pockets that will be further changed are on the right component.
And from here on any further upload and change will be on top of that latest version anyway.

Comparing to the new releases we had no s390x support yet - ok.
These older releases did not create -dbg (not -dbgsym, those are there).
I found a meant to be new "Added new binary packages for debug symbols." - so that makes sense

With all that confirmed it matches the dry-run preview ...
Going on:

Override component to main
dotnet6 6.0.128-0ubuntu1~22.04.2 in jammy: universe/devel -> main
aspnetcore-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
aspnetcore-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-host 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-host 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
dotnet6 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
dotnet6 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.128-0ubuntu1~22.04.2 in jammy amd64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.128-0ubuntu1~22.04.2 in jammy arm64: universe/devel/optional/100% -> main
Override [y|N]? y
25 publications overridden.

Override component to main
dotnet6 6.0.127-0ubuntu1~22.04.1 in jammy: universe/devel -> main
aspnetcore-runtime-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
aspnetcore-runtime-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-host 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-host 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
dotnet6 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
dotnet6 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.127-0ubuntu1~22.04.1 in jammy amd64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.127-0ubuntu1~22.04.1 in jammy arm64: universe/devel/optional/100% -> main
Override [y|N]? y
25 publications overridden.

Override component to main
dotnet6 6.0.128-0ubuntu1~23.10.2 in mantic: universe/devel -> main
aspnetcore-runtime-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
aspnetcore-runtime-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-host 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-host 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
dotnet6 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
dotnet6 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.128-0ubuntu1~23.10.2 in mantic amd64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.128-0ubuntu1~23.10.2 in mantic arm64: universe/devel/optional/100% -> main
Override [y|N]? y
25 publications overridden.

Override component to main
dotnet6 6.0.127-0ubuntu1~23.10.1 in mantic: universe/devel -> main
aspnetcore-runtime-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
aspnetcore-runtime-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
aspnetcore-targeting-pack-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-apphost-pack-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-host 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-host 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-hostfxr-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-runtime-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-sdk-6.0-source-built-artifacts 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-targeting-pack-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet-templates-6.0 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
dotnet6 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
dotnet6 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.127-0ubuntu1~23.10.1 in mantic amd64: universe/devel/optional/100% -> main
netstandard-targeting-pack-2.1 6.0.127-0ubuntu1~23.10.1 in mantic arm64: universe/devel/optional/100% -> main
Override [y|N]? y
25 publications overridden.

Changed in dotnet6 (Ubuntu Jammy):
status:	Fix Committed → Fix Released
Changed in dotnet6 (Ubuntu Mantic):
status:	Fix Committed → Fix Released
Changed in dotnet6 (Ubuntu Noble):
assignee:	Dominik Viererbe (dviererbe) → nobody

	Status	Importance	Assigned to
dotnet6 (Ubuntu)	Invalid	Undecided	Unassigned
Jammy	Fix Released	Undecided	Unassigned
Mantic	Fix Released	Undecided	Unassigned
Noble	Invalid	Undecided	Unassigned

Ubuntu
dotnet6 package

[MIR] dotnet6

Bug Description

Related branches

CVE References

Other bug subscribers

Remote bug watches

Changed in dotnet6 (Ubuntu):
assignee:	Ubuntu Security Team (ubuntu-security) → nobody

Changed in dotnet6 (Ubuntu):
status:	New → Incomplete
assignee:	nobody → Dominik Viererbe (dviererbe)

Ubuntudotnet6 package

[MIR] dotnet6

Bug Description

Related branches

CVE References

Other bug subscribers

Remote bug watches

Ubuntu
dotnet6 package