<html><head></head><body><div>Hi David,</div><div><br></div><div>On Sat, 2022-01-22 at 23:26 +1100, David Bannon wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Thu, 2022-01-20 at 13:15 +1100, David Bannon wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Wed, 2022-01-19 at 20:36 +0100, Paul Gevers wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On 19-01-2022 02:58, David Bannon wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Abou, there has been some discussion about these lintian warning <br></div></blockquote></blockquote></blockquote><div><br></div><div><br></div><div>OK, here is a summary of a selected bunch of the lintian issues. Quite<br></div><div>a lot are definitely overrides, I am happy to start generating suitable<br></div><div>override files if you like Abou.<br></div></blockquote><div>Thanks for this analysis, it is a valuable help and I'm happy to accept your patches.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>--- Under Spelling ---<br></div><div><br></div><div>declatory should be declaratory - This is in a copywrite file, FPC<br></div><div>people feel they should not change it. Already has an override ?<br></div></blockquote><div>This was already fixed here:</div><div><a href="https://salsa.debian.org/pascal-team/fpc/-/commit/ada1fbc2bcf178f08292622fa507652d5b0f08d3">https://salsa.debian.org/pascal-team/fpc/-/commit/ada1fbc2bcf178f08292622fa507652d5b0f08d3</a></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>occured should be occurred - Have all been fixed except for 8<br></div><div>incidences in comments. I assume Lintian does not scan source code ?<br></div></blockquote><div>I'm not sûre, I think it scans everything .deb including *-src*.deb, so may hit comments.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>condtional - in a man page, appears to have been fixed already<br></div><div>ACount is a variable name, not a misspeling of Account, a widely used<br></div><div>syntex. override.<br></div></blockquote><div>Yes, traditional Pascal syntax to use AField for methods parameter to set Field class member.</div><div>Override</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>implicitely should be implicitly - appears in 16 comments but I could<br></div><div>not find, in main, instance that will make its way into a binary. So,<br></div><div>assume recently fixed.<br></div></blockquote><div>Here are they:</div><pre>fpcsrc/packages/fcl-passrc/src/pparser.pp|1069| FImplicitUses.Add('System'); // system always implicitely first.</pre><pre>fpcsrc/packages/os2units/src/wpstk.pp|660| { implicitely set, when pszName specifies drive }</pre><pre>fpcsrc/utils/pas2js/docs/translation.html|451| <li>Unit <i>System</i> is always loaded implicitely.</li></pre><pre>fpcsrc/compiler/aoptda.pas|78| { done implicitely by the constructor</pre><pre>fpcsrc/compiler/aoptobj.pas|1176| { this happens with registers which are loaded implicitely, outside the }</pre><pre>fpcsrc/compiler/ninl.pas|1650| { zero-based arrays (of char) can be implicitely converted to ansistring, but don't do</pre><pre>fpcsrc/compiler/pgenutil.pas|1153| { for partial specializations we implicitely declare the routine as</pre><pre>fpcsrc/compiler/pgenutil.pas|1204| { for partial specializations we implicitely declare any methods as having their</pre><pre>fpcsrc/compiler/pgenutil.pas|1756| { and the body is available already (which is implicitely the</pre><pre>fpcsrc/compiler/pmodules.pas|1819| as implicitely imported ones }</pre><pre>fpcsrc/compiler/msg/errore.msg|3615| package_n_implicit_unit_import=13005_N_Unit $1 is implicitely imported into package $2</pre><pre>fpcsrc/tests/webtbs/tw33563.pp|27| property T: Double read fT write fT nodefault; // stored implicitely True</pre><pre>fpcsrc/tests/webtbs/tw33563.pp|28| property U: Double read fU write fU; // stored implicitely True, default=0</pre><pre>fpcsrc/tests/webtbs/tw33563.pp|30| property Tn: Double read fTn write fTn nodefault; // stored implicitely True</pre><pre>fpcsrc/tests/webtbs/tw33563.pp|31| property Un: Double read fUn write fUn; // stored implicitely True, default=0</pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>"Allow to" should be "Allow one to" - really, I think Lintian is<br></div><div>pulling a long bow here! I have checked where these happen, only one<br></div><div>that would appear in a binary seems to be a help message from<br></div><div>compiler/utils/msgdif.pp:159 and is quite adequate English IMHO.<br></div><div>Override. <br></div></blockquote><div>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.</div><div>Override</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>entrys, SetTS, relocateable - are all variable names and will never be<br></div><div>shown to end users. Will not be fixed. Override.<br></div></blockquote><div>Override</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>install/man/man5/fpc.cfg.5 contains developpers - spelling mistake<br></div><div>Not fixed yet, but should be. I will deal with it.<br></div></blockquote><div>Thanks,</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>--- Other Things ---<br></div><div><br></div><div>hardening-no-pie a number of binaries in fp-utils not<br></div><div>hardened. Subject to some discussion still, may or may not be fixed,<br></div><div>concern about performance issues. Technically possible to fix,<br></div><div>downstream, in the mean time if you wish it to happen (but at expense<br></div><div>of performance, esp 32bit).<br></div></blockquote><div>Just a silly question. Do we need performance here?</div><div>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!</div><div>Now for this, we may have exactly the opposite, the programs will loose a few milliseconds, but it not a time critical one.</div><div>So is it better to care about security or about performance here?</div><div>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?</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>national-encoding - do not expect any progress upstream there, suggest<br></div><div>override and a downstream fix may compromise cross compilers build from<br></div><div>debian src.<br></div></blockquote><div>Override</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>COPYRIGHT file, I think it has been dealt with ? If not, I am happy to<br></div><div>do some editing. Am I right in thinking that Debian builds this file<br></div><div>from the various copyright statements in the source files ? Wow .....<br></div></blockquote><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>unusual-documentation-package-name : fp-docs debian would prefer fp-doc <br></div><div>apparently. I don't think so. I think this has to be an override, its<br></div><div>been like that for a long time and is quite unlikely to be changed<br></div><div>IMHO.<br></div></blockquote><div>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.</div><div>Let's keep it this one, no change no override until we decide.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div><br></div><div>fp-compiler-3.2.2: executable-in-usr-lib usr/lib/x86_64-linux-<br></div><div>gnu/fpc/3.2.2/samplecfg<br></div><div>Yep, its an executable sh script. But not unintended to be executed as<br></div><div>such, as filename indicates, its a sample, it gets copied to user's<br></div><div>home directory. I really cannot think of where else it should go.<br></div><div>Definitely not in libexe, its not intended to be executed directly. I<br></div><div>supose this means its also an override ?<br></div></blockquote><div>This can be used by user to build ~/.fpc.cfg. It was recently buggy due to missing patch, but now the patch was restored.</div><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div><br></div><div>repeated-path-segment packages<br></div><div>usr/share/fpcsrc/3.2.2/packages/fppkg/tests/packages/<br></div><div>Yes, its like that and its quite reasonable and unlikely to change.<br></div><div>Override.</div></blockquote><div>This wrong detection in Lintian. Let's override.<br class="Apple-interchange-newline">-- <br></div><pre style="caret-color: rgb(46, 52, 54); color: rgb(46, 52, 54); font-variant-caps: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">Cheers,
Abou Al Montacir</pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"></blockquote></body></html>