From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C3953A04A3; Tue, 16 Jun 2020 16:25:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 072001BF86; Tue, 16 Jun 2020 16:25:28 +0200 (CEST) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id EC1B81BF7D for ; Tue, 16 Jun 2020 16:25:26 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id l17so3090847wmj.0 for ; Tue, 16 Jun 2020 07:25:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=qiJUp95Ha8+0a3q85UGEgxvkkeASYoxyM1PKn9NPgOQ=; b=bIQhkrTXaVB8ABuDkCLuvJvJ6bMi6yBYD7g7oS7OGmW4rj9XLsjSljGxI6HknBWTjx LhzhDuj7Ilf/3E//SUhpTgfhXPLdrNQbfCFktyhtJBxKVND5eexUuBtH03SfLvOXDxYM R1wj16SdG7nKA33QcowN2RgQvZr8rb55qVj+2SnN4AWXatM4A77PEvmShDUTrJ7q4BDC 9urkbSTt7xRD2ZpWSc3gB38LRuNVzAI3S8bnl5gtYx4XP9UZYWdzbBi1D/lTd//GNvtK 55Rd61cuZiLVjfLFqdWamrwPSGNb2kGQnW3JitP0VjCUdIa4wpAyXCz7KWnS1Zmq0OK3 E81g== X-Gm-Message-State: AOAM5329OdLiJFrY79pfMkKjEHSXVo9pGD+i9LDy7CL16NjfgJW9cqa1 ZiVlZ0N3qBRFQteEqPusj4WXoGrjUfZhKg== X-Google-Smtp-Source: ABdhPJwmkIOp41YJfxJ+zICkrzeAQcYPyhbMQ5nsYSxj+xN5VCw3fwfxfvyB61+IIKMfhVUy/6lZEQ== X-Received: by 2002:a7b:c1d4:: with SMTP id a20mr3381132wmj.153.1592317526535; Tue, 16 Jun 2020 07:25:26 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id g3sm33010144wrb.46.2020.06.16.07.25.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2020 07:25:25 -0700 (PDT) Message-ID: <9ec158c4bf26f72505521be34821785ed2521905.camel@debian.org> From: Luca Boccassi To: Thomas Monjalon Cc: Kevin Traynor , dev@dpdk.org Date: Tue, 16 Jun 2020 15:25:25 +0100 In-Reply-To: <6245559.rmFrDPG0Ap@thomas> References: <20200229163706.12741-1-luca.boccassi@gmail.com> <4740923.upeRZZJTqa@thomas> <6245559.rmFrDPG0Ap@thomas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] Fix various typos found by Lintian X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > > >=20 > > > > > 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. > > > > >=20 > > > > > "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.." > > > > >=20 > > > > > as opposed to > > > > >=20 > > > > > "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.." > > > >=20 > > > > You might be right - but the intent here is not to be correct, it's > > > > to > > > > get the linter to leave me alone :-) > > >=20 > > > I agree with Kevin that the wording "allow one to make" is strange. > > > Would lintian leave you alone with "allow making"? > > >=20 > > > Anyway the "allow to" sentences are not typos. > > > They could be reworded in a separate patch. > > >=20 > > > Patch partly applied, except the "allow one to" changes, thanks. > >=20 > > It probably would work - will check in the next cycle. >=20 > 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