[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]



On Sat, Jun 02, 2018 at 03:24:07AM +0000, Lumin wrote:
> Please fix the aforementioned problems. Hopefully we'll have the last
> round of check next time. Thank you for working on this.
> 
> [1] http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog

Forgot to check the copyright ... The copyright looks incomplete. A
simple search on the source tree would reveal many non-Linaro copyright
holders:

  grep -ri copyright | grep -vi linaro | grep -i copyright

The package will be rejected by ftp-master if we don't fix the
copyright.

When checking odp-dpdk, one more problem was found:

  root@b69fed1c16e0 ~/odp-dpdk-1.19.0.0# update-alternatives --config libodp-linux.so-x86_64-linux-gnu
  There are 2 choices for the alternative libodp-linux.so-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libodp-linux.so).
  
    Selection    Path                                                   Priority   Status
  ------------------------------------------------------------
  * 0            /usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so   40        auto mode
    1            /usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so      40        manual mode
    2            /usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so   40        manual mode


  * 0            /usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119      60        auto mode
    1            /usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119      60        manual mode
    2            /usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so.119   40        manual mode

Taking BLAS as an example, the generic and slow libblas3 provides
libblas.so.3 symlink with a priority of 10. Faster implementations
provides the same symlink with higher priorities, e.g. 40 for openblas.

Maybe you want to adjust the priority values in those postinst scripts?
The exact value is up to you, as long as it helps to tell the difference
among different implementations.


Reply to: