Bug#1066100: Acknowledgement (freeciv: new cities unmanageable in a long game)

[Marko Lindqvist]

On Tue, 12 Mar 2024 at 18:42, Giacomo Mulas  wrote:

> Please find attached a saved game on which the bug can be seen.
> Just load the saved game with freeciv and look for the cities of
> Oberhausen or Bischweiler, and try e.g. to change the production in any of
> them, it will not be possible (or at least it is impossible here!).
>
> Bye, thanks in advance
> Giacomo
>

 Reproduced in upstream 3.1 branch, and opened a ticket about other, but
likely related, error messages I saw in the process:
https://redmine.freeciv.org/issues/304


 - ML

Bug#1056916: freeciv fails to load saved games

[Marko Lindqvist]

 This fix works at least in my tests.
 And it turned out to be a bit more complex than I thought, and it was on
the loading side after all.


 - ML
From 56d18b3c06e3c3b61908da30ab130d62f3e0e85d Mon Sep 17 00:00:00 2001
From: Marko Lindqvist 
Date: Mon, 27 Nov 2023 01:29:52 +0200
Subject: [PATCH] Reserve space for terminating NULL on astr_buffer

Growing the buffer was always considered a failure,
as it was one byte too small even after giving out
the requested size.

Reported by Giacomo Mulas

Debian Bug#1056916

Signed-off-by: Marko Lindqvist <
---
 utility/astring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utility/astring.c b/utility/astring.c
