[Bug 2004516] Re: [MIR] libyuv (transitive dependency of libheif)

[Christian Ehrhardt ]

Slight change here - this isn't needed for libaom3.

Due to the good use of non-embedded libs we now have correct dependency tracking.
That shows that only aom-tools would needed it, which isn't pulled in from libheif.

We could promote it, but if you want that you'd need to seed aom-tools
(if it is serving a good purpose) in one of the -supported seeds I
guess.

A bit more detail in
https://bugs.launchpad.net/ubuntu/+source/libheif/+bug/1827442/comments/55

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to libyuv in Ubuntu.
https://bugs.launchpad.net/bugs/2004516

Title:
  [MIR] libyuv (transitive dependency of libheif)

Status in libyuv package in Ubuntu:
  Fix Committed

Bug description:
  [Availability]

  The package libyuv is already in Ubuntu universe.
  The package libyuv build for the architectures it is designed to work on.
  It currently builds and works for architectures:
  amd64 arm64 armhf i386 ppc64el riscv64 s390x

  Link to package https://launchpad.net/ubuntu/+source/libyuv

  [Rationale]

  - The package libyuv will not generally be useful for a large part of
    our user base, but is important/helpful still because it provides color
    format conversion and scaling which is important for video processing
  - The package libyuv is a transitive dependency of package libheif that
    we intend to support
  - It would be great and useful to community/processes to have the
    package libyuv in Ubuntu main, but there is no definitive deadline.

  [Security]

  - No CVEs/security issues in this software in the past
  - no executables in `/sbin` and `/usr/sbin`
  - Package does not install services, timers or recurring jobs
  - Packages does not open privileged ports (ports < 1024)
  - Packages does contain extensions to security-sensitive software:
    the package colorspace conversion library which processes untrusted input

  [Quality assurance - function/usage]

  - The package works well right after install

  [Quality assurance - maintenance]

  - The package is maintained well in Debian/Ubuntu and has not too many
    and long term critical bugs open
    - Ubuntu https://bugs.launchpad.net/ubuntu/+source/libyuv/+bug
    - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libyuv
  - The package has no important open bugs.
    Note: patches need to be refreshed.
  - The package does not deal with exotic hardware we cannot support

  [Quality assurance - testing]

  - The package runs a test suite on build time, if it fails
    it makes the build fail, link to build log:
    https://launchpadlibrarian.net/625029537/buildlog_ubuntu-kinetic-amd64.libyuv_0.0~git20220809.9b17af9-1ubuntu2_BUILDING.txt.gz
    Note: unit tests are disabled for architectures:
    arm64 armel s390x powerpc ppc64 sparc64
  - The package does not run an autopkgtest because it is not implemented

  [Quality assurance - packaging]

  - debian/watch is present and works
  - debian/control does not define a correct Maintainer field
  - This package does not yield massive lintian Warnings, Errors
  - Please link to a recent build log of the package
    https://launchpadlibrarian.net/625029537/buildlog_ubuntu-kinetic-amd64.libyuv_0.0~git20220809.9b17af9-1ubuntu2_BUILDING.txt.gz
  - Please attach the full output you have got from
    `lintian --pedantic` as an extra post to this bug.
  - Lintian overrides are not present
  - This package does not rely on obsolete or about to be demoted packages.
  - This package has no python2 or GTK2 dependencies
  - The package will not be installed by default
  - Packaging and build is easy, link to d/rules
    https://git.launchpad.net/ubuntu/+source/libyuv/tree/debian/rules

  [UI standards]

  - Application is not end-user facing (does not need translation)
  - End-user applications without desktop file, not needed because
    it does not provide any GUI

  [Dependencies]

  - No further depends or recommends dependencies that are not yet in
  main

  [Standards compliance]

  - This package correctly follows FHS and Debian Policy

  [Maintenance/Owner]

  - Owning Team will be Foundations Team
  - Team is not yet, but will subscribe to the package before promotion
  - This does not use static builds
  - This does not use vendored code
  - This package is not rust based
  - The package successfully built during the most recent test rebuild
    Note: Build on lunar takes extremely long time compiling
    unit_test/convert_test.cc.
    https://launchpadlibrarian.net/640219928/buildlog_ubuntu-lunar-amd64.libyuv_0.0~git20220809.9b17af9-1ubuntu2_BUILDING.txt.gz
    Is it a known GCC issue?
      [Thread debugging using libthread_db enabled]
      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
      0x0000000000917faf in bitmap_set_bit(bitmap_head*, int) ()
      (gdb) where
      #0  0x0000000000917faf in bitmap_set_bit(bitmap_head*, int) ()
      #1  0x0000000000f62ed2 in ?? ()
      #2  0x0000000000f636d1 in compute_may_aliases() ()
      #3  0x0000000000cc0fad in ?? ()
      #4  0x0000000000cc156f in ?? ()
      #5  0x0000000000cc45f7 in execute_one_pass(opt_pass*) ()
      #6  0x0000000000cc4af0 in ?? ()
      #7  0x0000000000cc4b02 in ?? ()
      #8  0x0000000000cc4b2d in execute_pass_list(function*, opt_pass*) ()
      #9  0x0000000000984e68 in cgraph_node::expand() ()
      #10 0x0000000000986397 in ?? ()
      #11 0x00000000009888ac in symbol_table::finalize_compilation_unit() ()
      #12 0x0000000000d92060 in ?? ()
      #13 0x00000000006a48fe in toplev::main(int, char**) ()
      #14 0x00000000006a5fef in main ()

  [Background information]

  The Package description explains the package well
  Upstream Name is libyuv
  Link to upstream project https://chromium.googlesource.com/libyuv/libyuv

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