Bug#1022343: [Pkg-pascal-devel] Bug#1022343: view3dscene: FTBFS: view3dscene.lpr(63, 17) Fatal: Can't find unit CastleCubeMaps used by view3dscene

[Michalis Kamburelis]

The new CGE (Castle Game Engine) indeed broke compatibility in this
regard: the unit has been renamed
CastleCubeMaps->CastleInternalCubeMaps . There are likely other small
incompatibilities -- view3dscene in general "exercises" a lot of
obscure CGE API (where we don't care much about backward compat,
because we predict almost nobody except view3dscene is using
something), and upgrading view3dscene and CGE usually have to be done
together.

In this case, view3dscene 4.2.0, which was released along with CGE,
contains a fixed (and generally better) view3dscene version. See

- 
https://castle-engine.io/wp/2022/09/12/castle-game-engine-7-0-alpha-2-release-many-new-components-lights-primitives-fonts-sound-new-cameras-terrains-sprite-sheet-editor-delphi/
,
- https://github.com/castle-engine/castle-engine/releases/tag/v7.0-alpha.2 ,
- https://github.com/castle-engine/view3dscene/releases/tag/v4.2.0 .

So my preferred way to solve this would be to just have view3dscene
4.2.0 in Debian.

Regards,
Michalis

niedz., 23 paź 2022 o 15:15 Lucas Nussbaum  napisał(a):
>
> Source: view3dscene
> Version: 4.0.0-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[3]: Entering directory '/<>/embedded_data/screen_effects'
> > file_to_pascal_string flashlight.glsl screen_effects_flashlight.glsl.inc
> > file_to_pascal_string edge_detect.glsl screen_effects_edge_detect.glsl.inc
> > make[3]: Leaving directory '/<>/embedded_data/screen_effects'
> > make[2]: Leaving directory '/<>'
> > fpc -k"-z relro -z now" -dRELEASE -Mobjfpc -Sh -Ci -Sm -Sc -Sg -Si -O2 -Xs 
> > -Fu/usr/lib/x86_64-linux-gnu/fpc/3.2.2/units/castle-game-engine  
> > code/view3dscene.lpr
> > Compiling Release Version
> > Free Pascal Compiler version 3.2.2+dfsg-15 [2022/08/20] for x86_64
> > Copyright (c) 1993-2021 by Florian Klaempfl and others
> > Target OS: Linux for x86-64
> > Compiling code/view3dscene.lpr
> > view3dscene.lpr(60,21) Warning: Unit "CastleProgress" is deprecated: "use 
> > TUIState and WaitForRenderAndCall to display progress of loading operations"
> > view3dscene.lpr(63,17) Fatal: Can't find unit CastleCubeMaps used by 
> > view3dscene
> > Fatal: Compilation aborted
> > Error: /usr/bin/ppcx64 returned an error exitcode
> > make[1]: *** [debian/rules:53: override_dh_auto_build-arch] Error 1
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2022/10/23/view3dscene_4.0.0-3_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221023;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221023=lu...@debian.org=1=1=1=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.
>
> ___
> Pkg-pascal-devel mailing list
> pkg-pascal-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel

Bug#954676: [Pkg-pascal-devel] Bug#954676: pasdoc: FTBFS: dh_installman: error: Could not determine section for ./pasdoc.1

[Michalis Kamburelis]

Paul Gevers  napisał(a):
>
> Hi Michalis,
>
> On 30-03-2020 14:11, Michalis Kamburelis wrote:
> > Do we know what the message "Could not determine section for" means,
> > or how to investigate it? I mean, this manpage should go to section 1
> > ("User Commands"), which is indicated both by the filename "pasdoc.1"
> > and by text inside "pasdoc(1)". Why does the dh_installman not catch
> > it?
>
> I don't know but if nobody does, I'll figure it out. I consider this a
> stupid regression of help2man and/or dh_installman, but there's probably
> a reason.
>
> > If necessary, I can easily create a proper manpage upstream (that
> > would be available in our repository, without the need for help2man),
> > I just need to know what is exactly required / necessary to avoid :)
>
> Let's not go that route unless you as upstream really want to support a
> proper man page. I mean, apparently you never really consider the
> program to lack a dedicated man page. Obviously if you think otherwise
> because of this issue, feel free to draft (and maintain) a man page
> upstream, but otherwise I am totally happy to ship a man page created
> with help2man. I assume you do maintain the --help option.
>

Thank you for looking into this.