index 44d39f582c..cfcb67565f 100644
--- a/utility/astring.c
+++ b/utility/astring.c
@@ -234,8 +234,8 @@ static inline void astr_vadd_at(struct astring *astr, size_t at,
   va_copy(copy, ap);
 
   req_len = fc_vsnprintf(buffer, buffer_size, format, ap);
-  if (req_len > buffer_size) {
-buffer = astr_buffer_grow(req_len, _size);
+  if (req_len + 1 > buffer_size) {
+buffer = astr_buffer_grow(req_len + 1, _size);
 /* Even if buffer is *still* too small, we fill what we can */
 req_len = fc_vsnprintf(buffer, buffer_size, format, copy);
 if (req_len > buffer_size) {
-- 
2.42.0

Bug#1056916: freeciv fails to load saved games

[Marko Lindqvist]

 I confirmed the issue upstream. Our bugtracker is currently down, so
there's no upstream ticket to link to yet.

 The problem is on the saving side, not loading. Unfortunately this means
that some information is permanently lost, i.e., one will not be able to
load those saved games even after the bug gets fixed.

Bug#1021468: gtk3-client built for no reason (gtk3.22-client packaged instead)

[Marko Lindqvist]

Package: freeciv
Version: 3.0.3-3

debian/rules: "--enable-client=gtk3,gtk3.22,sdl2,qt"

Nothing from gtk3-client is packaged in Debian, so there should be no need
to build it.


 - ML

Bug#967353: freeciv: depends on deprecated GTK 2

[Marko Lindqvist]

 For the future perspective: gtk2-client is dropped completely from
freeciv-3.1 development version. With our attempt to sync our feature
releases with various distributions' two-year release cycle, we are
expecting freeciv-3.1 to be in bookworm+1.


 - ML

Bug#967353: freeciv: depends on deprecated GTK 2

[Marko Lindqvist]

On Mon, 29 Aug 2022 at 21:45, Tobias Frost  wrote:
>
> On Mon, Aug 29, 2022 at 08:33:12PM +0200, Stephen Kitt wrote:
> > Hi,
> >
> > On Mon, 29 Aug 2022 20:06:12 +0200, Tobias Frost  wrote:
> > > On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote:
> > > > Source: freeciv
> > > > Severity: normal
> > > > User: pkg-gnome-maintain...@lists.alioth.debian.org
> > > > Usertags: gtk2 oldlibs
> > > > Control: block 947713 by -1
> > > >
> > > > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> > > > binary packages with a Depends on GTK 2.
> > >
> > > (...)
> > >
> > > Upstream says in 3.0.3 (doc/README.packaging):
> > > > * Gtk2-client is no longer considered maintained client

 Read that as: "We don't promise anything."

 In practice it's better than ever (some bug fixes still trivially
ported from other gtk-clients). Just if there's, e.g., going to be a
build breakage with newer compilers or other tools, upstream is not
going to waste time on fixing those. That said, it does compile with
both current gcc-snapshot and clang-15 of Debian Sid.


 - ML

Bug#1013426: Cannot be built twice

[Marko Lindqvist]

On Sun, 28 Aug 2022 at 19:27, Tobias Frost  wrote:
> So, even with the switch, the build system needs it at least at
> configure time, which is the reason why it failed at the second time.
> (make distclean was the command that failed; as the removal of lua
> was only directly before the build, it worked the first time.)

 Yes, autotools assume it to be part of the complete SOURCE tree, and
requiring some actions (any 'dist...' -target) as such.


 - ML

Bug#631775: Fixed in upstream 3.0.0

[Marko Lindqvist]

Freeciv-3.0 (optionally, defaulting to true) remembers messages from
the previous turn too.

See client section from: https://www.freeciv.org/wiki/NEWS-3.0.0


 -ML

Bug#1013429: x32 build failure

[Marko Lindqvist]

Package: freeciv
Version: 2.6.6-1

I've looked at the debian freeciv package build failure at x32 (
https://buildd.debian.org/status/logs.php?pkg=freeciv=2.6.6-1 ),
and opened upstream ticket:
https://osdn.net/projects/freeciv/ticket/44917
There's patch there that I used to successfully build the debian
package on x32. Should apply also to freeciv-3.0.2, if you are going
to update to that before fixing more issues on 2.6 series.


 - ML

Bug#1013426: Cannot be built twice

[Marko Lindqvist]

Package: freeciv
Version: 2.6.6-1

As debian/rules deletes dependencies/lua-5.3 directory when building
the package, later attempts to do another build from the same tree
fails.
You should not delete the directory. According to the comment, the
purpose is to make sure those sources are never used, as a fallback if
lua is not found from the system. That's better achieved by adding the
configure option --enable-sys-lua=yes (to override freeciv-2.6 default
of --enable-sys-lua=test). It will also give more sensible errors than
the missing directory, if those errors ever occur.

(This was causing me trouble when I started looking at the debian
freeciv build failure at x32 - I should have something for that soon)


 - ML

Bug#996746: Outdated lua dependency

[Marko Lindqvist]

Package: freeciv
Version: 2.6.5-1

Noticed on https://tracker.debian.org/pkg/freeciv a warning that
freeciv depends on two packages which would need a new maintainer. One
of these is liblua5.2-dev. That should be easy to fix by updating the
dependencies, as freeciv-2.6 uses lua-5.3, not lua-5.2. As you don't
have lua-5.3 in dependencies, it might be that no debian packaged lua
gets used at all, but it instead falls back to compiling it from an
included copy.

On a related note I suspect that the other listed package, gnulib, is
not needed as a dependency either. Freeciv distribution should contain
all the required .m4 files, and I think you use those anyway (newer
serial). I could see the point of using .m4 files from the gnulib
package instead, but as things currently stand the abandoned package
has more outdated versions than freeciv distribution.


 - ML

Bug#993157: autoconf-2.71 regression?

[Marko Lindqvist]

 Likely an autoconf-2.71 (currently in unstable, but blocked from
migrating to testing due to regressions caused) issue.


 - ML

Bug#984807: Add stdmusic to freeciv-sound-standard package

[Marko Lindqvist]

Package: freeciv-sound-standard
Version: 2.6.3-1

In addition to the standard sound effects set, freeciv-sound-standard
package should include standard music set. In the standard music set,
there's only one track of menu music, so it's not adding a lot to the
package size.
This is also a regression since freeciv-2.5 series, since back then
there were no separate music sets, but the music was included to the
sound set. Debian used to have the menu music via the sound set.
The files belonging to the standard music set are
data/stdmusic.musicspec and content of data/stdmusic/


 - ML

Bug#978745: Server buffer overflow when reading tailored score log

[Marko Lindqvist]

On Thu, 31 Dec 2020 at 10:39, Marko Lindqvist  wrote:
> I'll send link to upstream ticket once it is available.

https://www.hostedredmine.com/issues/907791


 - ML

Bug#978745: Server buffer overflow when reading tailored score log

[Marko Lindqvist]

Package: freeciv
Version: 2.6.2.1-2
Tags: Security

Freeciv server has a buffer overflow vulnerability, if it reads
tailored score log file.
Score log functionality is not enabled by default, and it's rarely enabled.
Freeciv-2.6.3 to be released later tonight will contain a fix. I'll
send link to upstream ticket once it is available.


 - ML

Bug#978744: Freeciv gtk-clients' crash on (tailored) chat message

[Marko Lindqvist]

Package: freeciv
Version: 2.6.2.1-2
Tags: Security

Gtk-client may crash when receiving chat message. It's reported that
certain chat messages always do that, making it possible for one
player to crash clients of other players on the same server.
Upstream fix is in https://www.hostedredmine.com/issues/910832, and
there's going to be freeciv-2.6.3 release with this fix included later
tonight. However, gtk-clients in older Debian releases are likely to
be affected.


 - ML

Bug#975148: freeciv: FTBFS: canvas.cpp:265:16: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Marko Lindqvist]

On Thu, 19 Nov 2020 at 11:50, Marko Lindqvist  wrote:
>
>  upstream 2.6.2.1 release with the fix included coming soon (likely 28.11)

 Out now.


 - ML

Bug#975148: freeciv: FTBFS: canvas.cpp:265:16: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Marko Lindqvist]

On Thu, 19 Nov 2020 at 11:50, Marko Lindqvist  wrote:
>
>  Upstream fix: https://www.hostedredmine.com/issues/868060, upstream
> 2.6.2.1 release with the fix included coming soon (likely 28.11)

 In case you decide not to wait for official upstream release but to
backport the fix to debian, you may want to consider other critical
(build & crash) fixes of 2.6.2.1 at the same time:
 http://www.freeciv.org/wiki/NEWS-2.6.2.1


 - ML

Bug#975148: freeciv: FTBFS: canvas.cpp:265:16: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Marko Lindqvist]

 Upstream fix: https://www.hostedredmine.com/issues/868060, upstream
2.6.2.1 release with the fix included coming soon (likely 28.11)


 - ML

Bug#946613: Consider making gtk3.22-client the one installed by 'freeciv' package

[Marko Lindqvist]

Package: freeciv
Version:   2.6.0-4

Freeciv doc/README.packaging about the new gtk3.22-client:
"This client suits better for systems with gtk+-3.22 than the
gtk3-client compatible with much older gtk+ versions."

 (Since that text has been written, gtk+ project changed their
decision that 3.22 would be the last version of gtk+-3. Above should
say that "...systems with gtk+-3.22 or gtk+-3.24...")

 - ML

Bug#931415: sdl2-client crashes when entering game

[Marko Lindqvist]

Package: freeciv
Version: 2.6.0-2

 Some people are reporting to us in freeciv upstream that sdl2-client
always crashes for them when entering the game. We have a fix for that
as 0001-Fix-arithmetic-error-in-SDL2-create_line.patch (2019-07-03
02:18 AM) in http://www.hostedredmine.com/issues/824589 You may want
to backport that fix.

 - ML

Bug#896924: extremetuxracer: segfault when reaching end of certain courses

[Marko Lindqvist]

On 26 April 2018 at 02:17, Andreas Eriksson  wrote:
> val = 
> #8  0x555a4e95 in CScore::AddScore(std::__cxx11::basic_string

Bug#853834: Ccache storing and restoring file paths that may no longer be correct

[Marko Lindqvist]

Package: ccache
Version: 3.3.3-1

Building SDL2_mixer-2.0.1
(https://www.libsdl.org/projects/SDL_mixer/release/) multiple times
with ccache enabled, following reproducible problem occurs.

1) Build SDL2_mixer in first source tree. I've used separate builddir
when doing so.
2) Delete source and build trees used in step 1 so that files in them
will not be found later
3) Rebuild SDL2_mixer in another (differently named) tree

 Latter build fails with error messages complaining about files
missing in the first, deleted, tree. Such paths should be stored
nowhere as we are talking about completely clean builds here. Ccache
is the thing that does store things between builds, so seems like
likely culprint. Further, issue does not occur if one does 'ccache -C'
before the second build.

 I'll send the exact error message once I have opportunity to
reproduce this again. Anyway, it was about .deps (again; ccache
involvement makes sense as those are created by compiler for which
ccache caches stuff)


 - ML

Bug#848165: freeciv-client-qt: crash at exit ...leavegame->quit

[Marko Lindqvist]

 As the crash is in atexit handlers when the program is closed, this
seems like upstream bug #25364: http://gna.org/bugs/?25364


 - ML

Bug#839104: Problem debugged

[Marko Lindqvist]

This regression has two parts:

- etr gets window resize events it didn't before (this is cause by
some change outside etr)
- etr handling of the resize events seems buggy (previously latent bug
activated by the changes outside etr)

 I'm testing a fix to upstream.


  -ML

