Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

[Graham Inggs]

On 7 March 2018 at 20:47, Paul Gevers  wrote:
>>> This can be worked around by the following change in debian/rules:
>>>
>>> -export FPCDIR=/usr/lib/fpc/${FPCDIR}
>>> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default
>
> @Graham, have you verified this?

It worked for in a local build on amd64.

> On arm64 the situation if fully different. Clean doesn't work (which
> could be easily worked around in multiple ways). I.e. this should not be
> blocking for building on arm64.

arm64 is fixed in Ubuntu, patch in comment 23 of #803986
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803986#23

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

[Paul Gevers]

Hi

Additional note, I got the same error¹ on debomatic² while debugging the
FTBFS of lazarus on mips/mipsel. Interestingly enough the exact same
source build succeeded on the build infrastructure. So maybe something
flaky IS going on.

Paul

¹ find * -name Makefile.fpc -exec fpcmake -Tall -q '{}' ';'
Error: Target "linux", package "rtl" not found
...
²
http://debomatic-mips.debian.net/distribution#unstable/lazarus/1.8.2+dfsg-2/buildlog



signature.asc
Description: OpenPGP digital signature

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

[Paul Gevers]

Hi  all,

On 07-03-18 18:28, Michalis Kamburelis wrote:
> "2018-03-07 16:46 GMT+01:00 Graham Inggs :
>> On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk  wrote:
>>>
>>> This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
>>>
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html

Yes, but not for i386 and armhf. Weird.

>> This can be worked around by the following change in debian/rules:
>>
>> -export FPCDIR=/usr/lib/fpc/${FPCDIR}
>> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default

@Graham, have you verified this?

> It seems that transgui is using an older "fpcmake" system (depending
> on Makefile which is auto-generated based on "Makefile.fpc" contents).
> The auto-detection is in a different place then, although it is also
> overridden by $FPCDIR environment variable.

transgui is calling fpcmake in d/rules, so it is regenerating all the
Makefiles (which is good). The failure happens DURING the call to fpcmake.

On arm64 the situation if fully different. Clean doesn't work (which
could be easily worked around in multiple ways). I.e. this should not be
blocking for building on arm64.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

[Michalis Kamburelis]

"2018-03-07 16:46 GMT+01:00 Graham Inggs :
> On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk  wrote:
>>
>> This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
>>
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html
>
>
> This can be worked around by the following change in debian/rules:
>
> -export FPCDIR=/usr/lib/fpc/${FPCDIR}
> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default
>
> However, it was my understanding that this was supposed to be fixed in FPC,
> so forwarding to the Pascal list for comment.
>

The recent fix in the Debian package of FPC was for the FpMake build
system, http://wiki.freepascal.org/FPMake . It tries to auto-detect
the standard units location, but can be overridden by $FPCDIR
environment variable. The auto-detection was fixed in this case,
removing the need for $FPCDIR.

It seems that transgui is using an older "fpcmake" system (depending
on Makefile which is auto-generated based on "Makefile.fpc" contents).
The auto-detection is in a different place then, although it is also
overridden by $FPCDIR environment variable.

You can see how this works in case of transgui :

- This is the source file:
https://github.com/transmission-remote-gui/transgui/blob/master/Makefile.fpc
- And developer calls "fpcmake" to generate a Makefile like this:
https://github.com/transmission-remote-gui/transgui/blob/master/Makefile

Searching the generated Makefile, there is a line that tries to
auto-guess the FPC library location:
https://github.com/transmission-remote-gui/transgui/blob/master/Makefile#L226
. So possibly it can be fixed in FPC package in Debian too.

Regards,
Michalis

Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

[Paul Gevers]

Hi Graham,

On 07-03-18 16:46, Graham Inggs wrote:
> On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk  wrote:
>> This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html
>>
> 
> This can be worked around by the following change in debian/rules:
> 
> -export FPCDIR=/usr/lib/fpc/${FPCDIR}
> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default
> 
> However, it was my understanding that this was supposed to be fixed in
> FPC, so forwarding to the Pascal list for comment.

No, FPC would fix the default behavior. When FPCDIR is defined in
debian/rules, it must match. I wonder, does building work without
defining FPCDIR at all?

Paul




signature.asc
Description: OpenPGP digital signature