Indeed, as upstream it is easier for me to *not* maintain a dedicated
webpage, and instead rely on "pasdoc --help" and help2man. The manpage
generated this way looks satisfactory I think (at least for us, humans
-- it seems only some programs complain :) ). So if we can fix this
without adding a dedicated man page, that's great.

Regards,
Michalis

Bug#954676: [Pkg-pascal-devel] Bug#954676: pasdoc: FTBFS: dh_installman: error: Could not determine section for ./pasdoc.1

[Michalis Kamburelis]

The PasDoc manpage in Debian is done using

help2man --output=pasdoc.1 --name="documentation tool for Pascal source code" \
 --no-info bin/pasdoc

Do we know what the message "Could not determine section for" means,
or how to investigate it? I mean, this manpage should go to section 1
("User Commands"), which is indicated both by the filename "pasdoc.1"
and by text inside "pasdoc(1)". Why does the dh_installman not catch
it?

If necessary, I can easily create a proper manpage upstream (that
would be available in our repository, without the need for help2man),
I just need to know what is exactly required / necessary to avoid :)

Regards,
Michalis

niedz., 22 mar 2020 o 15:03 Lucas Nussbaum  napisał(a):
>
> Source: pasdoc
> Version: 0.15.0-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200322 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> >  fakeroot debian/rules binary
> > dh binary
> >dh_testroot
> >dh_prep
> >dh_auto_install
> >dh_install
> >dh_installdocs
> >dh_installchangelogs
> >dh_installman
> > dh_installman: error: Could not determine section for ./pasdoc.1
> > dh_installman: error: Aborting due to earlier error
> > make: *** [debian/rules:13: binary] Error 25
>
> The full build log is available from:
>http://qa-logs.debian.net/2020/03/22/pasdoc_0.15.0-1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>
> ___
> Pkg-pascal-devel mailing list
> pkg-pascal-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel

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#887575: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4

[Michalis Kamburelis]

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

Bug#887575: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4

[Michalis Kamburelis]

2018-01-18 20:56 GMT+01:00 Michalis Kamburelis <michalis.ka...@gmail.com>:
> 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

Bug#887575: [Pkg-pascal-devel] Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4

[Michalis Kamburelis]

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

Bug#887575: castle-game-engine FTBFS with fpc 3.0.4

[Michalis Kamburelis]

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

Bug#813718: Patch in the MRIcron FTBFS bug

[Michalis Kamburelis]

2017-01-14 16:54 GMT+01:00 Andreas Tille :
> Hi Adrian,
>
> On Fri, Jan 13, 2017 at 05:29:01PM +0200, Adrian Bunk wrote:
>> I saw you were just working on the MRIcron package.
>>
>> Can you take a look at the patch in
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813718#40
>> ?
>
> Thanks for the ping.  I tried to turn the suggested patch into a quilt
> patch which I commited to Git:
>
>
> https://anonscm.debian.org/git/debian-med/mricron.git/tree/debian/patches/stricter_fpc.patch
>
> Unfortunately there is a Build-Problem:
>
> (3104) Compiling /build/mricron-0.20140804.1~dfsg.1/common/dialogsx.pas
> /build/mricron-0.20140804.1~dfsg.1/common/dialogsx.pas(75,42) Error: (5000) 
> Identifier not found "Dialogs"
> /build/mricron-0.20140804.1~dfsg.1/common/dialogsx.pas(75,42) Fatal: (2003) 
> Syntax error, ";" expected but "." found
> Fatal: (1018) Compilation aborted
> Error: /usr/bin/ppcx64 returned an error exitcode
> Error: (lazarus) Compile Project, Target: dcm2nii: stopped with exit code 256
> ERROR: failed compiling of project 
> /build/mricron-0.20140804.1~dfsg.1/dcm2nii/dcm2nii.lpi
> debian/rules:10: recipe for target 'override_dh_auto_build' failed
>
>
> I admit I can not see where a "." mit be but a ";" is expected but
> the patch seems to have some issue.
>

My patch from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813718#40
assumes that the "Dialogs" unit is in the uses clause. But the
"Dialogs" unit is in the uses clause only when the symbol "GUI" is
defined at compilation. I didn't test the compilation without the GUI
symbol.

I'm attaching a fixed version of the patch:)