Bug#839104: extremetuxracer takes the focus but no windows is displayed but sound is played => impossible to switch to other applications, impossible to close extremetuxracer

[Marko Lindqvist]

On 19 October 2016 at 22:08, Markus Koschany  wrote:
> On 19.10.2016 15:43, Isaac To wrote:
>> On Thu, 29 Sep 2016 14:59:47 +0200 Markus Koschany > > wrote:
>>> On 29.09.2016 14:52, gpe wrote:
>>> > I'm using gnome and a NVIDIA vidéo card with NVIDIA drivers.
>>>
>>> I'm also using GNOME but with an ATI video card and free drivers. What
>>> happens if you use the free nouveau drivers?
>>
>> I just want to share that I see exactly the same problem: a window shows
>> up, immediately get deleted, and this repeats after a very short while.
>> My lspci shows the following:
>
> Hello,
>
> thanks for your additional information but unfortunately I don't know
> how to interpret your strace output. I find it still unlikely that
> extremetuxracer is the root cause because the game (or the packaging)
> has not changed in months. It is rather related to your video card
> driver, the X server, SDL or window manager.

 Even my own build I last used a couple of months ago has broken this
way. I suspect it was broken either SFML (etr no longer uses SDL) or
gdm updates.


 - ML

Bug#827666: [Fwd: Freciv in Stretch]

[Marko Lindqvist]

On 9 July 2016 at 23:37, Markus Koschany  wrote:
> How can I avoid to run the configure step twice? Is there an option to
> force SDL1 mixer for the sdl client that I've missed?

 The mixer support build is part of client-common code (library that
all guis use - or try to use). Unfortunately that means that from the
same build (configure) one can't have guis with different mixer
versions. Note that while it has been possible to avoid running
configure twice in 2.5 by always using SDL1.2-mixer, in 2.6 you will
face the problem of sdl-client working only with sdl1.2-mixer and new
sdl2-client only working with sdl2-mixer (solution at that time might
be dropping old sdl-client completely, though)


 - ML

Bug#827666: [Fwd: Freciv in Stretch]

[Marko Lindqvist]

On 23 June 2016 at 17:00, Markus Koschany  wrote:
>
> That sounds encouraging. Do you intend to release another version of the
> 2.5 series before Debian's next freeze? Then I could upload the new
> freeciv-client-gtk3 package together with this one.

 We have main content for 2.5.5 release already, including one fix
that makes gtk3-client to behave better with gtk+-3.20 (and later). We
are just adding less-important fixes now. How much time you would need
for these packaging changes, if we were to release 2.5.5 so that it
would make to Ubuntu-16.10?


 - ML

Bug#827666: [Fwd: Freciv in Stretch]

[Marko Lindqvist]

On 19 June 2016 at 19:33, Markus Koschany  wrote:
>
> Debian has been providing both clients in the past but Jacob Nevins
> insisted that we should remove the gtk3 client because it was too
> experimental. Did this situation change in the meantime? Is the client
> stable enough for being supported in Stretch?

 I don't think you ever provided them both simultaneously. I hope
Jacob to clarify his opinion himself, but I think we had some
misunderstanding last time. We wanted (and for freeciv-2.5 still want)
gtk2-client as the default one (one you get with 'apt-get install
freeciv') but also to have gtk3-client as an alternative to it (like
sdl-client and qt-client already are).


 - ML

Bug#784019: freeciv: removal of bz2 support = inability to load old savegames?

[Marko Lindqvist]

On 2 May 2015 at 11:52, Jacob Nevins
jacobn+deb...@chiark.greenend.org.uk wrote:
 Package: freeciv-server
 Version: 2.5.0-1

 I haven't tested this at all, I'm afraid, but noticed this in the
 changelog of the new Freeciv packages in experimental:

 | - Remove libbz2-dev from Build-Depends.
 |   We already support xz compression which is a superior compression format.

 I think this means that the new server won't be able to load .sav.bz2
 savegames? That would be unfortunate, since the stable package generates
 them (and Freeciv is generally able to load savegames from older
 versions).

 Once you've released a package with support for a compression format, I
 think you can practically never remove it, even if you add a newer
 format.

 They can be deprecated and then obsoleted over long time in upstream
