On Tue, 2016-07-19 at 17:08 +0200, santiag...@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.ehrha...@canonical.com> wrote: > > > On Sun, Jul 3, 2016 at 8:52 PM, Santiago Ruano Rincón > > > <santiag...@riseup.net > > > > wrote: > > > > > > > Hi all, > > > > > > > > On Thu, 14 Apr 2016 21:34:11 +0100 Luca Boccassi > > > > <luca.bocca...@gmail.com> wrote: > > > > > On Wed, 30 Mar 2016 08:38:58 +0200 Christian Ehrhardt > > > > > <christian.ehrha...@canonical.com> wrote: > > > > > > On Wed, Mar 30, 2016 at 7:41 AM, C.J. Collier > > > > > > <cjcoll...@linuxfoundation.org > > > > > > > wrote: > > > > > > > > > > > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt > > > > > > > <pael...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > [...] > > > > Hi Santiago, > > > so far Luca was planned to maintain it, but I'd assume he is no objecting > > > to a co-maintainer. > > > Especially if the co-maintainer can help with the initial upload. > > > It might be good to know about a lot of details in advance out of the > > > scope > > > of actually uploading it. > > > We would be happy if you join us in our work even before the initial > > > upload > > > takes place. > > > > No objections at all, more help is always welcome :-) > > Thanks :) > > The current dpdk from the fi.io git repo builds ok on a stable > environment and I am able to make a basic use. Thanks for your work! > > 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 > 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. > 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 > 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 :-) > What do you think? > > Cheers, > > Santiago Thanks for the feedback! Keep it coming :-) Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
