Bug#1061418: [Pkg-pascal-devel] Bug#1061418: castle-game-engine: please add support for loong64
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
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
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
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
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
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
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
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
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
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)
"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
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
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
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
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
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
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}
> 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}
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
"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
> 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
> 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
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
> 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, 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"
> 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"
> 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"
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]