DPDK patches and discussions
 help / color / mirror / Atom feed
From: Luca Boccassi <bluca@debian.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Kevin Traynor <ktraynor@redhat.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] Fix various typos found by Lintian
Date: Tue, 16 Jun 2020 15:25:25 +0100	[thread overview]
Message-ID: <9ec158c4bf26f72505521be34821785ed2521905.camel@debian.org> (raw)
In-Reply-To: <6245559.rmFrDPG0Ap@thomas>

On Tue, 2020-06-16 at 14:44 +0200, Thomas Monjalon wrote:
> 26/04/2020 11:49, Luca Boccassi:
> > On Sat, 2020-04-25 at 19:47 +0200, Thomas Monjalon wrote:
> > > 04/03/2020 16:28, Luca Boccassi:
> > > > On Wed, 2020-03-04 at 14:34 +0000, Kevin Traynor wrote:
> > > > > On 29/02/2020 16:37, luca.boccassi@gmail.com  wrote:
> > > > > > Debian's linter is getting more and more annoy^^smart and now
> > > > > > parses binaries
> > > > > > for typos too - CC stable to get it off my back in the next
> > > > > > release
> > > > > 
> > > > > Minor: Probably linter is better trained in the Queen's English
> > > > > than
> > > > > me
> > > > > or it could be personal preference, but 'one' seems to be
> > > > > referring
> > > > > to
> > > > > the user and it reads a bit strange for me. e.g.
> > > > > 
> > > > > "Slave %d capabilities doesn't allow one to allocate additional
> > > > > queues"
> > > > > "hardware specifications that allow one to handle virtual memory"
> > > > > "Do not allow one to send packet if the maximum DMA.."
> > > > > 
> > > > > as opposed to
> > > > > 
> > > > > "Slave %d capabilities don't allow allocation of additional
> > > > > queues"
> > > > > "hardware specifications that allow handling of virtual memory"
> > > > > "Do not allow sending of a packet if the maximum DMA.."
> > > > 
> > > > You might be right - but the intent here is not to be correct, it's
> > > > to
> > > > get the linter to leave me alone :-)
> > > 
> > > I agree with Kevin that the wording "allow one to make" is strange.
> > > Would lintian leave you alone with "allow making"?
> > > 
> > > Anyway the "allow to" sentences are not typos.
> > > They could be reworded in a separate patch.
> > > 
> > > Patch partly applied, except the "allow one to" changes, thanks.
> > 
> > It probably would work - will check in the next cycle.
> 
> What are the news from Lintian?

Better, but still a bit angry at me:

 I: librte-pmd-bond20.0: spelling-error-in-binary usr/lib/x86_64-linux-
gnu/dpdk/pmds-20.0/librte_pmd_bond.so.20.0 "allow to" "allow one to"
 I: librte-pmd-hns3-20.0: spelling-error-in-binary usr/lib/x86_64-
linux-gnu/dpdk/pmds-20.0/librte_pmd_hns3.so.20.0 does't doesn't
 I: librte-pmd-hns3-20.0: spelling-error-in-binary usr/lib/x86_64-
linux-gnu/dpdk/pmds-20.0/librte_pmd_hns3.so.20.0 setted set
 I: librte-pmd-i40e20.0: spelling-error-in-binary usr/lib/x86_64-linux-
gnu/dpdk/pmds-20.0/librte_pmd_i40e.so.20.0 reseting resetting
 I: librte-pmd-ixgbe20.0: spelling-error-in-binary usr/lib/x86_64-
linux-gnu/dpdk/pmds-20.0/librte_pmd_ixgbe.so.20.0 sempahore semaphore
 I: librte-pmd-qede20.0: spelling-error-in-binary usr/lib/x86_64-linux-
gnu/dpdk/pmds-20.0/librte_pmd_qede.so.20.0 acces access
 I: librte-pmd-qede20.0: spelling-error-in-binary usr/lib/x86_64-linux-
gnu/dpdk/pmds-20.0/librte_pmd_qede.so.20.0 erorr error
 I: librte-pmd-sfc20.0: spelling-error-in-binary usr/lib/x86_64-linux-
gnu/dpdk/pmds-20.0/librte_pmd_sfc.so.20.0 threashold threshold
 I: librte-pmd-virtio20.0: spelling-error-in-binary usr/lib/x86_64-
linux-gnu/dpdk/pmds-20.0/librte_pmd_virtio.so.20.0 does't doesn't

      reply	other threads:[~2020-06-16 14:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-29 16:37 luca.boccassi
2020-03-04 14:34 ` Kevin Traynor
2020-03-04 15:28   ` Luca Boccassi
2020-04-25 17:47     ` Thomas Monjalon
2020-04-26  9:49       ` Luca Boccassi
2020-06-16 12:44         ` Thomas Monjalon
2020-06-16 14:25           ` Luca Boccassi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9ec158c4bf26f72505521be34821785ed2521905.camel@debian.org \
    --to=bluca@debian.org \
    --cc=dev@dpdk.org \
    --cc=ktraynor@redhat.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).