Regards,
Michalis
diff -ur mricron-0.20140804.1~dfsg.1/common/dialogsx.pas mricron-0.20140804.1~dfsg.2/common/dialogsx.pas
--- common/dialogsx.pas	2014-01-28 18:06:18.0 +0100
+++ common/dialogsx.pas	2017-01-14 22:07:02.839240363 +0100
@@ -68,13 +68,44 @@
 
 function MsgDlg(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint): Word;
 {$IFDEF GUI}
+
+  { Convert our TMsgDlgButtons type to Dialogs.TMsgDlgButtons type
+in a type-safe manner. Do not assume that memory layout matches between
+- TMsgDlgButtons and Dialogs.TMsgDlgButtons, or
+- TMsgDlgBtn and Dialogs.TMsgDlgBtn. 
+  }
+  function MsgDlgButtonsConvertToStandard(
+const Buttons: TMsgDlgButtons): Dialogs.TMsgDlgButtons;
+  var
+B: TMsgDlgBtn;
+  begin
+Result := [];
+for B := Low(B) to High(B) do
+  if B in Buttons then
+{ convert our TMsgDlgBtn to Dialogs.TMsgDlgBtn type }
+case B of
+  mbYes : Include(Result, Dialogs.mbYes );
+  mbNo  : Include(Result, Dialogs.mbNo  );
+  mbOK  : Include(Result, Dialogs.mbOK  );
+  mbCancel  : Include(Result, Dialogs.mbCancel  );
+  mbAbort   : Include(Result, Dialogs.mbAbort   );
+  mbRetry   : Include(Result, Dialogs.mbRetry   );
+  mbIgnore  : Include(Result, Dialogs.mbIgnore  );
+  mbAll : Include(Result, Dialogs.mbAll );
+  mbNoToAll : Include(Result, Dialogs.mbNoToAll );
+  mbYesToAll: Include(Result, Dialogs.mbYesToAll);
+  mbHelp: Include(Result, Dialogs.mbHelp);
+  else raise Exception.Create('Unsupported TMsgDlgBtn value');
+end;
+  end;
+
 var
lDlgType : Dialogs.TMsgDlgType;
lButtons: Dialogs.TMsgDlgButtons;
 
 begin
   lDlgType :=  Dialogs.TMsgDlgType(DlgType);
-  lButtons:= Dialogs.TMsgDlgButtons(Buttons);
+  lButtons:= MsgDlgButtonsConvertToStandard(Buttons);
   result := MessageDlg(Msg, lDlgType, lButtons,HelpCtx);
 {$ELSE}
 begin

Bug#820708: CGE and view3dscene tested with libpng 1.6

[Michalis Kamburelis]

Hi,

Quick test showed that Castle Game Engine and view3dscene work OK with
libpng 1.6. Various testing images (with colors encoded in different
ways), as well as deliberately wrong images, are handled correctly.

Tested with libpng16-16 in current Debian testing (1.6.21-2).

The necessary change in CGE is just a 2-line addition of

  if PngLibrary = nil then
PngLibrary := TDynLib.Load('libpng16.so.16', false);

to src/images/castlepng_dynamic.inc . Nothing else is needed. I
committed this upstream (taking also the occasion to improve comments
and search order there) in
https://github.com/castle-engine/castle-engine/commit/3abd42911bd85bf3782d0fac16439d0ab301d11a
.

For testing, you can simply comment out loading other libpng versions,
to make sure that only libpng 1.6 is picked up. (In engine version
from GitHub, you would also undefine CASTLE_PNG_USING_FCL_IMAGE in
src/base/castleconf.inc, to avoid using the native Pascal version.)

Regards,
Michalis

Bug#820708: [Pkg-pascal-devel] Bug#820708: castle-game-engine: hardcoded libpng12 dependency

[Michalis Kamburelis]

> Source: castle-game-engine
> Version: 5.2.0-2
> Severity: serious
> Justification: libpng1.6 transition
>
> Dear maintainer,
>
> in the discussion in #820566 it surfaced that castle-game-engine has a 
> hardcoded
> dependency on libpng12.
>
> After the completion of the tlibpng 1.6 transition, libpng12 will be removed,
> Therefore this bug is RC.
>
> Another bug is that this dependency is completly oqaue to the outside world.
> this is why has not been detected during the preparation of the transtiion.
> Please establish something here to catch e.g by buildtime checks,
> build-conflicts or other measure to make this more robust for other 
> transitions.
>
> (view3dscene, #820566 has the same bug, maybe you find can together find an 
> solution.)

1. 2. are just clarifications (I'm just repeating here some bits
mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820566
), 3. is a suggestion how to make a buildtime check if someone would
like to tackle this:)

1. Castle Game Engine works with libpng 1.2 or 1.4 (not only 1.2).

2. It's not a "hard dependency on libpng". It's perfectly sensible to
use Castle Game Engine without libpng. Having libpng installed *helps*
(it allows you to open png images, obviously), but it is not required
for all CGE use-cases. E.g. if you make a game that does not load png
images, you can certainly use Castle Game Engine without libpng.

  For Debian packaging, it may make sense to just simplify and say
"let castle-game-engine recommend libpng". I'm just saying that it's
not a strict dependency for upstream.

  Also remember that it will disappear in next CGE release, where PNG
reader is implemented without libpng (using FPC fcl-image, so it gets
compiled statically in, with the rest of FPC RTL).

3. If you want to add an automatic test that CGE can correctly
read+write PNG files, you can use e.g.
examples/images_videos/image_convert.lpr . Just compile it, and run
like

  image_convert ../2d/box_with_borders.png /tmp/whatever.png

  If /tmp/whatever.png exists, then png reading+writing works. In case
of problems (like a missing libpng), the program should write a clear
error message and have non-zero exit status.

Regards,
Michalis

Bug#820566: [Pkg-pascal-devel] Bug#820566: Bug#820566: view3dscene: please stop depending on libpng12-0

[Michalis Kamburelis]

> @Michalis, does view3dscene work with libpng16, or do you first need to
> port view3dscene to that API? If so, we better just drop the dependency
> for now.

Hi,

I'm not sure what is the dependency ldd detects. It seems that
something (possibly some unit inside FPC RTL?) uses the PNG unit
(which links to libpng in a traditional way and will be detected like
this by ldd).

In any case, like Paul writes, view3dscene (actually, Castle Game
Engine underneath) loads png library by dlopen/dlsym. This way things
work smoothly even when libpng is not available. The loading of libpng
library is trivially coded inside CGE in
src/images/castlepng_dynamic.inc (we just try to open libpng12.so.0,
or libpng.so, or libpng14.so.14...). This probably has to be adjusted
to look also for libpng16.so.16, so it will be a 2-line patch to make
view3dscene (actually, Castle Game Engine) in Debian work with libpng
1.6.

We carefully use a small subset on libpng API that is available in at
least libpng 1.2, 1.4. I can test around the weekend whether it also
works with libpng 1.6, from briefly reading about libpng 1.5 and 1.6
-- we should be fine.

So, the things to do here:

1. Make a 2-line change to CGE to src/images/castlepng_dynamic.inc to
try loading libpng16.so.16 .

2. Test whether view3dscene (actually, everything using Castle Game
Engine) works with this libpng version. Probably yes:)

I'll happily do it in a couple of days, around the nearest weekend:)

Sidenotes:

- The way we use libpng can be reconfigured to use static linking by
defining CASTLE_PNG_STATIC at compilation, see castlepng.pas and
castleconf.inc. Although I don't think it's necessary at this point.

- In the future CGE and view3dscene releases (which can be tested
using our GIT or SVN code right now), by default we use the png loader
provided by the FPC fcl-image library. Which uses png reading
implemented natively in Pascal in FPC fcl-image. This removes the
dependency on libpng entirely. It remains configurable anyway (you can
recompile engine with proper options to alternatively use libpng, with
traditional linking or with dlopen/dlsym).

Regards,
Michalis

Bug#813718: [Pkg-pascal-devel] Bug#813718: mricron: FTBFS: dialogsx.pas(77, 14) Error: (4054) Illegal type conversion: "TMsgDlgButtons" to "TMsgDlgButtons"

[Michalis Kamburelis]

> Short story: the patch is attached, it should help:)

Better take this patch version (spaces, not tabs:).
Michalis
--- common/dialogsx.pas.orig	2016-02-06 15:20:36.0 +0100
+++ common/dialogsx.pas	2016-02-06 15:43:30.0 +0100
@@ -66,6 +66,36 @@
 end;
 {$ENDIF}
 
+{ Convert our TMsgDlgButtons type to Dialogs.TMsgDlgButtons type
+  in a type-safe manner. Do not assume that memory layout matches between
+  - TMsgDlgButtons and Dialogs.TMsgDlgButtons, or
+  - TMsgDlgBtn and Dialogs.TMsgDlgBtn. 
+}
+function MsgDlgButtonsConvertToStandard(
+  const Buttons: TMsgDlgButtons): Dialogs.TMsgDlgButtons;
+var
+  B: TMsgDlgBtn;
+begin
+  Result := [];
+  for B := Low(B) to High(B) do
+if B in Buttons then
+  { convert our TMsgDlgBtn to Dialogs.TMsgDlgBtn type }
+  case B of
+mbYes : Include(Result, Dialogs.mbYes );
+mbNo  : Include(Result, Dialogs.mbNo  );
+mbOK  : Include(Result, Dialogs.mbOK  );
+mbCancel  : Include(Result, Dialogs.mbCancel  );
+mbAbort   : Include(Result, Dialogs.mbAbort   );
+mbRetry   : Include(Result, Dialogs.mbRetry   );
+mbIgnore  : Include(Result, Dialogs.mbIgnore  );
+mbAll : Include(Result, Dialogs.mbAll );
+mbNoToAll : Include(Result, Dialogs.mbNoToAll );
+mbYesToAll: Include(Result, Dialogs.mbYesToAll);
+mbHelp: Include(Result, Dialogs.mbHelp);
+else raise Exception.Create('Unsupported TMsgDlgBtn value');
+  end;
+end;
+
 function MsgDlg(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint): Word;
 {$IFDEF GUI}
 var
@@ -74,7 +104,7 @@
 
 begin
   lDlgType :=  Dialogs.TMsgDlgType(DlgType);
-  lButtons:= Dialogs.TMsgDlgButtons(Buttons);
+  lButtons:= MsgDlgButtonsConvertToStandard(Buttons);
   result := MessageDlg(Msg, lDlgType, lButtons,HelpCtx);
 {$ELSE}
 begin

Bug#813718: [Pkg-pascal-devel] Bug#813718: mricron: FTBFS: dialogsx.pas(77, 14) Error: (4054) Illegal type conversion: "TMsgDlgButtons" to "TMsgDlgButtons"

[Michalis Kamburelis]

> I can't see where the dialogs unit is getting the TMsgDlgButtons method
> or function or procedure or whatever it is called in Pascal from.

Short story: the patch is attached, it should help:)

Longer explanation:

1. TMsgDlgButtons is a "type". It's a set (which is like a type-safe
bitfield in Pascal). Writing "Dialogs.TMsgDlgButtons" means "take
TMsgDlgButtons type from Dialogs unit, not from any other unit that
may define the same name" --- that's how you deal with multiple used
units having the same identifier in Pascal.

2. What happens in this code is a little dirty, as mricron code
defines it's own type "TMsgDlgButtons", with the *exact* same memory
layout as standard "TMsgDlgButtons" type in "Dialogs" unit. "Dialogs"
unit is part of the Lazarus library (LCL). Then the line

  lButtons:= Dialogs.TMsgDlgButtons(Buttons);

converts one type to another. The dirtyness here is that such typecast
avoids any type checks, it just assumes that memory layout of both
"TMsgDlgButtons" types matches, and that the programmer knows what
(s)he is doing:)

3. To make it a little confusing, type names are the same, so you need
to be aware how compiler resolves them, and some error messages become
unclear. This message from FPC:

  Illegal type conversion: "TMsgDlgButtons" to "TMsgDlgButtons"

actually means that we cannot convert "TMsgDlgButtons as defined in
unit dialogsx" to "TMsgDlgButtons as defined in unit Dialogs".
Possibly FPC checks got stricter? Which would be a good thing here ---
this code is indeed dangerous, it's good that it's prohibited, IMHO.

In fact, Lazarus Dialogs.TMsgDlgButtons type did change (there's a new
enum mbClose), it only accidentally didn't change the memory layout of
TMsgDlgButtons (as mbClose was added at the end).

4. The attached patch just does the type conversion the long (but safe) way.

Regards,
Michalis
--- common/dialogsx.pas.orig	2016-02-06 15:20:36.0 +0100
+++ common/dialogsx.pas	2016-02-06 15:32:45.0 +0100
@@ -66,6 +66,36 @@
 end;
 {$ENDIF}
 
+{ Convert our TMsgDlgButtons type to Dialogs.TMsgDlgButtons type
+  in a type-safe manner. Do not assume that memory layout matches between
+  - TMsgDlgButtons and Dialogs.TMsgDlgButtons, or
+  - TMsgDlgBtn and Dialogs.TMsgDlgBtn. 
+}
+function MsgDlgButtonsConvertToStandard(
+  const Buttons: TMsgDlgButtons): Dialogs.TMsgDlgButtons;
+var
+  B: TMsgDlgBtn;
+begin
+  Result := [];
+  for B := Low(B) to High(B) do
+if B in Buttons then
+  { convert our TMsgDlgBtn to Dialogs.TMsgDlgBtn type }
+  case B of
+mbYes	  : Include(Result, Dialogs.mbYes );
+	mbNo	  : Include(Result, Dialogs.mbNo  );
+	mbOK	  : Include(Result, Dialogs.mbOK  );
+	mbCancel  : Include(Result, Dialogs.mbCancel  );
+	mbAbort	  : Include(Result, Dialogs.mbAbort   );
+	mbRetry	  : Include(Result, Dialogs.mbRetry   );
+	mbIgnore  : Include(Result, Dialogs.mbIgnore  );
+	mbAll	  : Include(Result, Dialogs.mbAll );
+	mbNoToAll : Include(Result, Dialogs.mbNoToAll );
+	mbYesToAll: Include(Result, Dialogs.mbYesToAll);
+	mbHelp	  : Include(Result, Dialogs.mbHelp);
+else raise Exception.Create('Unsupported TMsgDlgBtn value');
+  end;
+end;
+
 function MsgDlg(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint): Word;
 {$IFDEF GUI}
 var
@@ -74,7 +104,7 @@
 
 begin
   lDlgType :=  Dialogs.TMsgDlgType(DlgType);
-  lButtons:= Dialogs.TMsgDlgButtons(Buttons);
+  lButtons:= MsgDlgButtonsConvertToStandard(Buttons);
   result := MessageDlg(Msg, lDlgType, lButtons,HelpCtx);
 {$ELSE}
 begin

Bug#806488: [Pkg-pascal-devel] Bug#806488: view3dscene: FTBFS: v3dsceneraytrace.pas Error: Identifier not found "TImageFormat"

[Michalis Kamburelis]

Paul Gevers wrote:
> This makes me wonder, does fpc have any reasonable symbols
> tracking mechanism? I guess it does (at least in ppu files), so
> should we extend the Debian tooling dh_makeshlibs/dh_shlibsdeps to
> be able to handle the fpc situation?

ppu files indeed hold the 100% information about unit's interface
(what symbols are exported, what other units are used etc.).

You could probably use this information to automatically detect
dependencies, or detect when something from the API was removed. But
this would need writing and maintaining the tool to do this, which
seems non-trivial, at least if I understand the desired usage. To
check for API compatibility breakage (like in this case) --- it seems
easier to just attempt recompiling and see what is required/broken:)

Hm, although to detect dependencies between Pascal programs/libraries,
using

  ppudump *.ppu | grep 'Uses unit'

may be a useful solution... Going only a little further, this trivial
snippet:

  find . -iname *.ppu -execdir ppudump '{}' ';' | grep 'Uses unit' |
awk '{ print $3 }' | sort -u

tells you what Pascal units are used by the project at a glance. Which
I guess would be helpful to automatically fill what Debian packages
'fp-units-xxx' should be required.

> 
>> The view3dscene sources in SVN are of course adjusted since a
>> long time, but there hasn't been a view3dscene release since some
>> time.
> 
> If you don't want to release newer version for these kind of 
> incompatibilities, or if you want to go to something fully based
> on version control versions, than let's discuss. We can come up
> with working schemes if you want. I am not strict on having
> upstream tar balls (although it is nice that people can check the
> checksum of the Debian tar ball versus the one provided by
> upstream). So if you are more for rolling release, we could do
> that.
> 

I think the current approach is OK. If you take the latest stable
release of Castle Game Engine and view3dscene, they *should* be
compatible, that's my goal. I always make extensive view3dscene tests
together with CGE release (as they are related quite closely), so I
always should release view3dscene with CGE.

I simply forgot to do it this time... it's my human error, not a
system error, I say:)


> Could you at least communicate these kind of changes pro-active on
> this list or somewhere in your own domain where we can pick it up
> (via push communication). Or just a clear "THIS BREAKS API" note in
> some changelog, I scan all the changed between two versions during
> import of the tar ball.

I try to document everything in the release notes. But sometimes I cut
off from release notes changes that I consider "tiny", since the
release notes are usually too long anyway.

In case of my own programs, and *especially* in case of view3dscene,
they often use obscure APIs of the engine, APIs that (I suspect) are
not really used widely. That was the case with TImageFormat, and
that's why it slipped from the changelog. Small API breakage that I
thought would go unnoticed... until it got noticed:)