- or by similar sources patching in downstream (I think we should
start that process in upstream for bz2). Anyway, dropping the support
for compression format that has been the default (assuming Debian uses
upstream default) to create savegames in previous version is certainly
no way to go.


 Sorry if I've misconstrued the situation.



 - ML


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

Bug#784019: freeciv: removal of bz2 support = inability to load old savegames?

[Marko Lindqvist]

On 2 May 2015 at 17:56, Markus Koschany a...@gambaru.de wrote:
  only old savegames are affected.

I think this (the word 'only') is the point we disagree about. Are you
going to document it so that User should not upgrade from Jessie to
Stretch before finishing current games of Freeciv. (or at least to
load latest save in Jessie, switch compresstype, and save it again).
 If you want to take quicker route to obsoleting .bz2 than upstream, I
would recommend patching so that .xz will be the default compression
format for new savegames now on - users upgrading from Stretch to
Stretch+1 won't be affected if Stretch+1 drops .bz2 support. I'm going
to submit such a patch to upstream patch tracker in near future, which
you could just backport.


 - ML


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

Bug#784019: freeciv: removal of bz2 support = inability to load old savegames?

[Marko Lindqvist]

On 2 May 2015 at 21:24, Markus Koschany a...@gambaru.de wrote:
  What about savegames from 2.2, 2.3 and so
 on, they all need to be converted by hand but that shouldn't be too
 difficult.

 True. To clarify: I'm not so worried about old old savegames, but as
a user I would expect that I can seamlessly continue my currently
active game over Debian update. Remember that game of freeciv is not
something typically completed in a single session. (Each real game
(ignoring games run purely for testing something in freeciv) I play
myself takes about 8 months calendar time)


 - ML


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

Bug#766185: freeciv-client-gtk: Removal of GTK+3 client

[Marko Lindqvist]

On Wednesday, 22 October 2014, Markus Koschany a...@gambaru.de wrote:


 On 22.10.2014 15:15, Marko Lindqvist wrote:

  Gtk3-client breakage with Jessie's latest gtk3 libraries is something I
  need to investigate if it's a bug in gtk3 or freeciv.

 I can't reproduce any black game screen when I launch the GKT3 client.


 Gtk3 upstream has fixed https://bugzilla.gnome.org/show_bug.cgi?id=737986
in just releases 3.14.4. It sounds like it might be the issue I've been
having, but I can't confirm yet.

 - ML

Bug#764114: freeciv: Error during build

[Marko Lindqvist]

On 5 October 2014 18:30, Rogier rogier...@gmail.com wrote:
 --enable-client=all \   


 Apparently, the configure step does not fail if the qt client is
 requested, and the qt headers etc. were not found...

It would fail if qt-client was explicitly requested
(--enable-client=gtk2,gtk3,sdl,qt,xaw,stub), but all means all
that can be built (on this platform)


 - ML


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

Bug#757876: freeciv-client-gtk: can't start a local game

[Marko Lindqvist]

On 12 August 2014 20:05, Jacob Nevins
jacobn+deb...@chiark.greenend.org.uk wrote:
 Xavier Cartron writes:
 - If I do 'freeciv-server -p 5557',, the server starts normally.

 Enh. Of course the client might not be choosing 5557. It tries to find a
 free port and tells the server to use that.
 (Sure would have been useful if we (upstream) had thought to log the
 port we were attempting to use, either in the client or in the
 server...)

 If the client had, for instance, a logical bug where it searched for the
 first *used* port, or its test for free-ness always returned false
 causing the port to wrap around, I guess that could cause this symptom.
 (The relevant code is in utility/netintf.c:find_next_free_port().)

 Is there anything unusual about your network stack? Lack of IP
 connectivity, real IPv6 connectivity, non-default kernel options,
 anything like that?

 My guess would be that this is related to IPv4/IPv6 dual stack. Could
it be so that the same port number is free in IPv4, but bound in IPv6?
There might be a bug in initial detection of the free port in that it
checks only IPv4, but then final bind wants them both (for security
reasons among others)
 The other explanation coming to my mind is that it's the detection of
the free port itself that somehow fails to free the port back after
succesfully binding it.


 - ML


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

Bug#757876: freeciv-client-gtk: can't start a local game

[Marko Lindqvist]

On 12 August 2014 20:54, Marko Lindqvist cazf...@gmail.com wrote:
 There might be a bug in initial detection of the free port in that it
 checks only IPv4, but then final bind wants them both

 I've confirmed that bug in freeciv code (can't be sure that it's the
problem you're suffering from, though). It's now
http://gna.org/bugs/index.php?22463. Unfortunately no fix made it to
the 2.4.3 release earlier today.


 - ML


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

Bug#747975: extremetuxracer: SVG icon is missing

[Marko Lindqvist]

On 13 May 2014 23:20, Markus Koschany a...@gambaru.de wrote:
 Control: found -1 0.6.0-1

 On 13.05.2014 13:52, Ronny Standtke wrote:
 Package: extremetuxracer
 Version: 0.6.0-1~bpo70+1
 Severity: minor

 The previous version of extremetuxracer contained an SVG icon
 (/usr/share/pixmaps/etracericon.svg). Please add it as
 /usr/share/icons/hicolor/scalable/apps/etr.svg. Then you can probably
 even remove the other icons in /usr/share/pixmaps.
 SVG looks so much better...

 Hi,

 as far as I know the latest extremetuxracer release doesn't ship a svg
 icon hence it cannot be installed. I completely agree that the current
 svg icon for 0.4-6 looks much better. Let's see what happens in the next
 version. I keep your bug report in mind.

 Is that icon same as resources/etracer.svg from source tarball? I
