This bug was fixed in the package linux - 5.13.0-14.14

---------------
linux (5.13.0-14.14) impish; urgency=medium

  * impish/linux: 5.13.0-14.14 -proposed tracker (LP: #1938565)

  * Miscellaneous Ubuntu changes
    - SAUCE: Revert "UBUNTU: SAUCE: random: Make getrandom() ready earlier"
    - SAUCE: random: properly make getrandom() ready earlier

  * Miscellaneous upstream changes
    - seq_buf: Fix overflow in seq_buf_putmem_hex()
    - bpf: Fix integer overflow in argument calculation for bpf_map_area_alloc
    - ext4: cleanup in-core orphan list if ext4_truncate() failed to get a
      transaction handle
    - ext4: fix kernel infoleak via ext4_extent_header
    - ext4: fix overflow in ext4_iomap_alloc()
    - ext4: return error code when ext4_fill_flex_info() fails
    - ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit
    - ext4: remove check for zero nr_to_scan in ext4_es_scan()
    - ext4: fix avefreec in find_group_orlov
    - ext4: use ext4_grp_locked_error in mb_find_extent

 -- Andrea Righi <andrea.ri...@canonical.com>  Mon, 02 Aug 2021 14:23:08
+0200

** Changed in: linux (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1930713

Title:
  Kernel package builds running out of space on builders

Status in linux package in Ubuntu:
  Fix Released

Bug description:
  [Impact]

  Our kernel builds are sometimes running out of space on the builders
  when we are building multiple flavours. We've seen this with
  focal:linux-hwe for amd64 and impish:linux-unstable for arm64. This is
  in part because package builds are broken up into a build phase (which
  builds the source tree) and a binary phase (which creates the debs).
  These are run separately, with the binary phase run under fakeroot to
  get correct ownership for files in the package archives, requiring
  builds for multiple flavours to be present on disk at the same time.

  We have implemented various fixes for this problem over time, and
  explored many others which have not worked out. But the size of the
  kernel keeps increasing, and now it seems our only remaining option is
  to build one flavour and install its files, then remove the flavour
  build files before building the next flavour. This means that files
  are installed for later package builds during the build phase,
  requiring that ownership of these files be fixed up during the binary
  phase to get correct ownership in the package archives.

  [Test Plan]

  Build a full set of kernel packages (inlcuding linux-source and dbgsym
  packages, which are generally excluded when not building on builders)
  at a given tag, then build another set from the same tag with the
  packaging changes applied. Compare the resulting debs to confirm that
  the set of produced packages is the same, the file lists within the
  packages are the same, and that file ownership and permissions between
  the packages is identical.

  I have done this testing with the proposed patches with a recent
  linux-unstable tag and found no differences with and without the
  changes.

  [Where problems could occur]

  Incorrect ownership of files in the package archives is the main
  concern. I have tested for this, but it is possible that future
  upstream changes could unexpectedly result in files with incorrect
  ownership.

  Reordering of the package build sequence could result in missing files
  which should be in packages, or files present in packages which should
  be excluded. Some instances of this occurred while developing these
  changes and have been fixed. Future updates to upstream or to the
  packaging could cause additional issues.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1930713/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to