Point taken, I'll try to communicate such breakage next time! And
also, to always keep latest release CGE and view3dscene releases
compatible. I can't avoid the fact that they are very tightly related
(that's a feature actually, view3dscene being a "swiss army knife of
the engine", important tool to inspect 3D and 2D files). But I always
update them simultaneously in SVN, and so they should also be released
together.

> 
>> I'm attaching a minimal patch that, when applied to view3dscene
>> 3.15.0 sources, makes them compile with Castle Game Engine
>> 5.2.0:) Tested with FPC 2.6.4.
> 
> If possible, could you check also with 3.0.0. That was released
> last week and I am preparing the upload (to experimental) still.
> When we verified all reversed dependencies (help would be nice), I
> want to ask for a transition slot.
> 

Tested: CGE 5.2.0 with view3dscene 3.15.0 (with my patched attached
earlier) compile fine with FPC 3.0.0, on Linux x86_64 at least:)

Same for CGE SVN with view3dscene SVN.

Regards,
Michalis

Bug#806488: [Pkg-pascal-devel] Bug#806488: view3dscene: FTBFS: v3dsceneraytrace.pas Error: Identifier not found "TImageFormat"

[Michalis Kamburelis]

Chris West (Faux) wrote:

> mkdir -p /view3dscene-3.15.0/debian/tmp/usr/lib/view3dscene/3.15.0
> fpc -k"-z relro" -dRELEASE -Mobjfpc -Sh -Ci -Sm -Sc -Sg -Si -O2 -Xs
> -FU/view3dscene-3.15.0/debian/tmp/usr/lib/view3dscene/3.15.0
> -FE/view3dscene-3.15.0/debian/tmp/usr/bin
> -Fu/usr/lib/x86_64-linux-gnu/fp-units-2.6.4/castle-game-engine-5.2.0/
> view3dscene.lpr
...
> v3dsceneraytrace.pas(135,26) Error: Identifier not found "TImageFormat"

Reason: view3dscene source code of version 3.15.0 is not compatible with
Castle Game Engine version 5.2.0. I removed the identifier TImageFormat
from the public interface of CastleImages unit. The view3dscene sources
in SVN are of course adjusted since a long time, but there hasn't been a
view3dscene release since some time.

IOW, it's my fault, I broke Castle Game Engine API in 5.2.0.

I'm attaching a minimal patch that, when applied to view3dscene 3.15.0
sources, makes them compile with Castle Game Engine 5.2.0:) Tested with
FPC 2.6.4.

The need for this patch will disappear with next view3dscene release.

Regards,
Michalis
diff -ur view3dscene-original/v3dscenelightseditor.pas view3dscene/v3dscenelightseditor.pas
--- view3dscene-original/v3dscenelightseditor.pas	2014-12-30 03:51:05.0 +0100
+++ view3dscene/v3dscenelightseditor.pas	2015-11-28 00:15:34.319771551 +0100
@@ -312,10 +312,10 @@
   inherited;
   BackgroundOpacityFocused := 0.3;
   BackgroundOpacityNotFocused := 0.2;
-  PositionRelativeMenuX := prLow;
-  PositionRelativeMenuY := prHigh;
-  PositionRelativeScreenX := prLow;
-  PositionRelativeScreenY := prHigh;
+  PositionRelativeMenuX := hpLeft;
+  PositionRelativeMenuY := vpTop;
+  PositionRelativeScreenX := hpLeft;
+  PositionRelativeScreenY := vpTop;
   Position[0] := 20;
   Position[1] := - WindowMarginTop - 20;
 end;
diff -ur view3dscene-original/v3dsceneraytrace.pas view3dscene/v3dsceneraytrace.pas
--- view3dscene-original/v3dsceneraytrace.pas	2014-12-30 03:51:05.0 +0100
+++ view3dscene/v3dsceneraytrace.pas	2015-11-28 00:14:42.390563004 +0100
@@ -132,28 +132,11 @@
 var
   D: PCallData;
   SaveURL: string;
-  ImgFormat: TImageFormat;
 begin
   D := PCallData(Window.UserData);
-
   SaveURL := ApplicationName + '_rt.png';