guess we should install and use that in .desktop -file.


 - ML


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

Bug#706898: Upstream Project

[Marko Lindqvist]

We in the upstream project currently list said
http://sourceforge.net/projects/extremetuxracer/ as our homepage in
the latest documentation. The old URL is not coming back in
foreseeable future.


 - ML


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

Bug#738142: New upstream release 0.6.0, watchfile needs updating

[Marko Lindqvist]

Package: extremetuxracer

Our latest release is 0.6.0, for which we also sanitized our downloads
directory structure. Unfortunately this means that Debian's old
watchfile does not catch new versions, though the change should make
new version of such mechanisms more reliable in the future.


 - ML


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

Bug#730868: freeciv: New upstream version 2.4.1 available

[Marko Lindqvist]

On 30 January 2014 15:19, Markus Koschany a...@gambaru.de wrote:
  Does a similar option such as --enable-sys-lua exist for m4?
 If possible I would like to drop Debian's patch for this issue.

 No, and such an feature couldn't easily be part of the configure, as
those .m4 -files are like part of the configure script itself - they
would be already been used by the time such an option, maybe itself
living in .m4 -file, would be parsed.


 - ML


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

Bug#730868: freeciv: New upstream version 2.4.1 available

[Marko Lindqvist]

On 28 January 2014 16:34, Markus Koschany a...@gambaru.de wrote:
 On 27.01.2014 20:06, Marko Lindqvist wrote:
 [...]
  I think 2.4.0-1 takes advantage of our new configure option
 --enable-sys-lua that makes freeciv to use lua libraries found (and
 required) in the system instead of using the copy shipped with freeciv
 itself.

 This option wasn't used in version 2.4.0 but will be in 2.4.1. Thanks
 for the hint!

 Be sure to check doc/README.packaging for things like this.


 - ML


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

Bug#730868: freeciv: New upstream version 2.4.1 available

[Marko Lindqvist]

On 27 January 2014 20:39, Markus Koschany a...@gambaru.de wrote:

 One of my biggest concerns is about the embedded lua libraries.
 Obviously until 2.4.0-1 Debian's lua5.1 system library has been used
 but the patch for making that happen has been removed with the last
 upload. What are the reasons for shipping those libraries? Is it
 possible to replace them with system libraries?

 I think 2.4.0-1 takes advantage of our new configure option
--enable-sys-lua that makes freeciv to use lua libraries found (and
required) in the system instead of using the copy shipped with freeciv
itself.


 - ML


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

Bug#730868: freeciv: New upstream version 2.4.1 available

[Marko Lindqvist]

On 26 January 2014 17:35, Jacob Nevins
jacobn+deb...@chiark.greenend.org.uk wrote:
 Markus Koschany writes:
 the current human maintainers of freeciv are quite inactive/busy these
 days. You could always try to update the package yourself and ask
 someone on debian-devel-ga...@lists.debian.org for sponsoring your
 package. This might often be the quickest way to get an urgent fix into
 Debian/Ubuntu.

 You're probably right that it's the quickest way, but so far I've been
 successfully resisting the temptation to get involved in Debian
 packaging -- I already have too many commitments as upstream...

 So are we all, though the fact that most freeciv devs seem to be
Debian or derivative users should make packaging to Debian a bit
easier - most incompatibility problems and the like get caught in
upstream already. I'm using Debian testing as primary Freeciv
development OS.

 As soon as Alioth and the git repositories are back online, I can try to
 package 2.4.1. I hope there aren't too many changes.

 Since 2.4.0 is already packaged, I *think* 2.4.1 should be a
 straightforward rebuild.

 I think so too, as long as one has only updating to the new upstream
version as goal for new Debian package version - as jtn said that
alone would be big improvement, fix many bugs.

 I don't see anything scary-looking at
 http://www.freeciv.org/wiki/NEWS-2.4.1#Build.2Fportability
 nor any significant additions to doc/README.packaging.

 I can't promise that the new release will be uploaded in time before
 the 6th of February. That depends on whether I can find a sponsor for
 freeciv.

 Thanks for considering it.

 After Ubunut LTS next important distributions related date for me is
freeze of Debian itself November. How much earlier we should have
upstream release (bugfix one) out for it to get included with high
probability?


 - ML


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

Bug#696306: freeciv: CVE-2012-5645

[Marko Lindqvist]

On 19 December 2012 09:02, Moritz Muehlenhoff j...@inutil.org wrote:
 Package: freeciv
 Severity: important
 Tags: security

 Hi,
 please see http://aluigi.altervista.org/adv/freecivet-adv.txt

 That's two issues...

 Bug: http://gna.org/bugs/?20003

 ... reported in one freeciv ticket.

 That CVE is a bit unfortunate that it (currently) has description
containing both parts but fix provided is only one part. I think it's
quite likely that they will assign new CVE for the other half to sort
this out.

 Fix: http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=21670

 Patch from stable S2_3 branch (where 2.3.x releases come from):
http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=21672

 And the other fix not listed in CVE: trunk:
http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=21701 /
S2_3: http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=21703

 Please make an isolated upload with the security fix to unstable and
 ask the release managers for an unblock by filing a bug against
 release.debian.org

 Cheers,
 Moritz


 - ML


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

Bug#672715: Failing lutimes() aborting whole unpacking

[Marko Lindqvist]

Source: dpkg
Version: 1.16.3

I'm not sure if this counts as dpkg bug, or is the behavior exactly
correct (for your upstream dpkg), but reporting just for you to
consider.

