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

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

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.

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: $

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

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

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

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

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

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

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

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

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,

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

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

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

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

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#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 +

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

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

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 >

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

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

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

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

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,

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

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

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

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

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)?

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

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

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

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

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

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

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 >

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

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 > > (&

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

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

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

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

Bug#967284: [Pkg-pascal-devel] Bug#967284: castle-game-engine: depends on deprecated GTK 2

cking 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 inst

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

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

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