From noreply at release.debian.org Wed Jan 17 04:39:20 2018 From: noreply at release.debian.org (Debian testing watch) Date: Wed, 17 Jan 2018 04:39:20 +0000 Subject: [Pkg-pascal-devel] fpc 3.0.4+dfsg-13 MIGRATED to testing Message-ID: FYI: The status of the fpc source package in Debian's testing distribution has changed. Previous version: 3.0.4+dfsg-11 Current version: 3.0.4+dfsg-13 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. From service at tnt.com Wed Jan 17 05:13:35 2018 From: service at tnt.com (TNT EXPRESS) Date: Tue, 16 Jan 2018 21:13:35 -0800 Subject: [Pkg-pascal-devel] TNT EXPRESS TRACKING - COURIER SERVICE Message-ID:

-------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 263303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DHL Courier Service.ace Type: application/octet-stream Size: 381591 bytes Desc: not available URL: From bunk at debian.org Thu Jan 18 04:15:55 2018 From: bunk at debian.org (Adrian Bunk) Date: Thu, 18 Jan 2018 06:15:55 +0200 Subject: [Pkg-pascal-devel] Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 Message-ID: <151624895548.1797.14154855774203524545.reportbug@localhost> Source: castle-game-engine Version: 6.2+dfsg1-1 Severity: serious https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/castle-game-engine.html ... --- Building dh_testdir # Build the real engine /usr/bin/make all make[1]: Entering directory '/build/1st/castle-game-engine-6.2+dfsg1' /usr/bin/make --no-print-directory build-using-fpmake fpc fpmake.pp Free Pascal Compiler version 3.0.4+dfsg-13 [2018/01/12] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling fpmake.pp Linking fpmake /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T? 351 lines compiled, 0.4 sec Running fpmake. If this fails saying that "rtl" is not found, remember to set FPCDIR environment variable, see http://wiki.freepascal.org/FPMake . if [ '(' -n "/usr/lib/fpc/3.0.4" ')' -a \ '(' 3.0.4 '!=' '2.6.4' ')' -a \ '(' 3.0.4 '!=' '2.6.2' ')' ]; then \ ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" -v -o -Ur; \ else \ ./fpmake -v -o -Ur; \ fi The installer encountered the following error: Could not find unit directory for dependency package "rtl" Makefile:60: recipe for target 'build-using-fpmake' failed make[2]: *** [build-using-fpmake] Error 1 From michalis.kambi at gmail.com Thu Jan 18 05:43:45 2018 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Thu, 18 Jan 2018 06:43:45 +0100 Subject: [Pkg-pascal-devel] Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 References: <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: The problem is caused by the different directories used by new FPC 3.0.4 packages (compared to previous versions of FPC in Debian). Doing ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" doesn't work, since /usr/lib/fpc/3.0.4 does not exist. This works: ./fpmake --globalunitdir="/usr/lib/x86_64-linux-gnu/fpc/3.0.4" To fix this, I suggest to - Change / define the $FPCDIR variable inside Debian build scripts, to point to the new correct directory. - Or create a symlink /usr/lib/fpc/3.0.4 -> /usr/lib/x86_64-linux-gnu/fpc/3.0.4 . Regards, Michalis From abou.almontacir at sfr.fr Thu Jan 18 13:44:34 2018 From: abou.almontacir at sfr.fr (Abou Al Montacir) Date: Thu, 18 Jan 2018 14:44:34 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: References: <151624895548.1797.14154855774203524545.reportbug@localhost> <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: <1516283074.26470.2.camel@sfr.fr> Hi Michalis, On Thu, 2018-01-18 at 06:43 +0100, Michalis Kamburelis wrote: > The problem is caused by the different directories used by new FPC > 3.0.4 packages (compared to previous versions of FPC in Debian). I must admit that I was expecting many packages to break as the change is too big.But I assume this is worth the pain as now we can install multiple architecture units on the same host. > Doing > > ? ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do we need to explicitly pass this? > doesn't work, since /usr/lib/fpc/3.0.4 does not exist. This works: > > ? ./fpmake --globalunitdir="/usr/lib/x86_64-linux-gnu/fpc/3.0.4" I would use DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH) > To fix this, I suggest to > > - Change / define the $FPCDIR variable inside Debian build scripts, to > point to the new correct directory. I would try to avoid this if possible but indeed seems correct solution > - Or create a symlink /usr/lib/fpc/3.0.4 -> > /usr/lib/x86_64-linux-gnu/fpc/3.0.4 . This brings us back to pre-MA epoch. Let's avoid it. Also not possible in the Debian auto-builder daemon. --? Cheers, Abou Al Montacir -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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: From elbrus at debian.org Thu Jan 18 18:36:41 2018 From: elbrus at debian.org (Paul Gevers) Date: Thu, 18 Jan 2018 19:36:41 +0100 Subject: [Pkg-pascal-devel] Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: <1516283074.26470.2.camel@sfr.fr> References: <151624895548.1797.14154855774203524545.reportbug@localhost> <151624895548.1797.14154855774203524545.reportbug@localhost> <1516283074.26470.2.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: <73d85d5c-7f17-a6c7-d061-72f66d62b1a2@debian.org> clone 887575 -1 assign -1 src:fpc retitle -1 fpc MA setup breaks some reverse dependency builds found -1 3.0.4+dfsg-13 block 887575 by -1 thanks Hi On 18-01-18 14:44, Abou Al Montacir wrote: > On Thu, 2018-01-18 at 06:43 +0100, Michalis Kamburelis wrote: >> The problem is caused by the different directories used by new FPC >> 3.0.4 packages (compared to previous versions of FPC in Debian). > I must admit that I was expecting many packages to break as the change > is too big. > But I assume this is worth the pain as now we can install multiple > architecture units on the same host. But I think this must be fixed in fpc (therefore the clone of the bug), not in all the packages that build using it. >> Doing >> >> ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" > Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do > we need to explicitly pass this? >> doesn't work, since /usr/lib/fpc/3.0.4 does not exist. This works: >> >> ./fpmake --globalunitdir="/usr/lib/x86_64-linux-gnu/fpc/3.0.4" > I would use > > DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH) So, /etc/fpc.cfg should be fixed, no? Can that be done in a MA manner? If not, I consider the whole fpc/MA design broken. >> To fix this, I suggest to >> >> - Change / define the $FPCDIR variable inside Debian build scripts, to >> point to the new correct directory. > I would try to avoid this if possible but indeed seems correct solution I disagree. I think a solution where every package needs to define this is wrong. >> - Or create a symlink /usr/lib/fpc/3.0.4 -> >> /usr/lib/x86_64-linux-gnu/fpc/3.0.4 . > This brings us back to pre-MA epoch. Let's avoid it. Also not possible > in the Debian auto-builder daemon. The first sentence is what I also thought, but what do you mean by the last? Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From owner at bugs.debian.org Thu Jan 18 18:39:15 2018 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Thu, 18 Jan 2018 18:39:15 +0000 Subject: [Pkg-pascal-devel] Processed (with 1 error): Re: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 References: <73d85d5c-7f17-a6c7-d061-72f66d62b1a2@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > clone 887575 -1 Bug #887575 [src:castle-game-engine] castle-game-engine FTBFS with fpc 3.0.4 Bug 887575 cloned as bug 887652 > assign -1 src:fpc Unknown command or malformed arguments to command. > retitle -1 fpc MA setup breaks some reverse dependency builds Bug #887652 [src:castle-game-engine] castle-game-engine FTBFS with fpc 3.0.4 Changed Bug title to 'fpc MA setup breaks some reverse dependency builds' from 'castle-game-engine FTBFS with fpc 3.0.4'. > found -1 3.0.4+dfsg-13 Bug #887652 [src:castle-game-engine] fpc MA setup breaks some reverse dependency builds The source 'castle-game-engine' and version '3.0.4+dfsg-13' do not appear to match any binary packages Marked as found in versions castle-game-engine/3.0.4+dfsg-13. > block 887575 by -1 Bug #887575 [src:castle-game-engine] castle-game-engine FTBFS with fpc 3.0.4 887575 was not blocked by any bugs. 887575 was not blocking any bugs. Added blocking bug(s) of 887575: 887652 > thanks Stopping processing here. Please contact me if you need assistance. -- 887575: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887575 887652: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887652 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Thu Jan 18 18:45:05 2018 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Thu, 18 Jan 2018 18:45:05 +0000 Subject: [Pkg-pascal-devel] Processed (with 1 error): Re: Processed (with 1 error): Re: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 References: Message-ID: Processing commands for control at bugs.debian.org: > # oops > reassing 887652 src:fpc Unknown command or malformed arguments to command. > found 887652 3.0.4+dfsg-13 Bug #887652 [src:castle-game-engine] fpc MA setup breaks some reverse dependency builds The source 'castle-game-engine' and version '3.0.4+dfsg-13' do not appear to match any binary packages Ignoring request to alter found versions of bug #887652 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 887652: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887652 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Thu Jan 18 18:51:05 2018 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Thu, 18 Jan 2018 18:51:05 +0000 Subject: [Pkg-pascal-devel] Processed: Re: Processed (with 1 error): Re: Processed (with 1 error): Re: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 References: Message-ID: Processing commands for control at bugs.debian.org: > # Last try > reassign 887652 src:fpc Bug #887652 [src:castle-game-engine] fpc MA setup breaks some reverse dependency builds Bug reassigned from package 'src:castle-game-engine' to 'src:fpc'. No longer marked as found in versions castle-game-engine/3.0.4+dfsg-13 and castle-game-engine/6.2+dfsg1-1. Ignoring request to alter fixed versions of bug #887652 to the same values previously set > found 887652 3.0.4+dfsg-13 Bug #887652 [src:fpc] fpc MA setup breaks some reverse dependency builds Marked as found in versions fpc/3.0.4+dfsg-13. > thanks Stopping processing here. Please contact me if you need assistance. -- 887652: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887652 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From michalis.kambi at gmail.com Thu Jan 18 19:56:06 2018 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Thu, 18 Jan 2018 20:56:06 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: <1516283074.26470.2.camel@sfr.fr> References: <151624895548.1797.14154855774203524545.reportbug@localhost> <1516283074.26470.2.camel@sfr.fr> Message-ID: 2018-01-18 14:44 GMT+01:00 Abou Al Montacir : > Doing > > ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" > > Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do we > need to explicitly pass this? > Hi Abou, I think you're very right here -- the option "--globalunitdir XXX" should not be needed at all. Specifying $FPCDIR / --globalunitdir should only be necessary when the FPC is installed in some custom, user-owned location. But when the FPC is installed system-wide (like from a Debian package), then nothing (including CGE build script) should need to define $FPCDIR or use "--globalunitdir" anymore -- it should be picked up by the fpmake system automatically. That's how it should work in the upstream FPC, and I know there's an auto-detection in fpmkunit for these paths. So, it would be best to fix this issue, by fixing that auto-detection mechanism. To be clear: It's not just a matter of having correct /etc/fpc.cfg -- the fpmake also needs to know the root location of FPC units. (You would have to ask fpmake authors why they did it like this.) But that is why we have this complication with $FPCDIR or --globalunitdir or auto-detecting it. So, we should get to the point where CGE (or any other package using fpmake) can be compiled by simple ~~~ unset FPCDIR fpc fpmake.pp ./fpmake # without any additional options like --globalunitdir ~~~ Looking in the FPC sources, the auto-detection is inside packages/fpmkunit/src/fpmkunit.pp , in TFPCDefaults.CompilerDefaults , I'm quoting the relevant lines below. So, someone should adjust it (in Debian package) to follow the Debian path conventions :) That's a much better solution than both of my previous suggestions -- thanks! ~~~ procedure TFPCDefaults.CompilerDefaults; var BD : String; begin inherited CompilerDefaults; // Use the same algorithm as the compiler, see options.pas {$ifdef Unix} BD:=FixPath(GetEnvironmentVariable('FPCDIR'), False); if BD='' then begin BD:='/usr/local/lib/fpc/'+FCompilerVersion; if not DirectoryExists(BD) and DirectoryExists('/usr/lib/fpc/'+FCompilerVersion) then BD:='/usr/lib/fpc/'+FCompilerVersion; end; {$else unix} ... ~~~ Regards, Michalis From michalis.kambi at gmail.com Thu Jan 18 19:56:06 2018 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Thu, 18 Jan 2018 20:56:06 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: <1516283074.26470.2.camel@sfr.fr> References: <151624895548.1797.14154855774203524545.reportbug@localhost> <1516283074.26470.2.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: 2018-01-18 14:44 GMT+01:00 Abou Al Montacir : > Doing > > ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" > > Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do we > need to explicitly pass this? > Hi Abou, I think you're very right here -- the option "--globalunitdir XXX" should not be needed at all. Specifying $FPCDIR / --globalunitdir should only be necessary when the FPC is installed in some custom, user-owned location. But when the FPC is installed system-wide (like from a Debian package), then nothing (including CGE build script) should need to define $FPCDIR or use "--globalunitdir" anymore -- it should be picked up by the fpmake system automatically. That's how it should work in the upstream FPC, and I know there's an auto-detection in fpmkunit for these paths. So, it would be best to fix this issue, by fixing that auto-detection mechanism. To be clear: It's not just a matter of having correct /etc/fpc.cfg -- the fpmake also needs to know the root location of FPC units. (You would have to ask fpmake authors why they did it like this.) But that is why we have this complication with $FPCDIR or --globalunitdir or auto-detecting it. So, we should get to the point where CGE (or any other package using fpmake) can be compiled by simple ~~~ unset FPCDIR fpc fpmake.pp ./fpmake # without any additional options like --globalunitdir ~~~ Looking in the FPC sources, the auto-detection is inside packages/fpmkunit/src/fpmkunit.pp , in TFPCDefaults.CompilerDefaults , I'm quoting the relevant lines below. So, someone should adjust it (in Debian package) to follow the Debian path conventions :) That's a much better solution than both of my previous suggestions -- thanks! ~~~ procedure TFPCDefaults.CompilerDefaults; var BD : String; begin inherited CompilerDefaults; // Use the same algorithm as the compiler, see options.pas {$ifdef Unix} BD:=FixPath(GetEnvironmentVariable('FPCDIR'), False); if BD='' then begin BD:='/usr/local/lib/fpc/'+FCompilerVersion; if not DirectoryExists(BD) and DirectoryExists('/usr/lib/fpc/'+FCompilerVersion) then BD:='/usr/lib/fpc/'+FCompilerVersion; end; {$else unix} ... ~~~ Regards, Michalis From michalis.kambi at gmail.com Thu Jan 18 21:25:15 2018 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Thu, 18 Jan 2018 22:25:15 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: References: <151624895548.1797.14154855774203524545.reportbug@localhost> <1516283074.26470.2.camel@sfr.fr> Message-ID: 2018-01-18 20:56 GMT+01:00 Michalis Kamburelis : > So, we should get to the point where CGE (or any other package > using fpmake) can be compiled by simple > > ~~~ > unset FPCDIR > fpc fpmake.pp > ./fpmake # without any additional options like --globalunitdir > ~~~ > I created a "simplest possible example of using fpmake", so that you can test it all without dealing with (unrelated) Castle Game Engine code and Makefiles: - Get https://github.com/michaliskambi/simplest-fpmake-test . - Run "./testme.sh", that just calls "./fpmake". - I think that we should make it "just work" if user installed FPC from a Debian package. Without the need to set $FPCDIR, without the need to pass --globalunitdir . Right now, it will not work. Right now, you need to use --globalunitdir pointing to the proper location when invoking fpmake (see testme.sh comments). (In the previous FPC versions, setting environment variable FPCDIR was also enough, without the need for --globalunitdir . It doesn't work for me now, although I see that the code reading $FPCDIR is in TFPCDefaults.CompilerDefaults. As far as I observed, this was broken in FPC 3.x upstream, unrelated to Debian.) Regards, Michalis From michalis.kambi at gmail.com Thu Jan 18 21:25:15 2018 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Thu, 18 Jan 2018 22:25:15 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: References: <151624895548.1797.14154855774203524545.reportbug@localhost> <1516283074.26470.2.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: 2018-01-18 20:56 GMT+01:00 Michalis Kamburelis : > So, we should get to the point where CGE (or any other package > using fpmake) can be compiled by simple > > ~~~ > unset FPCDIR > fpc fpmake.pp > ./fpmake # without any additional options like --globalunitdir > ~~~ > I created a "simplest possible example of using fpmake", so that you can test it all without dealing with (unrelated) Castle Game Engine code and Makefiles: - Get https://github.com/michaliskambi/simplest-fpmake-test . - Run "./testme.sh", that just calls "./fpmake". - I think that we should make it "just work" if user installed FPC from a Debian package. Without the need to set $FPCDIR, without the need to pass --globalunitdir . Right now, it will not work. Right now, you need to use --globalunitdir pointing to the proper location when invoking fpmake (see testme.sh comments). (In the previous FPC versions, setting environment variable FPCDIR was also enough, without the need for --globalunitdir . It doesn't work for me now, although I see that the code reading $FPCDIR is in TFPCDefaults.CompilerDefaults. As far as I observed, this was broken in FPC 3.x upstream, unrelated to Debian.) Regards, Michalis From abou.almontacir at sfr.fr Fri Jan 19 08:14:47 2018 From: abou.almontacir at sfr.fr (Abou Al Montacir) Date: Fri, 19 Jan 2018 09:14:47 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: References: <151624895548.1797.14154855774203524545.reportbug@localhost> <1516283074.26470.2.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: <1516349687.26470.5.camel@sfr.fr> Hi Michalis, On Thu, 2018-01-18 at 22:25 +0100, Michalis Kamburelis wrote: > 2018-01-18 20:56 GMT+01:00 Michalis Kamburelis : > > So, we should get to the point where CGE (or any other package > > using fpmake) can be compiled by simple > > > > ~~~ > > unset FPCDIR > > fpc fpmake.pp > > ./fpmake # without any additional options like --globalunitdir > > ~~~ > > > > I created a "simplest possible example of using fpmake", so that you > can test it all without dealing with (unrelated) Castle Game Engine > code and Makefiles: > > - Get https://github.com/michaliskambi/simplest-fpmake-test . > - Run "./testme.sh", that just calls "./fpmake". > - I think that we should make it "just work" if user installed FPC > from a Debian package. Without the need to set $FPCDIR, without the > need to pass --globalunitdir . > > Right now, it will not work. Right now, you need to use > --globalunitdir pointing to the proper location when invoking fpmake > (see testme.sh comments). > > (In the previous FPC versions, setting environment variable FPCDIR was > also enough, without the need for --globalunitdir . It doesn't work > for me now, although I see that the code reading $FPCDIR is in > TFPCDefaults.CompilerDefaults. As far as I observed, this was broken > in FPC 3.x upstream, unrelated to Debian.) Thank you??for this example. I'll use it to debug this WE and hope we get it fixed by beginning of next week. --? Cheers, Abou Al Montacir -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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: From abou.almontacir at sfr.fr Fri Jan 19 08:23:10 2018 From: abou.almontacir at sfr.fr (Abou Al Montacir) Date: Fri, 19 Jan 2018 09:23:10 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: References: <151624895548.1797.14154855774203524545.reportbug@localhost> <1516283074.26470.2.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: <1516350190.26470.7.camel@sfr.fr> Hi Michalis, On Thu, 2018-01-18 at 20:56 +0100, Michalis Kamburelis wrote: > 2018-01-18 14:44 GMT+01:00 Abou Al Montacir : > > Doing > > > > ? ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" > > > > Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do we > > need to explicitly pass this? > > > > Hi Abou, > > I think you're very right here -- the option "--globalunitdir XXX" > should not be needed at all. Specifying $FPCDIR / --globalunitdir > should only be necessary when the FPC is installed in some custom, > user-owned location. But when the FPC is installed system-wide (like > from a Debian package), then nothing (including CGE build script) > should need to define $FPCDIR or use "--globalunitdir" anymore -- it > should be picked up by the fpmake system automatically. That's how it > should work in the upstream FPC, and I know there's an auto-detection > in fpmkunit for these paths. So, it would be best to fix this issue, > by fixing that auto-detection mechanism. I fully agree, I'll try to fix that. > To be clear: It's not just a matter of having correct /etc/fpc.cfg -- > the fpmake also needs to know the root location of FPC units. (You > would have to ask fpmake authors why they did it like this.) But that > is why we have this complication with $FPCDIR or --globalunitdir or > auto-detecting it. I've not been fan of fpmake, and I was used to compile my programs directly using fpc prog.pas. I understand one need to have some tool to build big projects, but then why not lazbuild. OK I'll stop complaining and try to fix this. > So, we should get to the point where CGE (or any other package > using fpmake) can be compiled by simple > > ~~~ > unset FPCDIR > fpc fpmake.pp > ./fpmake # without any additional options like --globalunitdir > ~~~ Yes, right! > Looking in the FPC sources, the auto-detection is inside > packages/fpmkunit/src/fpmkunit.pp , in TFPCDefaults.CompilerDefaults , > I'm quoting the relevant lines below. So, someone should adjust it (in > Debian package) to follow the Debian path conventions :) Wow! Thanks for this pointer, this saves me valuable time looking where to look for the bug! > That's a much better solution than both of my previous suggestions -- thanks! > > ~~~ > procedure TFPCDefaults.CompilerDefaults; > var > ? BD : String; > begin > ? inherited CompilerDefaults; > > ? // Use the same algorithm as the compiler, see options.pas > {$ifdef Unix} > ? BD:=FixPath(GetEnvironmentVariable('FPCDIR'), False); > ? if BD='' then > ????begin > ??????BD:='/usr/local/lib/fpc/'+FCompilerVersion; > ??????if not DirectoryExists(BD) and > ?????????DirectoryExists('/usr/lib/fpc/'+FCompilerVersion) then > ????????BD:='/usr/lib/fpc/'+FCompilerVersion; %s|usr/lib/fpc|usr/lib/' + FCompilerTargetTriplet + '/fpc|g > ????end; > {$else unix} > ... > ~~~ --? Cheers, Abou Al Montacir -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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: From michalis.kambi at gmail.com Fri Jan 19 14:39:03 2018 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Fri, 19 Jan 2018 15:39:03 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: <1516350190.26470.7.camel@sfr.fr> References: <1516283074.26470.2.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> <1516350190.26470.7.camel@sfr.fr> Message-ID: 2018-01-19 9:23 GMT+01:00 Abou Al Montacir : > To be clear: It's not just a matter of having correct /etc/fpc.cfg -- > the fpmake also needs to know the root location of FPC units. (You > would have to ask fpmake authors why they did it like this.) But that > is why we have this complication with $FPCDIR or --globalunitdir or > auto-detecting it. > > I've not been fan of fpmake, and I was used to compile my programs directly > using fpc prog.pas. > I understand one need to have some tool to build big projects, but then why > not lazbuild. You can use lazbuild to build Castle Game Engine (just run "lazbuild" on packages/castle_base.lpk , packages/castle_window.lpk, packages/castle_components.lpk). However, this requires having lazbuild installed, which is part of Lazarus. It is not available if you only have "bare" FPC installed. That is the only reason why I'm maintaining also an option to build using fpmake :) Regards, Michalis From michalis.kambi at gmail.com Fri Jan 19 14:39:03 2018 From: michalis.kambi at gmail.com (Michalis Kamburelis) Date: Fri, 19 Jan 2018 15:39:03 +0100 Subject: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4 In-Reply-To: <1516350190.26470.7.camel@sfr.fr> References: <1516283074.26470.2.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> <1516350190.26470.7.camel@sfr.fr> <151624895548.1797.14154855774203524545.reportbug@localhost> Message-ID: 2018-01-19 9:23 GMT+01:00 Abou Al Montacir : > To be clear: It's not just a matter of having correct /etc/fpc.cfg -- > the fpmake also needs to know the root location of FPC units. (You > would have to ask fpmake authors why they did it like this.) But that > is why we have this complication with $FPCDIR or --globalunitdir or > auto-detecting it. > > I've not been fan of fpmake, and I was used to compile my programs directly > using fpc prog.pas. > I understand one need to have some tool to build big projects, but then why > not lazbuild. You can use lazbuild to build Castle Game Engine (just run "lazbuild" on packages/castle_base.lpk , packages/castle_window.lpk, packages/castle_components.lpk). However, this requires having lazbuild installed, which is part of Lazarus. It is not available if you only have "bare" FPC installed. That is the only reason why I'm maintaining also an option to build using fpmake :) Regards, Michalis From pknewl at yahoo.com Fri Jan 19 19:47:47 2018 From: pknewl at yahoo.com (Patricia Knewl) Date: Fri, 19 Jan 2018 19:47:47 +0000 (UTC) Subject: [Pkg-pascal-devel] (no subject) References: <859517884.980819.1516391267616.ref@mail.yahoo.com> Message-ID: <859517884.980819.1516391267616@mail.yahoo.com> ?Dear Beloved, Compliments of the day to you! By this e-mail, I do sincerely apologize for my intrusion of your privacy. However, I have a serious concern with which I believe you might be of help and for this reason I decided to e-mail you believing in my faith that you will handle this issue with sincere mind. I am Mrs Patricia Knewl, I'm German citizen by birth and I'm married to Australian Mr. John Knewl, Please I am contacting you to let you know my desire to establish a charity foundation in your country with some amount of Euro (?8,800,000.00) which I inherited from my late husband (Mr. John Knewl) It is my desire to see that this money is invested to any charity organization of your choice in your country and distributed each year among the charity organizations, motherless baby?s home, mosques, churches, Schools, supporting destitute aged men and women or whatever you may have in mind that will be to the benefit of the less fortunate. I asked members of my husband family to donate to charity organization, they refused and kept the money for themselves. Hence, I do not trust them anymore, they are not contented with what left for them and all their wealth. I took this decision because I was raised from a motherless baby?s home and presently, I'm hospitalized where I am undergoing treatment for my up coming cancer surgery operation. Please reply as soon as possible to confirming your acceptance to this proposition so that I will give you all the relevant information that will authorize the release and transfer of the fund to you as my duly assigned representative. Thank you in advance for your understanding and I look forward hearing from you urgently. Best Regards, Mrs Patricia Knewl -------------- next part -------------- An HTML attachment was scrubbed... URL: From elbrus at debian.org Sun Jan 21 20:26:27 2018 From: elbrus at debian.org (Paul Gevers) Date: Sun, 21 Jan 2018 21:26:27 +0100 Subject: [Pkg-pascal-devel] Alioth to Salsa migration of the pascal packages Message-ID: <79e1ae98-644f-1a53-3521-5510237e7c7a@debian.org> Dear co Pascal developers, You should all be aware that Alioth is about to be decommissioned. As far as I see, the replacement on Salsa is mature enough? that I want to start migrating our archives over to it. I just created the pascal team?. The documentation (see ? for links) advises to lock down the archives on Alioth after the migration, so I'll do that for every archive that I migrate, hence this heads up. I'll try to post links to the new archives, but you should already be able to guess them. For all those people following this list that are not DD's yet but want to be part of the Salsa team, you'll have to sign-up for an Salsa account and ask us to add you to the team. I propose we don't start yet with updating the maintainer fields yet, as I don't believe there is consensus if the old values have to go away (there is an effort ongoing to keep supporting the Alioth mail lists). Paul ? https://lists.debian.org/msgid-search/877esvj33h.fsf at delenn.ganneff.de ? https://salsa.debian.org/pascal-team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: