[Pkg-pascal-devel] Lintian errors and warnings on FPC
David Bannon
dbannon at internode.on.net
Tue Jan 25 06:14:54 GMT 2022
On Mon, 2022-01-24 at 21:02 +0100, Abou Al Montacir wrote:
> > --- Under Spelling ---
Abou, sorry, careless wording on my part. When I say "fixed" I mean
fixed upsteam in trunk. In an ideal world, those fixes will make it
into the next release. Most certainly not into the copy of fpc322 you
have nor will there be a further release of FPC322.
I guess I would rather see these things fixed once and for all.
> > 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?
Its a good question and ultimatly one that will be resolved in the
security mode but short term, thats another issue. As I mentioned,
there really is two seperate issues here, one is the inability to
harden PPC64el at all. The other is the way hardening is done with FPC.
I'd rather they addressed PPC64el now and considered the big changes
further down the track. But I suspect they feel the need to fix the
problem holistically, that would also cover the situation that now
applies to eg x86-64 and Arm too where hardening does not work with a
statically linked binary, you need to manually force it to be a dynamic
link first.
Your question ? Personally I see little benifit in hardening on a
single user, private system. But agree that its a very good thing on
what we generally call a server. We should be able to do it !
> > 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.
Should we be trying to push the copyright file back to the FPC devs ?
They have a far better knowledge of what needs to be added each time
and building it frm scratch at each release sounds like very hard work
?
Davo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20220125/0112dfca/attachment-0001.htm>
More information about the Pkg-pascal-devel
mailing list