Bug#1061418: [Pkg-pascal-devel] Bug#1061418: castle-game-engine: please add support for loong64

[Michalis Kamburelis]

Hi,

(Upstream of CGE here.)

For a new architecture, we need to have FPC (our compiler) with the
appropriate support for the architecture first.

- And at least upstream FPC 3.2.2 doesn't have this support (the CPU
isn't listed in
https://gitlab.com/freepascal.org/fpc/source/-/blob/fixes_3_2/packages/fpmkunit/src/fpmkunit.pp?ref_type=heads
).

- Only FPC from GitLab (not yet released) has this, and it is called
"loongarch64" (see
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fpmkunit/src/fpmkunit.pp
). I don't know whether the support is considered stable or not.

- The FPC in Debian (
https://packages.debian.org/sid/fp-compiler-3.2.2 ) isn't released for
this architecture.

So, we need FPC to support this architecture (in some stable way), and
we need this FPC to be packaged in Debian, first.

Then adding it to CGE will be easy :)

- Once the FPC (at least packaged in Debian) has this supported, then
CGE unit ToolArchitectures ( tools/common-code/toolarchitectures.pas )
should be extended, to add a new enum to TCPU type.

- Extending the ToolDebian", as the attached patch does, is also nice
(but optional, it's only useful for `castle-engine package
--format=deb` to create DEBs of your games for new architeture; it's
not necessary to just build applications for new architecture).

- The attached patch just adds "loong64: Result := 'loong64';" to
"ToolDebian" but I don't think it can compile right now -- it
certainly doesn't compile with FPC 3.2.2 upstream.

Regards,
Michalis

śr., 24 sty 2024 o 09:18 wuruilong  napisał(a):
>
> Source: castle-game-engine
> Severity: normal
> X-Debbugs-Cc: wuruil...@loongson.cn
>
> Dear Maintainer,
>
> Please refer to the attachment patch to support loong64 arch
>
> wuruilong
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: loong64 (loongarch64)
>
> Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> ___
> 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#967284: [Pkg-pascal-devel] Bug#967284: castle-game-engine: depends on deprecated GTK 2

[Michalis Kamburelis]

pc/source/-/issues/39989 ). So I
guess in CGE upstream we'll have to fork these units:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/lcl/interfaces/gtk3
. I suppose Debian will also want to provide Pascal GTK3 bindings (in
a way independent from Lazarus or LCL), so CGE on Debian should use
Debian's version of Pascal GTK3 bindings. We risk having some work to
synchronize all these GTK3 bindings versions, but I don't think we can
avoid it, until FPC or Lazarus decide on where to centralize Pascal
GTK3 bindings. I see that Abou (Debian developer, also on
Pkg-pascal-devel list) is also participating in
https://gitlab.com/freepascal.org/fpc/source/-/issues/39989 so I guess
he's tracking that.

Regards,
Michalis

śr., 27 wrz 2023 o 12:27 Peter B  napisał(a):
>
> On 27/09/2023 10:45, Bastian Germann wrote:
> > On Sun, 9 Aug 2020 23:01:12 +0200 Michalis Kamburelis wrote:
> >> Upgrade to GTK3 is planned.
> >
> > Would it be possible to build with qt5 instead? From a Debian packaging 
> > perspective,
> > this should already work as opposed to gtk3.
> >
>
> Hi Bastian,
>
> That would maybe have possible if castle-game-engine was built with Lazarus,
> but it is built with Gtk2 via fp-units-gtk2.
>
> Michalis is the expert here, but FWIW, my guess is no.
>
>
> Regards,
> Peter
>

Bug#891685: castle-game-engine: FTBFS on m68k: color and vector tests fail

[Michalis Kamburelis]

Hello,

>From my side (upstream):

1. I fixed the compilation with ENDIAN_BIG in this commit:
https://github.com/castle-engine/castle-engine/commit/63ccfc4dd327fc4de1c71f8b351e1ab1933ba47d
. It's now pushed to CGE master.

I just removed the swap -- just like Abou said, indeed the swap in
this case wasn't sensible at all.

Note that I tested ENDIAN_BIG compilation now in a rather stupid
way (I just define it manually, while actually running compiler on
regular x86_64). I didn't really run it on big-endian machine.

2. Abou's idea with "case" in record -- that's just an excellent idea.
Thank you, I have implemented it now :)

Details:

- Note that it would not solve the faulty code in
src/scene/load/x3dloadinternal3ds.pas , doing stuff like "Col3Byte[2]
:= b;" , because "AsBytes" is not a default property.

- Note that all record properties have to stay read-only otherwise
we run into a risk of "traps". This is described on
https://castle-engine.io/coding_traps and at comment "Note: We avoid
introducing in these records *any* method that changes the current
record value." in
https://github.com/castle-engine/castle-engine/blob/master/src/base/castlevectors_generic_float_record.inc
. So the writes to records must happen directly through fields. Using
"case" allows us to expose fields in more ways -- great!

- Using "case" is an excellent idea to have writeable Data, and
also "subsets" like XY inside TVector3, XYZ inside TVector4.

It's now done on branch
https://github.com/castle-engine/castle-engine/tree/vectors-data-as-case
. I'll merge it tomorrow if it will pass all automatic Jenkins tests
(with various FPC and Delphi versions -- but I did test that FPC
3.2.0, 3.2.2, trunk and Delphi 11 all allow "case" in advanced
records).

Thanks!
Michalis

niedz., 9 kwi 2023 o 18:09 Abou Al Montacir  napisał(a):
>
> Hi,
>
> On Thu, 2022-05-26 at 20:23 +0200, Abou Al Montacir wrote:
>
> CGE build correctly on m68k architecture now.
>
> This was broken again in new upstream 7.0~alpha.2 release.
>
> There was a rework of TVector3Byte where the base data was changed from an 
> array to a record fields and a default property was added to allow array like 
> access.
> However, this array like property is read only, while a load from stream 
> function tries, in big endian mode, to switch bytes.
> While I don't think this swap endianess code is needed at all, I would 
> preferred a faster implementation with basic records:
>
>   TVector3Byte = packed record
>
>   case Boolean of:
>
> false: (x, y, z: Byte);
>
> true: (AsBytes: array[0..2] of Byte);
>
>   end;
>
>
> Anyway, I'll let upstream fix this as they wants, but probably this will 
> never be in Bookworms.
>
> --
>
> Cheers,
> Abou Al Montacir

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#820708: autopkgtest if cge works with current libpng version

[Michalis Kamburelis]

Note that Castle Game Engine contains a number of automatic tests that load PNG 
images already.

In particular tests/code/testcastleimages.pas loads various PNG images, 
checking that the type (like RGBA) and sizes are correct. See 
https://github.com/castle-engine/castle-engine/blob/master/tests/code/testcastleimages.pas
 .

This testcase is executed as part of large application in tests/, using 
FpcUnit, and Debian already executes this testsuite automatically as far as I 
know.

The one thing we don't test there is whether we actually use LibPng, not some 
other PNG-reading library.


CGE by itself will automatically fallback from LibPng to FpImage (in CGE 
7.0-alpha1) if LibPng is not found. This is acceptable for CGE, although on 
Linux practically everyone has LibPng, and we take care of distributing LibPng 
for other platforms too (like Windows, Android, iOs). But we still consider a 
"fallback on some other library to read PNG, like FpImage" useful, as A. we 
need such library anyway for other image formats (like JPG) and B. it will work 
in all possible cases (e.g. if someone packages CGE application in some weird 
way on Windows, and deletes "libpngXXX.dll").

In the upcoming CGE version, 7.0-alpha2, this fallback will likely change from 
FpImage to Vampyre Imaging Library, see our news last weekend: 
https://castle-engine.io/wp/2021/12/18/integration-with-vampyre-imaging-library-new-example-image_display-to-test-image-loading-speed-and-format-support/
 . From the point of view of Debian, it still means we just have a fallback 
from LibPng -> some other PNG reader, with implementation contained within 
Pascal units in CGE.


To test whether CGE actually uses LibPng, just

1. add to uses clause of TestCastleImages new unit: CastleInternalPng

2. add a method like this:

"""
procedure TTestImages.TestUsingLibPng;
begin
AssertTrue(CastlePngInitialized);
end;
"""

This will make sure that CGE is actually using LibPng, not any fallback. If 
this succeeds, and other TestCastleImages methods will also succeed -> you know 
that CGE is using LibPng and that it works :)

So Debian can carry the patch adding TestUsingLibPng (if you want to require 
that CGE in Debian always uses LibPng, which is fine by me, although I don't 
want to require it in upstream). And everything else will be tested using ready 
tests in CGE, which we maintain constantly :)

Regards,
Michalis

Bug#967795: view3dscene: depends on deprecated GTK 2

[Michalis Kamburelis]

This depends on upgrading Castle Game Engine class (TCastleWindowBase) to
GTK3. See my comments in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967284 -- we will do it :)

Once the upgrade to GTK3 in Castle Game Engine is done, then view3dscene
will just be able to use it, without any additional work.

Regards,
Michalis

Bug#967284: castle-game-engine: depends on deprecated GTK 2

[Michalis Kamburelis]

Upgrade to GTK3 is planned.

It is a task inside TCastleWindowBase class (a window with OpenGL context).
The class is implemented by various platform-specific backends, in
particular the default backend on Linux right now uses GTK2 indeed.

The upgrade is not a big job. We just use GTK to easily open a window, show
the menu bar, toggle fullscreen. In the end, most of the things done by
Castle Game Engine just happen inside the big OpenGL area that fills almost
all window space, so they are completely independent from GTK.

Although I do not plan the upgrade to GTK3 in the immediate moment.
Probably not in 2020, and not for the upcoming Castle Game Engine 7.0
release. It will happen most likely in 2021. Let me know if you would like
me to prioritize this task more.

Oh, and if anyone would like to help, you're most welcome. The point of
integration between Castle Game Engine and GTK is quite localized in code
-- see the src/window/gtk code path (view on GitHub:
https://github.com/castle-engine/castle-engine/tree/master/src/window/gtk
). Pull requests are welcome :) You can implement GTK3 backend there, as
parallel to existing GTK2, so you will be able to experiment with stuff
without fear of breaking the GTK2 version.

Regards,
Michalis

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#891682: [Pkg-pascal-devel] Bug#891682: castle-game-engine: FTBFS on arm64: assorted test suite errors and failures

[Michalis Kamburelis]

 2018-04-14 12:42 GMT+02:00 Punit Agrawal :
> At this point, I suspect it's a compiler issue. I've created a
> reproducer (attached) that highlights the problem and behaves
> differently on arm64 and x86.
>
> Note: I am not at all familiar with Pascal. Input from somebody more
> familiar with the language ecosystem will be greatly appreciated.
>

Great job!

Note that in your testcase, the minimized "TRectangle.ScaleAround0"
does not set Result.Width, Result.Left in some cases. And, since this
is a record, the uninitialized fields are undefined (may contain
memory garbage).

It should not matter for the result (from what I see, the
TRectangle.Width is always guaranteed to be 0 when calling this). But
maybe writing something like

"""
   if Width <= 0 then
   begin
  Result.Width  := Width;
  Result.Left   := Left;
   end else
  Writeln('This should never happen');
"""

would make this clearer?

The testcase definitely makes sense to me, and if you get different
results on different CPUs -- then indeed we have nicely reproducible
FPC bug.

(P.S. I'm the castle-game-engine upstream author.)
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)

[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#868790: [Pkg-pascal-devel] Bug#868790: castle-game-engine: please make the build reproducible

[Michalis Kamburelis]

2017-07-18 19:00 GMT+02:00 Chris Lamb :
> Whilst working on the Reproducible Builds effort [0], we noticed
> that castle-game-engine could not be built reproducibly.
>
> This is because it uses the current year when generating a "Copyright"
> string.
>
> Patch attached.

Hi,

I have applied a modified version of your patch upstream, see
https://github.com/castle-engine/castle-engine/commit/35a19832b84c396c6c5d3521e8afd50f8055d492
(I only moved the logic to a separate function CopyrightYears, used 2
times). Thank you!

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#845504: [Pkg-pascal-devel] Bug#845504: /usr/bin/ppdep-3.0.0: Claims to understand conditional defines, but doesn't handle {$ELSE}

[Michalis Kamburelis]

> I'll take care of submitting this patch upstream too.

The patch is submitted upstream to
http://bugs.freepascal.org/view.php?id=31007 .

Regards,
Michalis

Bug#845504: [Pkg-pascal-devel] Bug#845504: /usr/bin/ppdep-3.0.0: Claims to understand conditional defines, but doesn't handle {$ELSE}

[Michalis Kamburelis]

2016-11-24 3:14 GMT+01:00 Ben Longbons :
> In the `gearhead` package, `ppdep gharena.pas` produces almost no
> output, whereas `ppdep -dSDLMODE gharena.pas` produces plenty.
>

I took a look at ppdep sources, and the fix was fortunately very
easy:) There was indeed a trivial error when recognizing the "{$else}"
directive. I'm attaching a patch.

Note: The patch was done and tested against the utils/ppdep.pp file
from upstream FPC SVN sources. Not against the FPC 3.0.0 sources from
Debian. But I suspect that the patch will apply and fix the problem
for 3.0.0 too, since the "ppdep" utility is quite old and probably
didn't change significantly in the recent years.

I'll take care of submitting this patch upstream too.

BTW, I would advice against using "ppdep" in general. Reasons:

1. It will fail to understand various other Pascal constructions.
Looking briefly at ppdep sources, it will not understand modern "{$if
xxx}" directive, it doesn't understand "{$include xxx.inc}", it
doesn't understand macros, it doesn't support "{$define xxx}" or
"{$undef xxx}"... So it will fail on various valid Pascal code anyway.

  Fixing all these issues within the current (somewhat old) ppdep code
would be uneasy. It would be probably better to rewrite ppdep using
e.g. fcl-passrc units, that take care of parsing Pascal code.

2. The utility of "ppdep" for Pascal is limited anyway. Unlike in C,
in Pascal the compiler already handles the dependencies (what unit
should be recompiled when and in what order). So generating Makefiles
with dependencies per-unit is usually not needed.

Regards,
Michalis
--- ppdep.pp	2016-11-25 06:25:52.521343605 +0100
+++ ppdep-mod.pp	2016-11-25 06:18:52.156981295 +0100
@@ -344,7 +344,7 @@
 hs^:='';
   end
 else
- if (Copy(hs^,2,6)='$ELSE') then
+ if (Copy(hs^,2,5)='$ELSE') then
   begin
 skip[level]:=skip[level-1] or (not skip[level]);
 hs^:='';

Bug#823706: [Pkg-pascal-devel] Bug#823706: lazarus opengl

[Michalis Kamburelis]

"2016-11-04 9:47 GMT+01:00 Paul Gevers :
> I don't know how to build the component without a Makefile(.fpc). Would
> it be sufficient (a little hackish) for now (as you mention a wizard) to
> just make sure that the *.lpk are included (in lcl-units-1.6 as the
> other lpk files)?

The way to compile Lazarus package is either to use Lazarus GUI, or
(from command-line) just call the "lazbuild xxx.lpk". This will call
fpc with appropriate options underneath.

That being said, simply providing sources for these packages, and
making sure they compile "out of the box" with the current Lazarus +
FPC in Debian, would be probably enough for practical uses. You can
test it e.g. by compiling Castle Game Engine package in
"packages/castle_components.lpk" -- it has the "LazOpenGLContext"
package in it's dependencies. If it compiles OK, you should be able to
compile any LCL-based example in the engine, like
"examples/lazarus/model_3d_viewer/model_3d_viewer.lpi".

All these files (applications and packages, *.lpi and *.lpk) can be
either compiled from GUI, or using the "lazbuild" from command-line.

Best regards,
Michalis

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

[Michalis Kamburelis]

  

  

  

> Packages build with CGE that NEED png  
support are soon broken in testing (the moment libpng12 is removed)  
without a way to be fixed. And fixing this bug is not enough, those  
packages need to be rebuild as well.

  

Ah, indeed, you will need to recompile and release new view3dscene binary
version. In general, every package depending on CGE needs to be recompiled in
such cases (for now, it's only view3dscene?). Even though the source code
changed only in CGE.

I see your point.  

That's how static linking works, this reasoning applies to every change in
FreePascal standard library or CGE or any other library that is traditionally
"statically compiled" in Debian. It seems like the "Build-Using" you mention
is the way to declare this.

Regards,

Michalis

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

[Michalis Kamburelis]

  

  

>  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.

>

> Not sure if I fully agree. If I understand correctly the packages that  
have a Build-Depends on cge need the Depends/Recommends on libpng (like  
view3dscene).  

  

Sure, it's correct that view3dscene "Recommends" the libpng. Because opening a
VRML/X3D file that uses a texture encoded in png is a very common case, it's
reasonable for a user to assume that "just installing view3dscene" will make
this possible.

  

And most games use png for textures/images, so they will want to "Depend" on
libpng. Otherwise they could not read png textures. (Which doesn't need to
cause a crash, a particular game may choose to turn it into a mere warning.)

What I meant to say, in my earlier mail, is that: if you somehow make a game
that doesn't use png (maybe it has no textures/images, or only in other
formats like jpg or ppm or dds), then it does not need to depend on libpng. It
will happily work on a system without libpng. So merely using CGE does not
*always* imply that you also need to have libpng at runtime.

Regards,

Michalis

Bug#820566: 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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747547: PasDoc description

[Michalis Kamburelis]

You can remove the part (up to Delphi 2006) from the description (as 
PasDoc actually supports many of the language features found in latest 
Delphi versions, as well as FreePascal).


Also, I just updated the PasDoc project page on SourceForge ( 
https://sourceforge.net/projects/pasdoc/ ), adding screenshots and a 
list of features. Feel free to use it for packaging of course :)


Michalis


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

Bug#707932: ITP: view3dscene -- 3D scene viewer written with FreePascal Lazarus

[Michalis Kamburelis]

Some small changes to the view3dscene data in this bugreport are needed, 
all send to Abou (see forum thread on 
https://sourceforge.net/p/castle-engine/discussion/general/thread/377c403d/ 
and https://code.google.com/r/michaliskambi-view3dscene-debian/ ).


For the sake of people that find this bug through google, short recap:


 Version: 4.0.1


This should be 3.12.0 (view3scene versions are separate from Castle Game 
Engine versions).



 URL: http://castle-engine.sourceforge.net


More specific URL is http://castle-engine.sourceforge.net/view3dscene.php


 License: LGPL-2 + extention allowing statically linking to non free 
software


This should be GPL (view3dscene, unlike Castle Game Engine, is only 
under strict GPL).


Regards,
Michalis


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

Bug#706408: ITP: castle-game-engine -- 3D game engine for FreePascal Lazarus

[Michalis Kamburelis]

URL: http://castle-engine.sourceforge.ne


This URL misses final t of course :), it should be 
http://castle-engine.sourceforge.net/ . The engine description 
(downloads, documentation, details about license) are on subpage 
http://castle-engine.sourceforge.net/engine.php .



 License: LGPL-2 + extention allowing statically linking to non free software


It may be worth mentioning that this is exactly the same license as used 
for FPC and Lazarus units (FPC RTL, Lazarus LCL). And FPC and Lazarus 
are already packaged by Debian :)


Regards,
Michalis


--
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571549: Confirming #571549 is fixed in lives 1.2.1

[Michalis Kamburelis]

Ah thanks, I can confirm that the problems are gone in lives 1.2.1-1 (in
current testing). Opening files without extension works correctly (and
when it's a video file, it's even correctly recognized based on it's
content and loaded).

Please close as appropriate.

Michalis



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

Bug#564111: Confirming #564113 and #564111

[Michalis Kamburelis]

Thanks a lot, both Vincent and Shawn, for fixing! It's nice to get back
from a break and see your bugs gone :)

I just tested both SVN trunk from
http://nifelheim.dyndns.org/~cocidius/dds/, and latest Debian package
(2.0.9-1 from unstable, build by apt-get source...). Both bugs are
gone in both cases, so it's all fixed now for me :)

Thanks,
Michalis



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

Bug#572393: docbookwiki: When notes need not be approved, hide approval warnings for visitors

[Michalis Kamburelis]

Package: docbookwiki
Version: 0.9.1cvs-12
Severity: normal
Tags: patch

Even when you set in /etc/docbookwiki/books.conf WEBNOTES_APPROVE='false',
the user still sees a warning (when clicking on notes, add a new note)
that After you add your note, it will be queued for approval by a moderator..

I modified my /usr/share/docbookwiki/web_app/boxes/webnotes/edit/help.html
as below to fix this. This looks at WEBNOTES_APPROVE value and
shows the warning only if it's exactly 'true'. (There are other checks
around in .html files that check like this for true value, so I guess it's
Ok to expect that true value is always exactly literally spelled as 'true'
in the config file.)

/usr/share/docbookwiki/web_app/boxes/webnotes/edit/help.html contents:
--
div class=note
xmpT_(HTML tags that are allowed:) 
lt;bgt;lt;igt;lt;agt;lt;brgt;lt;pgt;lt;olgt;lt;ulgt;lt;ligt;lt;hrgt;lt;pregt;lt;xmpgt;
if condition=('{{WEBNOTES_APPROVE}}'=='true')
T_(After you add your note, it will be queued for approval by a 
moderator.)/if/xmp
/div
--

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
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 [htt 2.2.14-4Apache HTTP Server - traditional n
ii  dblatex  0.2.12-2Produces DVI, PostScript, PDF docu
ii  debconf [debconf-2.0]1.5.28  Debian configuration management sy
ii  docbook-dsssl1.79-6  modular DocBook DSSSL stylesheets,
ii  docbook-utils0.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-3   stylesheets for processing DocBook
ii  gawk 1:3.1.6.dfsg-4  GNU awk, a pattern scanning and pr
ii  jadetex  3.13-10 generator of printable output from
ii  libapache2-mod-php5  5.2.11.dfsg.1-2 server-side, HTML-embedded scripti
ii  libxml2-utils2.7.6.dfsg-1XML utilities
ii  mysql-server 5.1.41-3MySQL database server (metapackage
ii  mysql-server-5.1 [mysql- 5.1.41-3MySQL database server binaries
ii  openssl  0.9.8k-7Secure Socket Layer (SSL) binary a
ii  php5-cli 5.2.11.dfsg.1-2 command-line interpreter for the p
ii  php5-mysql   5.2.11.dfsg.1-2 MySQL module for php5
ii  subversion   1.6.3dfsg-1 Advanced version control system
ii  sudo 1.7.2p1-1   Provide limited super user privile
ii  svn-load 1.2-1   An enhanced import facility for Su
ii  swish-e  2.4.7-1 Simple Web Indexing System for Hum
ii  xmltex   1.9.debian.1-2  TeX package for processing XML fil
ii  xmlto0.0.23-2XML-to-any converter
ii  xsltproc 1.1.26-1XSLT command line processor

docbookwiki recommends no packages.

docbookwiki suggests no packages.

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

-- debsums errors found:
debsums: changed file /usr/share/docbookwiki/content/downloads/dblatex.sh (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/web_app/append/append.html (from 
docbookwiki package)
debsums: changed file 
/usr/share/docbookwiki/web_app/boxes/webnotes/edit/help.html (from docbookwiki 
package)
debsums: changed file /usr/share/docbookwiki/search/search.sh (from docbookwiki 
package)
debsums: changed file /usr/share/docbookwiki/search/make_index.sh (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/main/footer.html (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/main/header.html (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/main/main.html (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/docbook/langs/langs.html 
(from docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/docbook/docbook.css 
(from docbookwiki package)
debsums: changed file /usr/share/docbookwiki/css/view/contents.css (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/css/main.css (from docbookwiki 
package)
debsums: changed file /usr/share/docbookwiki/css/view.css (from docbookwiki 
package)
debsums: changed file 
/usr/share/docbookwiki/xsl_transform/cache/content_html/section.xsl (from 

Bug#572395: docbookwiki: Requires magic_quotes_gpc Off

[Michalis Kamburelis]

Package: docbookwiki
Version: 0.9.1cvs-12
Severity: normal

You really need php magic_quotes_gpc turned *off* for docbookwiki,
as docbookwiki cannot strip the additional backslashes by itself.
When magic quotes are on, editing may introduce backslashes
into the content (especially in DocBook format, where usually you
have a lot of  characters that will get converted to \ by magic quotes).
This makes content invalid, usually making invalid XML that cannot
be processed anymore.

Typical result is seeing errors like this when pressing save
after editing in the DocBook format:


h1Transformation Error/h1
xmp/tmp/dbwiki_6UM0Fq:7: parser error : AttValue:  or ' expected
  paracomment0/comment ulink url=\http://www.wroclaw.pl/m70276/\/ /pa
^
...
unable to parse /tmp/dbwiki_6UM0Fq
-

This bites you especially since the default php.ini (/etc/php5/apache2/php.ini,
php5 + apache2 using apache module) has magic_quotes_gpc turned On.

I added these lines to my /etc/apache2/conf.d/docbookwiki.conf and
they nicely fix the problem:

--
DirectoryMatch /usr/share/docbookwiki/

  # With magic quotes on, editing may introduce backslashes
  # into the content (especially in DocBook format, where usually you
  # have a lot of  characters that will get converted to \ by magic quotes).
  # This makes content invalid, usually making invalid XML that cannot
  # be processed anymore.

  IfModule mod_php5.c
  php_flag magic_quotes_gpc Off
  /IfModule
/DirectoryMatch
--

(Probably the same clause should be added for php4, under IfModule mod_php4.c.
Or maybe IfModule mod_php5.c can be removed entirely, but this
would make the config files invalid when php module is turned off
(docbookwiki doesn't work without php anyway, but still...).)

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
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 [htt 2.2.14-4Apache HTTP Server - traditional n
ii  dblatex  0.2.12-2Produces DVI, PostScript, PDF docu
ii  debconf [debconf-2.0]1.5.28  Debian configuration management sy
ii  docbook-dsssl1.79-6  modular DocBook DSSSL stylesheets,
ii  docbook-utils0.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-3   stylesheets for processing DocBook
ii  gawk 1:3.1.6.dfsg-4  GNU awk, a pattern scanning and pr
ii  jadetex  3.13-10 generator of printable output from
ii  libapache2-mod-php5  5.2.11.dfsg.1-2 server-side, HTML-embedded scripti
ii  libxml2-utils2.7.6.dfsg-1XML utilities
ii  mysql-server 5.1.41-3MySQL database server (metapackage
ii  mysql-server-5.1 [mysql- 5.1.41-3MySQL database server binaries
ii  openssl  0.9.8k-7Secure Socket Layer (SSL) binary a
ii  php5-cli 5.2.11.dfsg.1-2 command-line interpreter for the p
ii  php5-mysql   5.2.11.dfsg.1-2 MySQL module for php5
ii  subversion   1.6.3dfsg-1 Advanced version control system
ii  sudo 1.7.2p1-1   Provide limited super user privile
ii  svn-load 1.2-1   An enhanced import facility for Su
ii  swish-e  2.4.7-1 Simple Web Indexing System for Hum
ii  xmltex   1.9.debian.1-2  TeX package for processing XML fil
ii  xmlto0.0.23-2XML-to-any converter
ii  xsltproc 1.1.26-1XSLT command line processor

docbookwiki recommends no packages.

docbookwiki suggests no packages.

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

-- debsums errors found:
debsums: changed file /usr/share/docbookwiki/content/downloads/dblatex.sh (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/web_app/append/append.html (from 
docbookwiki package)
debsums: changed file 
/usr/share/docbookwiki/web_app/boxes/webnotes/edit/help.html (from docbookwiki 
package)
debsums: changed file /usr/share/docbookwiki/search/search.sh (from docbookwiki 
package)
debsums: changed file /usr/share/docbookwiki/search/make_index.sh (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/main/footer.html (from 
docbookwiki 

Bug#571549: Opening filename without any extension crashes lives

[Michalis Kamburelis]

Package: lives
Version: 1.1.8-2
Severity: normal

Open any filename without an extension (I tried and was able to crash with
text file README, empty file foo, and avi file video) --- lives crashes.
I simply open the file using Open File menu item.

$ touch foo
$ lives -debug

LiVES 1.1.8
Copyright 2002-2009 Gabriel Finch (salsa...@xs4all.nl) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.


Unfortunately LiVES crashed.
Please report this bug at 
http://sourceforge.net/tracker/?group_id=64341atid=507139
Thanks. Recovery should be possible if you restart LiVES.


When reporting crashes, please include details of your operating system, 
distribution, and the LiVES version (1.1.8)
and any information shown below:

#0  0xb7efc424 in __kernel_vsyscall ()
#1  0xb744af0b in waitpid () from /lib/i686/cmov/libpthread.so.0
#2  0xb7746a6a in g_on_error_stack_trace () from /lib/libglib-2.0.so.0
#3  0x08058c4b in ?? ()
#4  signal handler called
#5  0xb69f4cd0 in ?? () from /tmp/livestmp//520151788/dv_decoder.so
#6  0xb69f5013 in get_clip_data () from /tmp/livestmp//520151788/dv_decoder.so
#7  0x0806b062 in ?? ()
#8  0x080f5df5 in ?? ()
#9  0x080f681f in ?? ()
#10 0x0813018f in ?? ()
#11 0xb7806544 in g_cclosure_marshal_VOID__VOID ()
#12 0xb77f8de3 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0xb780cf0f in ?? () from /usr/lib/libgobject-2.0.so.0
#14 0xb780e359 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#15 0xb780e7b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#16 0xb7b99b7a in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb7dca729 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb7c58293 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#19 0xb77f8de3 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#20 0xb780cf0f in ?? () from /usr/lib/libgobject-2.0.so.0
#21 0xb780e359 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#22 0xb780e7b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#23 0xb7d52d98 in gtk_tree_view_row_activated ()
#24 0xb7d650ab in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#25 0xb7c59f66 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#26 0xb77f7569 in ?? () from /usr/lib/libgobject-2.0.so.0
#27 0xb77f8de3 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#28 0xb780cbb7 in ?? () from /usr/lib/libgobject-2.0.so.0
#29 0xb780e1ef in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#30 0xb780e7b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#31 0xb7d761b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#32 0xb7c526fc in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#33 0xb7c53b77 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#34 0xb7adc57a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#35 0xb776cf28 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#36 0xb77706b3 in ?? () from /lib/libglib-2.0.so.0
#37 0xb7770b7a in g_main_loop_run () from /lib/libglib-2.0.so.0
#38 0xb7c53f09 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#39 0x0805dde9 in ?? ()
#40 0xb72ecb55 in __libc_start_main (main=0x805d880, argc=2, 
#41 0x08054dd1 in ?? ()

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
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 lives depends on:
ii  frei0r-plugins  1.1.22git20090409-2  minimalistic plugin API for video 
ii  imagemagick 7:6.5.8.3-1  image manipulation programs
ii  libasound2  1.0.21a-1shared library for ALSA applicatio
ii  libatk1.0-0 1.28.0-1 The ATK accessibility toolkit
ii  libavc1394-00.5.3-1+b2   control IEEE 1394 audio/video devi
ii  libc6   2.10.2-2 GNU C Library: Shared libraries
ii  libcairo2   1.8.8-2  The Cairo 2D vector graphics libra
ii  libdv4  1.0.0-2  software library for DV format dig
ii  libfontconfig1  2.8.0-2  generic font configuration library
ii  libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii  libglib2.0-02.22.3-1 The GLib library of C routines
ii  libgtk2.0-0 2.18.3-1 The GTK+ graphical user interface 
ii  libjack00.118+svn3796-1  JACK Audio Connection Kit (librari
ii  libogg0 1.1.4~dfsg-2 Ogg bitstream library
ii  liboil0.3   0.3.16-1 Library of Optimized Inner Loops
ii  libpango1.0-0   1.26.2-1 Layout and rendering of internatio
ii  libpulse0   0.9.21-1 PulseAudio client libraries
ii  libraw1394-11   2.0.4-1  library for direct access to IEEE 
ii  libsdl1.2debian 1.2.13-5  

Bug#569522: docbookwiki: Invalid URLs in default template files

[Michalis Kamburelis]

Package: docbookwiki
Version: 0.9.1cvs-12
Severity: normal

Entering Approve page (from /books/edit.php) makes two warnings in apache 
error.log:

  File does not exist: /usr/share/docbookwiki/templates/docbook/view/view.css, 
referer: [snip]/templates/docbook/approve/revisions/revisions.css

  File does not exist: /usr/share/docbookwiki/graphics/x-header-background.png, 
referer: [snip]/edit.php

To fix the 1st one: change in 
/usr/share/docbookwiki/templates/docbook/approve/revisions/revisions.css line

  @import url(../../view/view.css);

to

  @import url(../../../../css/view.css);

(This fixes the warning, as the URL to view.css is now valid. I don't know if 
this is really needed, i.e. is view.css needed at all on approve pages.)

To fix the 2nd one: change in /usr/share/docbookwiki/templates/main/header.html 
x-header-background.png to header-background.png (remove the x-). Unless this 
is deliberate (you didn't want to show header background by default), but then 
this should be done better (to remove also header-background.png from 
admin.php, and to comment it out without causing warnings about invalid URLs in 
apache logs).

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
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 [htt 2.2.14-4Apache HTTP Server - traditional n
ii  dblatex  0.2.12-2Produces DVI, PostScript, PDF docu
ii  debconf [debconf-2.0]1.5.28  Debian configuration management sy
ii  docbook-dsssl1.79-6  modular DocBook DSSSL stylesheets,
ii  docbook-utils0.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-3   stylesheets for processing DocBook
ii  gawk 1:3.1.6.dfsg-4  GNU awk, a pattern scanning and pr
ii  jadetex  3.13-10 generator of printable output from
ii  libapache2-mod-php5  5.2.11.dfsg.1-2 server-side, HTML-embedded scripti
ii  libxml2-utils2.7.6.dfsg-1XML utilities
ii  mysql-server 5.1.41-3MySQL database server (metapackage
ii  mysql-server-5.1 [mysql- 5.1.41-3MySQL database server binaries
ii  openssl  0.9.8k-7Secure Socket Layer (SSL) binary a
ii  php5-cli 5.2.11.dfsg.1-2 command-line interpreter for the p
ii  php5-mysql   5.2.11.dfsg.1-2 MySQL module for php5
ii  subversion   1.6.3dfsg-1 Advanced version control system
ii  sudo 1.7.2p1-1   Provide limited super user privile
ii  svn-load 1.2-1   An enhanced import facility for Su
ii  swish-e  2.4.7-1 Simple Web Indexing System for Hum
ii  xmltex   1.9.debian.1-2  TeX package for processing XML fil
ii  xmlto0.0.23-2XML-to-any converter
ii  xsltproc 1.1.26-1XSLT command line processor

docbookwiki recommends no packages.

docbookwiki suggests no packages.

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

-- debsums errors found:
debsums: changed file /usr/share/docbookwiki/content/downloads/dblatex.sh (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/web_app/append/append.html (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/search/search.sh (from docbookwiki 
package)
debsums: changed file /usr/share/docbookwiki/search/make_index.sh (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/main/footer.html (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/main/header.html (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/main/main.html (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/docbook/langs/langs.html 
(from docbookwiki package)
debsums: changed file /usr/share/docbookwiki/templates/docbook/docbook.css 
(from docbookwiki package)
debsums: changed file /usr/share/docbookwiki/css/view/contents.css (from 
docbookwiki package)
debsums: changed file /usr/share/docbookwiki/css/main.css (from docbookwiki 
package)
debsums: changed file /usr/share/docbookwiki/css/view.css (from docbookwiki 
package)



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

Bug#564111: gimp-dds: Dark 1x1 mipmap for 2D texture

[Michalis Kamburelis]

Package: gimp-dds
Version: 2.0.7-1
Severity: normal

Open this file
https://vrmlengine.svn.sourceforge.net/svnroot/vrmlengine/trunk/kambi_vrml_test_suite/textures/016marbre.jpg
and save as DDS, checking Generate mipmaps (everything else default).
Look at mipmaps in the resulting file (e.g. open saved file back by
gimp-dds). The lowest 1x1 mipmap contains one almost black (color is
#1d1c1c) pixel.

Which is wrong --- the base image is obviously mostly white, so the
final 1x1 mipmap should be much lighter. Also, all the colors on
previous 2x2 mipmap are much *lighter* than #1d1c1c.

So something went wrong when generating (at least) this mipmap level.
Not sure whether 2x2 level is 100% correct either (it's a little too
dark anyway, although not as black).

My resulting DDS file is on
http://michalis.ii.uni.wroc.pl/~michalis/tmp/016marbre_with_mipmaps.dds

I also tried selecting both mipmaps and DXT1 compression, result is here:
http://michalis.ii.uni.wroc.pl/~michalis/tmp/016marbre_s3tc_with_mipmaps.dds
Result with S3TC compression has the same problem, so this
problem is not related to S3TC.

Oh, and I tested reading these DDS files with my own programs, and yes,
the last mipmap level *is* almost black. So it's not a problem in DDS
reader --- trouble happens at DDS writing, when mipmaps are generated.

Versions:

I initially saw both problems with 2.0.7 (more precisely, 2.0.7-1
version of Debian package gimp-dds). I checked out and compiled trunk
(from http://nifelheim.dyndns.org/svn/gimp-dds/trunk ) and both bugs are
still there. (I don't see any changes in SVN since around the 2.0.7
release anyway.)

My gimp version is 2.6.7-1.1.

Submitted by email to upsteam author (mail at the bottom of
http://nifelheim.dyndns.org/~cocidius/dds/), without an answer,
so resubmitting to Debian hoping for a fix :)



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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
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 gimp-dds depends on:
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libgimp2.02.6.7-1.1  Libraries for the GNU Image Manipu
ii  libglib2.0-0  2.22.3-1   The GLib library of C routines
ii  libgtk2.0-0   2.18.3-1   The GTK+ graphical user interface 

gimp-dds recommends no packages.

gimp-dds suggests no packages.

-- no debconf information



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

Bug#564113: gimp-dds: Invalid borders generated around cubemap mipmaps

[Michalis Kamburelis]

Package: gimp-dds
Version: 2.0.7-1
Severity: normal

Open this file
https://vrmlengine.svn.sourceforge.net/svnroot/vrmlengine/trunk/kambi_vrml_test_suite/textures/castle_end_sequence.dds
Save as DDS selecting Generate mipmaps (all else by default, As Cube
Map is correctly selected as default). Open resulting DDS with mipmaps,
and you can see that all generated mipmaps have a non-matching 1-pixel
wide borders at the bottom and right (upper and left borders are Ok).

I guess when generating mipmaps, they take from the wrong side of cube
map for reference.

castle_end_sequence.dds is oriented correctly, as far as I know,
following Direct X left-handed (which seems to be standard for DDS)
orientation. Changing orientation to OpenGL right-handed (swapping
negative and positive Y) doesn't help, the invalid borders are still
generated (and always at the lower and right side of the mipmap).

I tested also on cubemaps included in
http://developer.amd.com/gpu/cubemapgen/pages/default.aspx , to make
sure it's not the fault of my castle_end_sequence.dds. And generating
mipmaps for them (e.g. Textures/CubeMaps/BlueSky512.dds) by gimp-dds
makes the same bug.

My resulting DDS file is on
https://vrmlengine.svn.sourceforge.net/svnroot/vrmlengine/trunk/kambi_vrml_test_suite/textures/castle_end_sequence_with_mipmaps.dds

I made a similar test with S3TC:
https://vrmlengine.svn.sourceforge.net/svnroot/vrmlengine/trunk/kambi_vrml_test_suite/textures/castle_end_sequence_s3tc_with_mipmaps.dds
and the S3TC version has the same problem. So this doesn't seem
related to S3TC. I also read these files by my own code, and the ugly
border is there --- so, again, the bug seems to happen when generating
mipmaps (not when reading DDS file).

Versions:
(exactly like my previous bug report today to gimp-dds):

I initially saw both problems with 2.0.7 (more precisely, 2.0.7-1
version of Debian package gimp-dds). I checked out and compiled trunk
(from http://nifelheim.dyndns.org/svn/gimp-dds/trunk ) and both bugs are
still there. (I don't see any changes in SVN since around the 2.0.7
release anyway.)

My gimp version is 2.6.7-1.1.

Submitted by email to upsteam author (mail at the bottom of
http://nifelheim.dyndns.org/~cocidius/dds/), without an answer,
so resubmitting to Debian hoping for a fix :)



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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
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 gimp-dds depends on:
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libgimp2.02.6.7-1.1  Libraries for the GNU Image Manipu
ii  libglib2.0-0  2.22.3-1   The GLib library of C routines
ii  libgtk2.0-0   2.18.3-1   The GTK+ graphical user interface 

gimp-dds recommends no packages.

gimp-dds suggests no packages.

-- no debconf information



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

Bug#451258: fixed

[Michalis Kamburelis]

Sylvestre Ledru wrote:
 I did some tests, it seems that it works with current trunk (which is
 great anyway :) ). But it doesn't work with released 0.95 version.
 I tested with FOP 0.95 from Debian unstable packages (1:0.95.dfsg-4),
 then binary 0.95 from upstream, and testcase failed just the same, i.e.
 the first footnote is missing, as far as I saw.
 Maybe it is a font issue.
 As attachement, you will find the PDF and a screenshot of it.
 

Your attached PDF shows the same bug (and your screenshot doesn't show
the interesting part of the page). The bug is about showing the
footnotes text at the bottom of the page. In your PDF, I see at the
bottom of the page only the 2 Second footnote, missing the 1 First
footnote text (looked at pdf with evince and xpdf, so I don't think
it's an issue with my pdf viewer?).

See attached PNGs showing the buggy and correct (from FOP trunk)
renderings of the bottom of the page.

Michalis
inline: bug.pnginline: correct_from_fop_trunk.png

Bug#451258: fop: footnote inside varlistentry is not rendered in PDF output

[Michalis Kamburelis]

Michael Koch wrote:
 On Thu, Nov 15, 2007 at 01:09:10PM +0100, Michalis Kamburelis wrote:
 The same problem occurs with footnotes in orderedlist, for a test just try

 orderedlist
   listitemparaThird footnote from ordered list
 footnoteparaThird footnote./para/footnote/para
   /listitem
 /orderedlist
 
 Was this fixed with the fop 0.94 update? Can you still reproduce this?
 

I upgraded to fop 1:0.94.dfsg-1 in unstable and yes, the bug is still
present.

Some details about this bug that I found in the meantime:

1. It affects footnotes in all variablelist, glosslist,
orderedlist, itemizedlist DocBook elements.

2. If you're working with variablelist or glosslist, then there is
one workaround: you can set variablelist.as.blocks and
glosslist.as.blocks XSL parameters (like

  xsl:param name=variablelist.as.blocks1/xsl:param
  xsl:param name=glosslist.as.blocks1/xsl:param

). This way variablelist and glosslist are not formatted as real
lists in XML-FO files, and footnotes from there work OK. But this also
changes the look of these elements in PDF output, so it may not be
desirable.

Unfortunately, this doesn't help at all if you want to make footnotes
from orderedlist or itemizedlist.

3. It turns out this is a known problem with FOP, see
http://xmlgraphics.apache.org/fop/knownissues.html (search for text
Footnotes swallowed in lists) and
http://issues.apache.org/bugzilla/show_bug.cgi?id=37579

I hope this info helps others that are affected by this bug...

Michalis



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451258: fop: footnote inside varlistentry is not rendered in PDF output

[Michalis Kamburelis]

The same problem occurs with footnotes in orderedlist, for a test just try

orderedlist
  listitemparaThird footnote from ordered list
footnoteparaThird footnote./para/footnote/para
  /listitem
/orderedlist



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451258: fop: footnote inside varlistentry is not rendered in PDF output

[Michalis Kamburelis]

Package: fop
Version: 1:0.93.dfsg.1-2
Severity: normal

Take this DocBook file:
  http://michalis.ii.uni.wroc.pl/~michalis/tmp/a.xml
Convert to XML-FO by:
  xsltproc -o a.fo /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/fo/docbook.xsl 
a.xml

(using --stringparam fop1.extensions 1 doesn't change the bug).
Then convert it to PDF by

  fop -fo a.fo a.pdf

This produces this PDF output:
  http://michalis.ii.uni.wroc.pl/~michalis/tmp/a.pdf

which lacks the first footnote. The a.fo file contains both footnotes.
Also HTML output (by
  xmlto html a.xml -x 
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/html/chunk.xsl
) contains both footnotes. So I guess the problem is in FOP.
This construct once worked in some FOP 0.20.x version.

Even if you remove the second footnote,
the bug stays --- so the first footnote is not somehow hidden by
the second footnote. I added second footnote only to show that
footnote from normal paragraph (outside of DocBook's varlistentry)
works OK.

I'm using fop with sun-java6 (with gcj it fails badly, I assume that's
known problem).

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

Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages fop depends on:
ii  gij [java2-runtim 4:4.2.1-6  The GNU Java bytecode interpreter
ii  gij-4.1 [java2-ru 4.1.2-16   The GNU Java bytecode interpreter
ii  gij-4.2 [java2-ru 4.2.1-5The GNU Java bytecode interpreter
ii  libavalon-framewo 4.2.0-4Common framework for Java server a
ii  libbatik-java 1.6-3  xml.apache.org SVG Library
ii  libbsf-java   1:2.3.0+cvs20050308a-2 Bean Scripting Framework to suppor
ii  libcommons-io-jav 1.3.2-2Common useful IO related classes
ii  libcommons-loggin 1.1-1  commmon wrapper interface for seve
ii  libxalan2-java2.7.0-5XSL Transformations (XSLT) process
ii  libxerces2-java   2.8.1-2Validating XML parser for Java wit
ii  libxmlgraphics-co 1.1.dfsg.2-1   reusable components used by Batik 
ii  libxp61:1.0.0.xsf1-1 X Printing Extension (Xprint) clie
ii  libxt61:1.0.5-3  X11 toolkit intrinsics library
ii  libxtst6  2:1.0.3-1  X11 Testing -- Resource extension 
ii  sun-java6-jre [ja 6-00-2 Sun Java(TM) Runtime Environment (

fop recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#435754: libopenal0a: WAV file generated by waveout device is invalid

[Michalis Kamburelis]

Package: libopenal0a
Version: 1:0.0.8-5
Severity: normal

A sample WAV file generated by tremulous (when ~/.openalrc
contained ( define devices '(waveout) )) is on
http://www.camelot.homedns.org/~michalis/tmp/openal-1.wav

This is not a correct WAV file. Trying to play it with gstreamer:

$ gst-launch filesrc location=openal-1.wav ! wavparse ! audioconvert ! 
audioresample ! alsasink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /pipeline0/wavparse0: GStreamer encountered a general 
stream error.
Additional debug info:
gstwavparse.c(1346): gst_wavparse_stream_headers (): /pipeline0/wavparse0:
Stream claims av_bsp = 22050, which is more than 0 - invalid data
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...

Consequently, trying to play it with totem crashes totem.

Some programs are able to handle it, e.g. sox.
Converting it through sox like
  sox openal-1.wav newopenal-1.wav
produces valid WAV file (playable by everything).

Investigating WAV file with my own WAV file reader, I see that the
WAV file is invaild because ChunkSize recorded in file header is
too large: ChunkSize recorded in main RIFF chunk should not include
the 8 bytes needed for ChunkId and ChunkSize itself. Practically
speaking, for all WAV files, ChunkSize should always be the size
of the WAV file minus 8 bytes. See e.g.
[http://ccrma.stanford.edu/courses/422/projects/WaveFormat/]
for description of WAV file format.

But in WAV files generated by OpenAL waveout device, ChunkSize
is always exactly equal to the size of the file. So the WAV file
is invalid, although some programs don't notice it: if you read
WAV file without paying attention to ChunkSize recoded in RIFF chunk,
or if you just stop reading after data chunk, you will not notice
the problem. But if your program tries to read all chunks within
WAV file, then it will notice that the WAV file ends unexpectedly,
since ChunkSize indicates that 8 more bytes should be available.

That's my analysis... But I didn't find in OpenAL code where this
should be fixed.

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

Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core)
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash

Versions of packages libopenal0a depends on:
ii  libc6 2.6-2  GNU C Library: Shared libraries

libopenal0a recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#426476: fop-ttfreader needs commons-logging.jar and commons-io.jar on classpath

[Michalis Kamburelis]

Arnaud Vandyck wrote:
[...]
 
 Thanks for your bug, can you try the attached fop-ttfreeader.sh script?
 

There's a problem in attached script --- $LOCALCLASSPATH will have all
dirs glued without any separator, so the script will fail to find any
fop-related class.

I added

  pathSepChar=:

on line 33, and then your script works fine.

Cheers,
Michalis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#425064: 0.93 don't works with asciidoc anymore

[Michalis Kamburelis]

 SCHWERWIEGEND: Exception
 javax.xml.transform.TransformerException: org.apache.fop.apps.FOPException: 
 file:/home/formorer/hg/grml-infrastructure/./repo-cookbook.fo:2:25403: 
 Error(2/25403): No element mapping
  definition found for (Namespace URI: http://xml.apache.org/fop/extensions;, 
 Local Name: destination)

Maybe you generate your FO file with fop.extensions parameter set to 1 ?

Then you should set fop.extensions to 0. With fop.extensions set to 1,
current stylesheets will generate fox:destination elements that are not
understood by FOP 0.93. See the bottom of
[http://xmlgraphics.apache.org/fop/0.93/upgrading.html]. And
[http://www.mail-archive.com/[EMAIL PROTECTED]/msg07229.html].

Michalis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#426476: fop-ttfreader needs commons-logging.jar and commons-io.jar on classpath

[Michalis Kamburelis]

Package: fop
Version: 1:0.93.dfsg.1-1
Severity: normal


fop-ttfreader script needs commons-logging.jar and commons-io.jar in CLASSPATH, 
just like the fop script for FOP 0.93. Otherwise I get errors like below.

(missing commons-logging.jar:)

  $ fop-ttfreader /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf 
dejavusans-bold.xml
  Exception in thread main java.lang.NoClassDefFoundError: 
org/apache/commons/logging/LogFactory
  at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:116)

(after adding commons-logging.jar, still missing commons-io.jar)

  $ fop-ttfreader /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf 
dejavusans-bold.xml
  TTF Reader for Apache FOP 0.93

  Parsing font...
  Reading /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf...
  Exception in thread main java.lang.NoClassDefFoundError: 
org/apache/commons/io/IOUtils
  at 
org.apache.fop.fonts.truetype.FontFileReader.init(FontFileReader.java:45)
  at 
org.apache.fop.fonts.truetype.FontFileReader.init(FontFileReader.java:60)
  at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:205)
  at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:161)

After adding
  :$JAVASH/commons-logging.jar:$JAVASH/commons-io.jar
inside export CLASSPATH=... line, everything works fine.

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

Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core)
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash

Versions of packages fop depends on:
ii  gij-4.1 [java2-ru 4.1.1-20   The GNU Java bytecode interpreter
ii  java-gcj-compat-d 1.0.65-10  Java runtime environment with GCJ
ii  libavalon-framewo 4.2.0-3Common framework for Java server a
ii  libbatik-java 1.6-3  xml.apache.org SVG Library
ii  libbsf-java   1:2.3.0+cvs20050308a-2 Bean Scripting Framework to suppor
ii  libcommons-io-jav 1.3.1.dfsg.1-1 Common useful IO related classes
ii  libcommons-loggin 1.0.4-5commmon wrapper interface for seve
ii  libxalan2-java2.7.0-4XSL Transformations (XSLT) process
ii  libxerces2-java   2.8.1-2Validating XML parser for Java wit
ii  libxmlgraphics-co 1.1.dfsg.2-1   reusable components used by Batik 
ii  libxp61:1.0.0.xsf1-1 X Printing Extension (Xprint) clie
ii  libxt61:1.0.5-2  X11 toolkit intrinsics library
ii  libxtst6  1:1.0.1-5  X11 Testing -- Resource extension 
ii  sun-java6-jre [ja 6-00-2 Sun Java(TM) Runtime Environment (

fop recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]