Upstream note: The unit CastleTextureFont_DejaVuSansMonoBold_15 was
distributed in the older Castle Game Engine versions. It is not
distributed anymore, which explains this issue -- trying to build
older view3dscene (4.2.0) using newer CGE (7.0~alpha.3+dfsg1-1) will
indeed fail.
The unit was remov
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/packa
g 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:
> &g
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
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 compa
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/
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 addition
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 op
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
> > ("Us
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 Co
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 l
"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
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 $
2018-01-18 20:56 GMT+01:00 Michalis Kamburelis :
> So, we should get to the point where CGE (or any other package
> using fpmake) can be compiled by simple
>
> ~~~
> unset FPCDIR
> fpc fpmake.pp
> ./fpmake # without any additional options like --globalunitdir
> ~~~
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"
s
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_6
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 modif
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
> 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
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
"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
> 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 view3dsc
> > 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
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 i
> 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, li
> @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
> 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 TMsgD
> 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
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 a
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-
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
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/ ), addin
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 bu
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 +
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 (h
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, em
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 c
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
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.
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
Co
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
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).
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 s
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
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
>>
>>
>> Third footnote from ordered list
>> Third footnote.
>>
>>
>
The same problem occurs with footnotes in orderedlist, for a test just try
Third footnote from ordered list
Third footnote.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 th
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-l
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=":"
o
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
> 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";,
51 matches
Mail list logo