I'm using dpkg in building OpenEmbedded image. So I'm unpacking
packets not to host system, but under custom prefix. Some packets fail
to unpack. They abort when lutimes() in tarobject_set_mtime() fails
for some symbolic link. Most of the time problem is that symbolic link
being unpacked has absolute path, and host system does not have such a
file (ENOENT) but I've also seen it to complain about permissions
(EACCES).

From man lutimes I find it surprising that lutimes() cares about
file being linked to at all. It should operate on link only, so this
might actually count as lutimes() bug.


 - ML



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

Bug#671623: override.cc fails to compile due to apti18n.h definitions conflicting with standard headers

[Marko Lindqvist]

Source: apt
Version: 0.9.2

apti18n.h has comment about how each source file should include it
last. That's for a reason, as override.cc compilation failed to find
setlocale() declaration from locale.h when included after apti18n.h.
Attached patch moves apti18n.h include to be last one.


override-i18n-inc.patch
Description: Binary data

Bug#671623: override.cc fails to compile due to apti18n.h definitions conflicting with standard headers

[Marko Lindqvist]

On 5 May 2012 16:42, David Kalnischkies kalnischkies+deb...@gmail.com wrote:
 On Sat, May 5, 2012 at 2:02 PM, Marko Lindqvist cazf...@gmail.com wrote:
 apti18n.h has comment about how each source file should include it
 last. That's for a reason, as override.cc compilation failed to find
 setlocale() declaration from locale.h when included after apti18n.h.
 Attached patch moves apti18n.h include to be last one.

 Out of interest: Which compiler is that?

 I don't think this depends so much on compiler (gcc 4.6), but overall
setup. I encountered this compilation failure while trying to upgrade
apt version used by OpenEmbedded. I think that the failing pass had
NLS disabled, which leads quite differently behaving apti18n.h than
what one usually gets.


 - ML



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

Bug#476284:

[Marko Lindqvist]

 Even if physics change caused by library upgrade independently from
program upgrade would sometimes be unwanted, there should be option to
use bullet from debian packet. Those programs that cannot afford to
risk physics upgrade without balancing everything in program itself
would be no way forced to use that packet, but they could still use
their own internal bullet copy. Another, though IMO much worse, option
would be to provide several bullet packets, one of each supported
bullet version and one metapacket that would depend on current default
version packet.

 I've done some bullet dependent packages myself, and for that goal I
had to package also bullet myself ( http://build.cazfi.net/deb/ ).
There's also packages in getdeb, and as earlier comments mentioned
some work has been done in Debian version control. So there's several
independent packaging implementations of bullet already. It should be
quite easy to just cleanup official packaging from these.


 - ML



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

Bug#591617: Build server with bzip2 savegame compression support

[Marko Lindqvist]

Package: freeciv
Version: 2.2.1-1
Severity: wishlist

It seems that freeciv-server is built without bzip2 savegame
compression support.

To test in server prompt:

 explain compresstype
Option: compresstype  -  Savegame compression algorithm
Description:
  Compression library to use for savegames.
   0 - none
   1 - zlib (gzip format)
   2 - bzip2
  Not all servers support all compression methods.
Status: changeable
Value: 1, Minimum: 0, Default: 1, Maximum: 1
 set compresstype 2
Value out of range (minimum: 0, maximum: 1).



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

Bug#591617: Build server with bzip2 savegame compression support

[Marko Lindqvist]

On 4 August 2010 14:37, Karl Goetz k...@kgoetz.id.au wrote:

 It seems that freeciv-server is built without bzip2 savegame
 compression support.

 We don't appear to modify the default here, so I assume freeciv
 upstream ships with zlib as default compression. Is there a particular
 motivator for us to diverge from that?
 thanks,
 kk

 Upstream default is to ship with bzip2 compression support if it's
available (configure time check). It's just a matter of having
libbz2-dev package installed when building freeciv binaries.


 - ML



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

Bug#587890: Debian patch reverts upstream cross-compilation fix

[Marko Lindqvist]

Package: freeciv
Version: 2.2.0-1

Among other changes patch 99_build_without_ggzd.diff effectively
reverts upstream bugfix RT #40134 (ggz.m4 breaks cross-compilation),
commit #14649. Is this intentional?


 - ML



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

Bug#578068:

[Marko Lindqvist]

 only meant to be used by one user

Freeciv is primarily multiplayer game.

I agree it would be nice to have option to use UNIX sockets when
playing single player, though.


 - ML



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

Bug#484810: Configure failure when all code is position independent

[Marko Lindqvist]

2008/6/6 Mark Brown [EMAIL PROTECTED]:
 On Fri, Jun 06, 2008 at 06:53:31PM +0300, Marko Lindqvist wrote:

 -  SFLAGS=${CFLAGS--O3} -fPIC
 +  SFLAGS=${CFLAGS--O3}
 +
 +  if ! $CC -c $CFLAGS -fPIC $test.c 21 |
 +   grep all code is position independent /dev/null
 +  then
 +SFLAGS=$SFLAGS -fPIC
 +  fi

 This patch is too specific to current toolchains and a specific locale
 at the minute - it'll be too fragile going forward.  If you can come up
 with a test for this that checks for the feature more directly that
 would be much better.

 This patch goes against more fundamental problem in zlib configure -
determining compile success/failure from compiler output and not from
compiler return value. This fixes above fPIC warning problem, and is
more robust against similar future problems.


 - ML
diff -Nurd zlib/configure zlib/configure
--- zlib/configure	2008-07-13 01:40:19.0 +0300
+++ zlib/configure	2008-07-13 01:43:22.0 +0300
@@ -190,8 +190,8 @@
 if test $shared -eq 1; then
   echo Checking for shared library support...
   # we must test in two steps (cc then ld), required at least on SunOS 4.x
-  if test `($CC -c $SFLAGS $test.c) 21` =  
- test `($LDSHARED -o $test$shared_ext $test.o) 21` = ; then
+  if $CC -c $SFLAGS $test.c /dev/null 21 
+ $LDSHARED -o $test$shared_ext $test.o /dev/null 21 ; then
 LIBS=$LIBS $SHAREDLIBV
 echo Building shared library $SHAREDLIBV with $CC.
   elif test -z $old_cc -a -z $old_cflags; then
@@ -228,7 +228,7 @@
 #include sys/types.h
 off64_t dummy = 0;
 EOF
-if test `($CC -c $CFLAGS -D_LARGEFILE64_SOURCE=1 $test.c) 21` = ; then
+if $CC -c $CFLAGS -D_LARGEFILE64_SOURCE=1 $test.c /dev/null 21 ; then
   CFLAGS=${CFLAGS} -D_LARGEFILE64_SOURCE=1
   SFLAGS=${SFLAGS} -D_LARGEFILE64_SOURCE=1
   echo Checking for off64_t... Yes.
@@ -242,7 +242,7 @@
   return 0;
 }
 EOF
