[Pkg-pascal-devel] Lintian errors and warnings on FPC

[Abou Al Montacir]

Hi David,

On Sat, 2022-01-22 at 23:26 +1100, David Bannon wrote:
> On Thu, 2022-01-20 at 13:15 +1100, David Bannon wrote:
> > On Wed, 2022-01-19 at 20:36 +0100, Paul Gevers wrote:
> > > On 19-01-2022 02:58, David Bannon wrote:
> > > > Abou, there has been some discussion about these lintian warning 
> 
> 
> OK, here is a summary of a selected bunch of the lintian issues.  Quite
> a lot are definitely overrides, I am happy to start generating suitable
> override files if you like Abou.
Thanks for this analysis, it is a valuable help and I'm happy to accept your
patches.
> 
> --- Under Spelling ---
> 
> declatory  should be declaratory - This is in a copywrite file, FPC
> people feel they should not change it. Already has an override ?
This was already fixed here:
https://salsa.debian.org/pascal-team/fpc/-/commit/ada1fbc2bcf178f08292622fa507652d5b0f08d3
> 
> occured should be occurred - Have all been fixed except for 8
> incidences in comments. I assume Lintian does not scan source code ?
I'm not sûre, I think it scans everything .deb including *-src*.deb, so may hit
comments.
> 
> condtional - in a man page, appears to have been fixed already
> ACount is a variable name, not a misspeling of Account, a widely used
> syntex. override.
Yes, traditional Pascal syntax to use AField for methods parameter to set Field
class member.
Override
> 
> implicitely should be implicitly - appears in 16 comments but I could
> not find, in main, instance that will make its way into a binary. So,
> assume recently fixed.
Here are they:
fpcsrc/packages/fcl-passrc/src/pparser.pp|1069| FImplicitUses.Add('System'); // system always implicitely first.
fpcsrc/packages/os2units/src/wpstk.pp|660| { implicitely set, when pszName specifies drive  }
fpcsrc/utils/pas2js/docs/translation.html|451| <li>Unit <i>System</i> is always loaded implicitely.</li>
fpcsrc/compiler/aoptda.pas|78| { done implicitely by the constructor
fpcsrc/compiler/aoptobj.pas|1176| { this happens with registers which are loaded implicitely, outside the }
fpcsrc/compiler/ninl.pas|1650| { zero-based arrays (of char) can be implicitely converted to ansistring, but don't do
fpcsrc/compiler/pgenutil.pas|1153| { for partial specializations we implicitely declare the routine as
fpcsrc/compiler/pgenutil.pas|1204| { for partial specializations we implicitely declare any methods as having their
fpcsrc/compiler/pgenutil.pas|1756| { and the body is available already (which is implicitely the
fpcsrc/compiler/pmodules.pas|1819| as implicitely imported ones }
fpcsrc/compiler/msg/errore.msg|3615| package_n_implicit_unit_import=13005_N_Unit $1 is implicitely imported into package $2
fpcsrc/tests/webtbs/tw33563.pp|27| property T: Double read fT write fT nodefault;    // stored implicitely True
fpcsrc/tests/webtbs/tw33563.pp|28| property U: Double read fU write fU;              // stored implicitely True, default=0
fpcsrc/tests/webtbs/tw33563.pp|30| property Tn: Double read fTn write fTn nodefault; // stored implicitely True
fpcsrc/tests/webtbs/tw33563.pp|31| property Un: Double read fUn write fUn;           // stored implicitely True, default=0
> 
> "Allow to" should be  "Allow one to" - really, I think Lintian is
> pulling a long bow here!  I have checked where these happen, only one
> that would appear in a binary seems to be a help message from
> compiler/utils/msgdif.pp:159 and is quite adequate English IMHO.
> Override. 
I'm not native English speaker, so can't say whether it is acceptable or not,
but I feel like this is a bit extremist, as most people I know use allow to.
Override
> 
> entrys, SetTS, relocateable - are all variable names and will never be
> shown to end users. Will not be fixed. Override.
Override
> 
> install/man/man5/fpc.cfg.5 contains developpers - spelling mistake
> Not fixed yet, but should be. I will deal with it.
Thanks,
> 
> --- Other Things ---
> 
> hardening-no-pie  a number of binaries in fp-utils not
> hardened.  Subject to some discussion still, may or may not be fixed,
> concern about performance issues. Technically possible to fix,
> downstream, in the mean time if you wish it to happen (but at expense
> of performance, esp 32bit).
Just a silly question. Do we need performance here?
I saw many people optimizing code that none cares about it. ending to gain 99%
of execution time of a routing which total time used to be 0.1% of total
execution time before optimization. Just to say they lost their time!
Now for this, we may have exactly the opposite, the programs will loose a few
milliseconds, but it not a time critical one.
So is it better to care about security or about performance here?
Of course, if the security issue is really absent, we may want to avoid changes,
 but can we ensure one day our argument does not go and then we end with an
overridden security bug?
> 
> national-encoding - do not expect any progress upstream there, suggest
> override and a downstream fix may compromise cross compilers build from
> debian src.
Override
> 
> COPYRIGHT file, I think it has been dealt with ?  If not, I am happy to
> do some editing.  Am I right in thinking that Debian builds this file
> from the various copyright statements in the source files ? Wow .....
It is build manually if I'm right. Anyway, I already plan to rework the gbp
import-orig stuff to make it use standard tools (like I did for Lazarus) and
will need to touch this file. I can care about it. I already integrated Paul's
patches.
> 
> unusual-documentation-package-name : fp-docs debian would prefer fp-doc 
> apparently. I don't think so.  I think this has to be an override, its
> been like that for a long time and is quite unlikely to be changed
> IMHO.
I think Lintian is right here, but this will need to go though NEW queue. Maybe
we can handle this when importing the 3.2.4, that may come soon.
Let's keep it this one, no change no override until we decide.
> 
> 
> fp-compiler-3.2.2: executable-in-usr-lib usr/lib/x86_64-linux-
> gnu/fpc/3.2.2/samplecfg
> Yep, its an executable sh script. But not unintended to be executed as
> such, as filename indicates, its a sample, it gets copied to user's
> home directory.  I really cannot think of where else it should go.
> Definitely not in libexe, its not intended to be executed directly.  I
> supose this means its also an override ?
This can be used by user to build ~/.fpc.cfg. It was recently buggy due to
missing patch, but now the patch was restored.
You can keep it until we decide where to move it, but the problem is that the
name is not so explicit, so putting it somewhere else will confuse people.
> 
> 
> repeated-path-segment packages
> usr/share/fpcsrc/3.2.2/packages/fppkg/tests/packages/
> Yes, its like that and its quite reasonable and unlikely to change.
> Override.
This wrong detection in Lintian. Let's override.
-- 
Cheers,
Abou Al Montacir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20220124/2b7920b1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20220124/2b7920b1/attachment.sig>