On Wed, 2016-09-14 at 17:45 +0200, santiagorr@riseup.net wrote: > Hi, > > So sorry for this time to answer. > > El 26/07/16 a las 14:56, Luca Boccassi escribió: > > On Tue, 2016-07-19 at 17:08 +0200, santiagorr@riseup.net wrote: > > > Hi, > > > > > > El 06/07/16 a las 10:27, Luca Boccassi escribió: > > > > On Mon, 4 Jul 2016 13:57:33 +0200 Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote: > > > > > On Sun, Jul 3, 2016 at 8:52 PM, Santiago Ruano Rincón <santiagorr@riseup.net > > > > > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Apr 2016 21:34:11 +0100 Luca Boccassi > > > > > > <luca.boccassi@gmail.com> wrote: > > > > > > > On Wed, 30 Mar 2016 08:38:58 +0200 Christian Ehrhardt > > > > > > > <christian.ehrhardt@canonical.com> wrote: > > > > > > > > On Wed, Mar 30, 2016 at 7:41 AM, C.J. Collier > > > > > > > > <cjcollier@linuxfoundation.org > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt > > > > > > > > > <paelzer@gmail.com> > > > > > > > > > wrote: > > […] > > > > However, lintian is not happy, as you can see in the attached report. > > > Some of the points to highlight from it that, IMHO could block uploading > > > are: > > > > > > 1. W: libdpdk-librte-pmd-xenvirt1: package-name-doesnt-match-sonames librte-pmd-xenvirt1 and related: > > > Any reason to add the libdpdk- name prefix to the librte-* libraries? > > > Usually, the name of a binary library package follows its SONAME, and > > > thus just librte-* would be more accurate. > > > > Some time ago the libraries were renamed and no longer have the libdpdk- prefix: > > > > https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git;a=blob;f=debian/control;h=37a64437bf1d566082477923d91618c1b9016725;hb=refs/heads/deb_dpdk_16.07 > > Humm, I was following the master branch instead. Any reason to don't > merge this deb_dpdk_16.07 into master? > > I am starting to work over this branch now, so I will have to do part of > the job again. For the moment, the rest of the mail is a quick answer. We will soon have a 16.11 branch I think. We didn't discuss in details but I don't know if we'll be using the master branch again or just stay on the topic branches. > > > 2. Hardening: it seems that build flags need to be fixed. E.g: > > > W: libdpdk-librte-eal2: hardening-no-relro usr/lib/x86_64-linux-gnu/librte_eal.so.2 > > > > Some were fixed, but yes indeed there's a few more to deal with, will do as soon as I have time. But given the possible performance implications it might be good to consult with upstream. > > Indeed, seems to be fixed. Thanks! With the latest version as of today all the hardening and the other lintian errors are fixed, the manpages are what's missing but there's a patch upstream for that. > > > 3. I am not sure the licensing (and then debian/copyright) is not as > > > simple as a dual GPL-2/BSD for core stuff and GPL for kernel components, > > > as README states. I will check carefully this, since no accurate > > > debian/copyright, no upload possible. > > > > I'm pretty sure that's what upstream advertises and a quick run of licensecheck seems to confirm that, but if you find otherwise please do flag that both with us and upstream > > Actually, my wording was not accurate either, since README doesn't claim > *dual* licensing but different licenses for different components. BSD > (3-clause) for the core and GPLv2 for kernel-related. > > Anyway, licensecheck outputs files under other licenses. E.g.: > > […] > ./drivers/crypto/qat/qat_adf/icp_qat_fw.h: BSD (3 clause) GPL (v2) > ./drivers/crypto/qat/qat_adf/icp_qat_fw_la.h: BSD (3 clause) GPL (v2) > ./drivers/crypto/qat/qat_adf/adf_transport_access_macros.h: BSD (3 clause) GPL (v2) > ./drivers/crypto/qat/qat_adf/qat_algs_build_desc.c: BSD (3 clause) GPL (v2) > […] > ./lib/librte_compat/rte_compat.h: BSD (2 clause) > […] > > Attached you can find a patch for debian/copyright, that I think it's > accurate with the current source. FTR, it is based on (and thanks to): > > licensecheck --copyright -r `find * -type f` | \ > /usr/lib/cdbs/licensecheck2dep5 > debian/copyright.auto > > Also, AFAICS there are a couple of files in lib/librte_net/ that need > some cleaning by upstream. Thanks for the patch, I'll have a look and apply it! > > > 4. It would be great to have manpages for these binaries: > > > > > > W: dpdk: binary-without-manpage sbin/dpdk_nic_bind > > > W: dpdk: binary-without-manpage usr/bin/dpdk_proc_info > > > W: dpdk: binary-without-manpage usr/bin/testpmd > > > > Yes absolutely, patches are welcome :-) > > Unless somebody else beats me, I will try do them at some point. Christian has sent patches upstream a couple weeks back: http://dpdk.org/dev/patchwork/patch/15553/ Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part