-  if test `($CC $CFLAGS -o $test $test.c) 21` = ; then
+  if $CC $CFLAGS -o $test $test.c /dev/null 21 ; then
 echo Checking for fseeko... Yes.
   else
 CFLAGS=${CFLAGS} -DNO_FSEEKO
@@ -255,7 +255,7 @@
 #include unistd.h
 int main() { return 0; }
 EOF
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   cat  zlibdefs.h EOF
 #include sys/types.h	/* for off_t */
 #include unistd.h	/* for SEEK_* and off_t */
@@ -292,7 +292,7 @@
 }
 EOF
 
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   echo Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
 
   cat  $test.c EOF
@@ -316,7 +316,7 @@
 }
 EOF
 
-  if test `($CC $CFLAGS -o $test $test.c) 21` = ; then
+  if $CC $CFLAGS -o $test $test.c /dev/null 21 ; then
 echo Checking for vsnprintf() in stdio.h... Yes.
 
 cat $test.c EOF
@@ -341,7 +341,7 @@
 }
 EOF
 
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   echo Checking for return value of vsnprintf()... Yes.
 else
   CFLAGS=$CFLAGS -DHAS_vsnprintf_void
@@ -379,7 +379,7 @@
 }
 EOF
 
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   echo Checking for return value of vsprintf()... Yes.
 else
   CFLAGS=$CFLAGS -DHAS_vsprintf_void
@@ -409,7 +409,7 @@
 }
 EOF
 
-  if test `($CC $CFLAGS -o $test $test.c) 21` = ; then
+  if $CC $CFLAGS -o $test $test.c /dev/null 21 ; then
 echo Checking for snprintf() in stdio.h... Yes.
 
 cat $test.c EOF
@@ -428,7 +428,7 @@
 }
 EOF
 
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   echo Checking for return value of snprintf()... Yes.
 else
   CFLAGS=$CFLAGS -DHAS_snprintf_void
@@ -460,7 +460,7 @@
 }
 EOF
 
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   echo Checking for return value of sprintf()... Yes.
 else
   CFLAGS=$CFLAGS -DHAS_sprintf_void
@@ -476,7 +476,7 @@
 #include errno.h
 int main() { return 0; }
 EOF
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   echo Checking for errno.h... Yes.
 else
   echo Checking for errno.h... No.
@@ -491,7 +491,7 @@
   return mmap((caddr_t)0, (off_t)0, PROT_READ, MAP_SHARED, 0, (off_t)0);
 }
 EOF
-if test `($CC -c $CFLAGS $test.c) 21` = ; then
+if $CC -c $CFLAGS $test.c /dev/null 21 ; then
   CFLAGS=$CFLAGS -DUSE_MMAP
   echo Checking for mmap support... Yes.
 else

Bug#484810: Configure failure when all code is position independent

[Marko Lindqvist]

Package: zlib1g
Version: 1:1.2.3.3.dfsg-12

 zlib1g configure checks assume that compile fails if compiler outputs
anything, assuming it is always error message. (This is ugly, and one
may want to fix it properly.)

 Compiler always gets -fPIC, and when compiling for certain
platforms (I encountered this when compiling with MinGW32), compiler
gives warning all code is position independent meaning that -fPIC
is not needed at all. Configure checks fail because this warning
message.

 Attached patch checks against that situation, and avoids using
-fPIC if it's not needed. For more info (and possible new versions
of the patch) see http://vcust127.louhi.net/other/crosser/


 - ML
diff -Nurd zlib/configure zlib/configure
--- zlib/configure	2008-04-07 19:24:07.0 +0300
+++ zlib/configure	2008-04-07 19:29:26.0 +0300
@@ -80,7 +80,13 @@
 
 if test $gcc -eq 1  ($cc -c $cflags $test.c) 2/dev/null; then
   CC=$cc
-  SFLAGS=${CFLAGS--O3} -fPIC
+  SFLAGS=${CFLAGS--O3}
+
+  if ! $CC -c $CFLAGS -fPIC $test.c 21 |
+   grep all code is position independent /dev/null
+  then
+SFLAGS=$SFLAGS -fPIC
+  fi
   CFLAGS=${CFLAGS--O3}
   if test -z $uname; then
 uname=`(uname -s || echo unknown) 2/dev/null`

Bug#484814: Compile failure when off64_t ok, but no fseeko

[Marko Lindqvist]

Package: zlib1g
Version: 1:1.2.3.3.dfsg-12

Attached patch checks for fseeko separately even if off64_t check
success. Assuming fseeko when ever off64_t check success caused
compile failure on MinGW32 compile (don't know if this affects any of
the official Debian platforms)

For more info (and possible new versions of the patch) see
http://vcust127.louhi.net/other/crosser/


