Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp651652ybe; Thu, 5 Sep 2019 03:53:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqxc5E56Qy53vZ5Vlx90JMgMjM1SDu7Eg2mYe6WZEcp8AdN3kXlm+/0l/BBCqBO9a16yYqrZ X-Received: by 2002:a65:6284:: with SMTP id f4mr2650080pgv.416.1567680806283; Thu, 05 Sep 2019 03:53:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567680806; cv=none; d=google.com; s=arc-20160816; b=vmXfu31sz4cciVJdyRz3WKFtLmTs+HAc7RSXLPZ3RLiuSpLXhE+byE93/cJBdirnsP RXq0VbWhbNQAPECmYsVZxpUvQAH2+0NfT5FYICEVepA8eZzsHiblw1JD+4t+nWzN44oi KO9e6n+OUEzq908aSV7kcIW9Qxa42aYVco3xuMNJYrh06//K/koro5aXiMT4DrkwNHPX mZynwasPT6Agp9eKS4f/dZSXagSZuYTLrLVgZ2DilPTiDWatR3tYnCTP2W+1ACk2ReN1 f78UtvKwbHCorm7TimYEG0E4v5ru7luS3iZFNAJy29ImvqvxDxKEX9JG8NMk19OcPuAw SrpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=Nf/a77KEmjaFsuAPj3FAUym6ojWYmBF/YMuIBQgblrE=; b=qNTQx+7ejtzCZLajoYd8cRdP3ZIlQWWDuTLkVBg4Q5De24svG2FCnQSB2BhV0v3Bjx 0ymipS0TEX47PFX93Jo+nWUQu4ba7r+GmfrN0pebdQXmnGk5otCz525c8vZV5Ql0jDl7 bZI+fAVfLV/Vqo0a7t5omQEKdEpXSpbM9RNtzbf2x3AD2XiGRT+0qd80eJczjrA3yBIS g1VUQaP6aQG+6l3Th6UQlN3+184QD2yZ8XqCv2l2cZwfJcrqhE5N8zwTRZIAaSvc2AbQ S7TbY37G4oa5J+Wrvakpiv0sEMVxuZjS/gy10bgi7oFTgstUSgj2GrH29kelP0TeXh2N /InA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="WcvE/VB7"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y8si1530622pgr.89.2019.09.05.03.53.10; Thu, 05 Sep 2019 03:53:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b="WcvE/VB7"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387843AbfIEKue (ORCPT + 99 others); Thu, 5 Sep 2019 06:50:34 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:35580 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731476AbfIEKud (ORCPT ); Thu, 5 Sep 2019 06:50:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Nf/a77KEmjaFsuAPj3FAUym6ojWYmBF/YMuIBQgblrE=; b=WcvE/VB7dxohDehAFdQG3Hqfj uiUdUZA9DRE3ujMDC3Z5krLdKvHxg/I3Ws3koV7ln2znwhJWL5++KuBywUUclVrDMZ1XXVVEtACWi G0n75tbkEfcUWKkpKm2dCkdau1YSITr/n153fsef0nOUgMyiF9X+Ck2RSYSiWtlgcGm/BscB4UGCB IMx8x5OS6JZBdnN3TQMBnHCvyZM5mJI9OgErJCNxz2TFqm+Q/orVALoNaRAD4oI2+brDSNJuKHw4E XRmznLwdo+zUW2QrSR9/K5pqKe60SA5jK3gUL1PZ+zgeC11EYHZMJBMK+H4F/9Tmp21BQBPpo9qBP beoLnuDqg==; Received: from 177.17.137.173.dynamic.adsl.gvt.net.br ([177.17.137.173] helo=coco.lan) by bombadil.infradead.org with esmtpsa (Exim 4.92 #3 (Red Hat Linux)) id 1i5pLU-0006Y8-VQ; Thu, 05 Sep 2019 10:50:33 +0000 Date: Thu, 5 Sep 2019 07:50:28 -0300 From: Mauro Carvalho Chehab To: Greg Kroah-Hartman Cc: Linux Media Mailing List , Mauro Carvalho Chehab , Joe Perches , linux-kernel@vger.kernel.org, Jonathan Corbet , Jessica Yu , Federico Vaga , Thomas Gleixner , linux-doc@vger.kernel.org Subject: Re: [PATCH] docs: license-rules.txt: cover SPDX headers on Python scripts Message-ID: <20190905075028.643f4b9d@coco.lan> In-Reply-To: <20190905092703.GA30899@kroah.com> References: <20190905055614.7958918b@coco.lan> <88e638eb959095ab6657d295f9f8c27169569bf2.1567675272.git.mchehab+samsung@kernel.org> <20190905092703.GA30899@kroah.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Thu, 5 Sep 2019 11:27:03 +0200 Greg Kroah-Hartman escreveu: > On Thu, Sep 05, 2019 at 06:23:13AM -0300, Mauro Carvalho Chehab wrote: > > The author of the license-rules.rst file wanted to be very restrict > > with regards to the location of the SPDX header. It says that > > the SPDX header "shall be added at the first possible line in > > a file which can contain a comment". Not happy with this already > > restrictive requiement, it goes further: > > > > "For the majority of files this is the first line, except for > > scripts", opening an exception to have the SPDX header at the > > second line, if the first line starts with "#!". > > > > Well, it turns that this is too restrictive for Python scripts, > > and may cause regressions if this would be enforced. > > > > As mentioned on: > > https://stackoverflow.com/questions/728891/correct-way-to-define-python-source-code-encoding > > > > Python's PEP-263 [1] dictates that an script that needs to default to > > UTF-8 encoding has to follow this rule: > > > > 'Python will default to ASCII as standard encoding if no other > > encoding hints are given. > > > > To define a source code encoding, a magic comment must be placed > > into the source files either as first or second line in the file' > > > > And: > > 'More precisely, the first or second line must match the following > > regular expression: > > > > ^[ \t\f]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+)' > > > > [1] https://www.python.org/dev/peps/pep-0263/ > > > > If a script has both "#!" and the charset encoding line, we can't place > > a SPDX tag without either violating license-rules.rst or breaking the > > script by making it crash with non-ASCII characters. > > > > So, add a sort notice saying that, for Python scripts, the SPDX > > header may be up to the third line, in order to cover the case > > where both "#!" and "# .*coding.*UTF-8" lines are found. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > Documentation/process/license-rules.rst | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst > > index 2ef44ada3f11..5d23e3498b1c 100644 > > --- a/Documentation/process/license-rules.rst > > +++ b/Documentation/process/license-rules.rst > > @@ -64,9 +64,12 @@ License identifier syntax > > possible line in a file which can contain a comment. For the majority > > of files this is the first line, except for scripts which require the > > '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX > > - identifier goes into the second line. > > + identifier goes into the second line\ [1]_. > > > > -| > > +.. [1] Please notice that Python scripts may also need an encoding rule > > + as defined on PEP-263, which should be defined either at the first > > + or the second line. So, for such scripts, the SPDX identifier may > > + go up to the third line. > > > > 2. Style: > > > > If you are going to do this, can you also fix up scripts/spdxcheck.py to > properly catch this, Hmm... it defaults to analyze the first 15 lines: ap.add_argument('-m', '--maxlines', type=int, default=15, help='Maximum number of lines to scan in a file. Default 15') So, I guess it won't require any changes. > as well as fixing up the location of the spdx tag > line in the file itself? Good point. I'll write a patch fixing the SPDX location at the three files where the coding location is at the wrong place. > > thanks, > > greg k-h Thanks, Mauro