-  if Window.FileDialog('Save image', SaveURL, false,
-SaveImage_FileFilters) then
-  begin
-{ Determine ImgFormat exactly the same like SaveImage() does. }
-if MimeTypeToImageFormat(URIMimeType(SaveURL), false, true, ImgFormat) and
-  (ImgFormat = ifRGBE) then
-  MessageOK(Window,
-'Note: When saving raytraced image from view3dscene to ' +
-'RGBE file format, you will *not* get image with perfect ' +
-'RGB+Exponent precision. ' +
-'That''s because image is already stored in memory in RGB ' +
-'(8 bits per component) format (this was required to quickly display ' +
-'image in OpenGL) so any precision (beyond 8-bits) is already lost. ' +
-'Use rayhunter if you want to have RGBE image with precise colors.');
-
+  if Window.FileDialog('Save image', SaveURL, false, SaveImage_FileFilters) then
 SaveImage(D^.Image, SaveURL);
-  end;
 end;
 
 procedure EventEscape;

Bug#750340: Recompilation of CastleStringUtils

[Michalis Kamburelis]

In case of recursive unit dependencies, FPC sometimes wants to recompile
the units even though nothing changed. See e.g.
http://bugs.freepascal.org/view.php?id=12223 .

Possibly this is the reason of problems mentioned here. As Castle Game
Engine sources are not available anymore (only the compiled .ppu) when
compiling view3dscene.

Try compiling the Castle Game Engine sources with -Ur to avoid this.

Michalis


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578212: docbookwiki: Function named GoTo conflicts with PHP 5.3

[Michalis Kamburelis]

Package: docbookwiki
Version: 0.9.1cvs-12
Severity: grave
Justification: renders package unusable

DocBookWiki uses php function named GoTo (defined
in /usr/share/docbookwiki/web_app/class.WebApp.php line 125,
used all over the place). This is a problem, since php 5.3
introduces goto construct (http://pl.php.net/goto),
making it seemingly impossible to declare a user function
with the name goto (regardless of case, it seems).

Result: after uprading php to 5.3 (I had libapache2-mod-php5
version 5.2.12.dfsg.1-2, upgraded to 5.3.2-1)
DocBookWiki fails, leaving in /var/log/apache2/error.log php errors:

PHP Parse error:  syntax error, unexpected T_GOTO,
expecting T_STRING in /usr/share/docbookwiki/web_app/class.WebApp.php
on line 125

Seems that the only fix would be to rename GoTo PHP function
in DocBookWiki to something else, grepping for all occurences.

Setting as grave, as this makes DocBookWiki broken
with php 5.3 in current Debian.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-486
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages docbookwiki depends on:
ii  adduser   3.112  add and remove users and groups
ii  apache2-mpm-prefork [http 2.2.15-3   Apache HTTP Server - traditional n
ii  dblatex   0.2.12-4   Produces DVI, PostScript, PDF docu
ii  debconf [debconf-2.0] 1.5.30 Debian configuration management sy
ii  docbook-dsssl 1.79-6 modular DocBook DSSSL stylesheets,
ii  docbook-utils 0.6.14-1.1 Convert Docbook files to other for
ii  docbook-xml   4.5-7  standard XML documentation system 
ii  docbook-xsl   1.75.2+dfsg-5  stylesheets for processing DocBook
ii  gawk  1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr
ii  jadetex   3.13-12generator of printable output from
ii  libapache2-mod-php5   5.3.2-1server-side, HTML-embedded scripti
ii  libxml2-utils 2.7.7.dfsg-1   XML utilities
ii  mysql-server  5.1.45-1   MySQL database server (metapackage
ii  mysql-server-5.1 [mysql-s 5.1.45-1   MySQL database server binaries
ii  openssl   0.9.8n-1   Secure Socket Layer (SSL) binary a
ii  php5-cli  5.3.2-1command-line interpreter for the p
ii  php5-mysql5.3.2-1MySQL module for php5
ii  subversion1.6.9dfsg-1Advanced version control system
ii  sudo  1.7.2p5-1  Provide limited super user privile
ii  svn-load  1.2-1  An enhanced import facility for Su
ii  swish-e   2.4.7-1Simple Web Indexing System for Hum
ii  xmltex1.9.debian.1-2 TeX package for processing XML fil
ii  xmlto 0.0.23-2   XML-to-any converter
ii  xsltproc  1.1.26-2   XSLT command line processor

docbookwiki recommends no packages.

docbookwiki suggests no packages.

-- debconf information:
* docbookwiki/restart_webserver: true
  docbookwiki/generate_downloads: false
* docbookwiki/purge_books: false
  docbookwiki/reconfigure_webserver:



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org