- ML
diff -Nurd zlib/configure zlib/configure
--- zlib/configure	2007-06-19 13:26:13.0 +0300
+++ zlib/configure	2008-04-07 18:21:36.0 +0300
@@ -232,23 +232,22 @@
   CFLAGS=${CFLAGS} -D_LARGEFILE64_SOURCE=1
   SFLAGS=${SFLAGS} -D_LARGEFILE64_SOURCE=1
   echo Checking for off64_t... Yes.
-  echo Checking for fseeko... Yes.
 else
   echo Checking for off64_t... No.
-  cat  $test.c EOF
+fi
+cat  $test.c EOF
 #include stdio.h
 int main(void) {
   fseeko(NULL, 0, 0);
   return 0;
 }
 EOF
-  if test `($CC $CFLAGS -o $test $test.c) 21` = ; then
-echo Checking for fseeko... Yes.
-  else
-CFLAGS=${CFLAGS} -DNO_FSEEKO
-SFLAGS=${SFLAGS} -DNO_FSEEKO
-echo Checking for fseeko... No.
-  fi
+if test `($CC $CFLAGS -o $test $test.c) 21` = ; then
+  echo Checking for fseeko... Yes.
+else
+  CFLAGS=${CFLAGS} -DNO_FSEEKO
+  SFLAGS=${SFLAGS} -DNO_FSEEKO
+  echo Checking for fseeko... No.
 fi
 
 cat  $test.c EOF

Bug#447915: freeciv-client-gtk: Segfaults in lib.so.6 strlen() from g_strdup()

[Marko Lindqvist]

On 27/10/2007, Jude Anthony [EMAIL PROTECTED] wrote:
 Package: freeciv-client-gtk
 Version: 2.0.9-3
 Followup-For: Bug #447915

 For me, this started after a weekly dist-upgrade for security reasons.
 I tried to open a saved game, and as soon as I try to open a city
 dialog, I get a segfault.  Worked fine before the upgrade.  Wish I could
 remember what packages were included.

 Which gcc version are you using? gcc-4.2.1 and 4.2.2 miscompile
Freeciv just so that opening city dialog (or global worklist) crashes.


 - ML



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

Bug#440545: Miscompilation casting signed long to void* in 64bit system

[Marko Lindqvist]

Package: gcc
Version: 4:4.2.1-5

Debian GNU/Linux lenny/sid
amd64

 gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--disable-werror --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-4)


Output from attached program, if compiled with optimization level -O2:
From 0 to 2:
 0 - In: -1, -1 (0x), Out: -1
 1 - In: 0, 0 (0x), Out: 0
 2 - In: 1, 1 (0x), Out: 1
From 1 to 3:
 1 - In: 0, 0 ((nil)), Out: 0
 2 - In: 1, 1 (0x1), Out: 1
 3 - In: 2, 2 (0x2), Out: 2

 Should be
From 0 to 2:
 0 - In: -1, -1 (0x), Out: -1
 1 - In: 0, 0 ((nil)), Out: 0
 2 - In: 1, 1 (0x1), Out: 1
From 1 to 3:
 1 - In: 0, 0 ((nil)), Out: 0
 2 - In: 1, 1 (0x1), Out: 1
 3 - In: 2, 2 (0x2), Out: 2


 This problem hit me when glib GINT_TO_POINTER() returned wrong values.


 - ML

#include assert.h
#include stdlib.h

int main()
{
  int i = 0;

  printf(From 0 to 2:\n);
  for (i = 0; i  3; i++) {
int iin = i - 1;
signed long lin = iin;
void *pin = (void *) lin;
signed long iout = (signed long) pin;
  
printf( %d - In: %d, %d (%p), Out: %d\n, i, iin, lin, pin, iout);
  }

  printf(From 1 to 3:\n);
  for (i = 1; i  4; i++) {
int iin = i - 1;
signed long lin = iin;
void *pin = (void *) lin;
signed long iout = (signed long) pin;
  
printf( %d - In: %d, %d (%p), Out: %d\n, i, iin, lin, pin, iout);
  }

  return EXIT_SUCCESS;
}

Bug#437503: Valgrind claims illegal instruction in ld-2.6.1.so

[Marko Lindqvist]

Package: libc6
Version: 2.6.1-1

 For a couple of days valgrind has refused to run any programs. This
started when /lib/ld-2.6.1.so was updated.

==19756==
vex amd64-IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
==19756== valgrind: Unrecognised instruction at address 0x4016321.
==19756== Your program just tried to execute an instruction that Valgrind
==19756== did not recognise.  There are two possible reasons for this.
==19756== 1. Your program has a bug and erroneously jumped to a non-code
==19756==location.  If you are running Memcheck and you just saw a
==19756==warning about a bad jump, it's probably your program's fault.
==19756== 2. The instruction is legitimate but Valgrind doesn't handle it,
==19756==i.e. it's Valgrind's fault.  If you think this is the case or
==19756==you are not sure, please let us know and we'll try to fix it.
==19756== Either way, Valgrind will now raise a SIGILL signal which will
==19756== probably kill your program.
==19756==
==19756== Process terminating with default action of signal 4 (SIGILL)
==19756==  Illegal opcode at address 0x4016321
==19756==at 0x4016321: memcpy (in /lib/ld-2.6.1.so)
==19756==by 0x400466E: dl_main (in /lib/ld-2.6.1.so)
==19756==by 0x4014457: _dl_sysdep_start (in /lib/ld-2.6.1.so)
==19756==by 0x400230A: _dl_start (in /lib/ld-2.6.1.so)
==19756==by 0x4000A67: (within /lib/ld-2.6.1.so)

Kernel 2.6.22-1-amd64 #1 SMP Sun Jul 29 13:54:41 UTC 2007 x86_64 GNU/Linux


 - ML


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