Follow-up Comment #8, bug #18891 (project freeciv):
I also cannot play in oneiric. At least with the gtk2/gtk3 clients, I can
start the client but when I click start to begin the game the client hangs
indefinitely consuming full CPU.
___
On Fri, Oct 28, 2011 at 5:30 PM, Matthias Pfafferodt
matthias.pfaffer...@mapfa.de wrote:
Am Mittwoch, 26. Oktober 2011, 23:25:49 schrieben Sie:
On Wed, Oct 26, 2011 at 4:50 PM, Matthias Pfafferodt
matthias.pfaffer...@mapfa.de wrote:
Am Mittwoch, 26. Oktober 2011, 01:26:49 schrieb Jason Dorje
Follow-up Comment #1, bug #18872 (project freeciv):
The warning you show is a minor bug perhaps, but the real question here is
why is compilation using -Werror? You didn't pass --enable-debug=yes or
--enable-debug=checks to the autogen / configure script? Or is the
non-presence of gcc
On Wed, Oct 26, 2011 at 4:50 PM, Matthias Pfafferodt
matthias.pfaffer...@mapfa.de wrote:
Am Mittwoch, 26. Oktober 2011, 01:26:49 schrieb Jason Dorje Short:
In file included from /usr/include/gtk-2.0/gtk/gtk.h:236:0,
from colors.h:16,
from chatline.c:44:
/usr
On Mon, Oct 24, 2011 at 4:33 PM, Marko Lindqvist cazf...@gmail.com wrote:
On 24 October 2011 22:20, Jason Dorje Short jdo...@gmail.com wrote:
For the first time in some time, I have time for freeciv work. But on
compiling, --enable-debug=checks (--enable-debug=yes in older
branches) doesn't
Follow-up Comment #9, bug #18217 (project freeciv):
Attached patch fixes trunk for me. I had to disable one warning, which
conflicts with gtkitemfactory.h:
/* We use () here to mean unspecified arguments. This is deprecated
* as of C99, but we can't change it without breaking compatibility.
For the first time in some time, I have time for freeciv work. But on
compiling, --enable-debug=checks (--enable-debug=yes in older
branches) doesn't compile in trunk or in most branches anymore.
One issue does seem to be in the GTK header files, both not under our
control and commented in the
Follow-up Comment #3, bug #16964 (project freeciv):
For older versions of the game, it might be best to change the rules to match
what the docs say - otherwise they'll probably stay wrong for lots of
languages.
For the new release though, go with the simplest rules IMO.
Follow-up Comment #6, bug #16797 (project freeciv):
Yep good catch. The actual bug is in the final loop at the bottom of the
function but using ptile throughout does make it easier to read. I'm also
going to set punit = NULL right before the loop so any future bugs of this
kind trigger
Update of bug #16797 (project freeciv):
Severity: 3 - Normal = 5 - Blocker
Status: Ready For Test = Fixed
Assigned to: pepeto = jdorje
Open/Closed:
Follow-up Comment #8, bug #16775 (project freeciv):
--- server/unithand.c (revision 18197)
+++ server/unithand.c (working copy)
@@ -1409,7 +1409,9 @@
}
/* The attack is legal wrt the alliances */
-victim = get_defender(punit, pdesttile);
+if (is_attack_unit(punit)) {
+
Update of bug #16836 (project freeciv):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #2, bug #16362 (project freeciv):
I'll take a look at this next week. Some of the GTK errors in ggz-gtk though
are due to deprecated widgets and hard to fix. If anyone good with GTK code
would like to help out it'd be welcomed.
Sorry for the spam: this comment was from me.
Follow-up Comment #4, bug #16362 (project freeciv):
Find me on irc sometime to discuss.
___
Reply to this item at:
http://gna.org/bugs/?16362
___
Message sent via/by Gna!
http://gna.org/
Follow-up Comment #1, bug #16318 (project freeciv):
Pointer type casts like that are generally to be avoided in C, in my
experience.
Agreed that the generated files should be removed by 'make distclean'.
___
Reply to this item at:
On Tue, Jun 1, 2010 at 1:55 PM, Tim Reid standsthechurchcl...@gmail.com wrote:
I was interested to see an impressive amount of work done on this
project, and might be interested in contributing something along the
lines of development, testing and/or documentation. I've started to
have a look
Update of bug #15825 (project freeciv):
Assigned to:None = jdorje
___
Reply to this item at:
http://gna.org/bugs/?15825
___
Message sent
Follow-up Comment #4, patch #1582 (project freeciv):
Truncation is fundamentally unavoidable unless we strdup-printf every string
we make everywhere, which isn't going to happen. We can cut down on it by
making buffers sufficiently long.
ATM there is an issue with MAX_LEN_NAME. This is
Follow-up Comment #1, bug #15825 (project freeciv):
Without a backtrace on this it'll be really hard to do anything with it. If
it ever happens again, give the client a SEGV (killall -SEGV freeciv-gtk) and
get a backtrace from the resulting core file.
URL:
http://gna.org/bugs/?15832
Summary: trunk will not compile
Project: Freeciv
Submitted by: jdorje
Submitted on: Saturday 04/10/2010 at 01:05
Category: agents
Severity: 5 - Blocker
Follow-up Comment #3, bug #15816 (project freeciv):
If an empty line is required there should be a comment in the file. I see
the patch but isn't the empty line above the comment, making the comment
actually wrong? And which versions (1.14 and on) does this apply to?
Secondly, it does sound
Follow-up Comment #1, bug #15801 (project freeciv):
This second attached patch does the same for 1.14.
(file #8828)
___
Additional Item Attachment:
File name: compile-warnings-1.14.diff Size:12 KB
Update of bug #15809 (project freeciv):
Status: Ready For Test = Fixed
Assigned to:None = jdorje
___
Reply to this item at:
Update of bug #15809 (project freeciv):
Category: client-gtk-2.0 = client
___
Reply to this item at:
http://gna.org/bugs/?15809
___
Message sent
Update of bug #15809 (project freeciv):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?15809
___
Message sent
Follow-up Comment #1, bug #15808 (project freeciv):
Good eye. Should it be struck by plague instead of struck by a plague?
I guess it's correct either way.
Also, bug #15802 should be lumped in with these.
___
Reply to this item at:
Update of bug #15513 (project freeciv):
Status:None = Need Info
___
Follow-up Comment #1:
Agreed.
___
Reply to this item at:
Update of bug #15502 (project freeciv):
Severity: 2 - Minor = 3 - Normal
___
Follow-up Comment #3:
It sounds to me like there's some deeper issues than just the translation.
Do you have a
Follow-up Comment #12, bug #15741 (project freeciv):
I still have no idea how to actually reproduce this or tell if the patch
fixes it. It's up to you to verify and commit it.
___
Reply to this item at:
http://gna.org/bugs/?15741
Update of bug #14205 (project freeciv):
Assigned to:None = jdorje
___
Reply to this item at:
http://gna.org/bugs/?14205
___
Message sent
Follow-up Comment #13, bug #15738 (project freeciv):
Agreed; that's just what I was going to suggest. On resizing the mapcanvas
it is the center that should be preserved. However this could run into
problems in the GTK client as it can be sized up/down in small increments
quickly which would
Follow-up Comment #15, bug #15738 (project freeciv):
Moving the upper left corner will lead to a much bigger redraw than will
happen if the top left remains fixed.
___
Reply to this item at:
http://gna.org/bugs/?15738
Follow-up Comment #10, bug #15741 (project freeciv):
Probably. I'll be more careful in future, and sorry about the inconvenience.
___
Reply to this item at:
http://gna.org/bugs/?15741
___
Follow-up Comment #3, bug #15747 (project freeciv):
Looks like just trunk is affected.
___
Reply to this item at:
http://gna.org/bugs/?15747
___
Message sent via/by Gna!
http://gna.org/
Update of bug #15741 (project freeciv):
Status: Ready For Test = Need Info
Assigned to: pepeto = None
Planned Release:2.1.12, 2.2.1, 2.3.0 =
Update of bug #15741 (project freeciv):
Status: Ready For Test = Need Info
Planned Release:2.1.12, 2.2.1, 2.3.0 =
___
Reply to this item at:
Update of bug #15741 (project freeciv):
Status: Ready For Test = Need Info
Planned Release:2.1.12, 2.2.1, 2.3.0 =
___
Reply to this item at:
Follow-up Comment #8, bug #15741 (project freeciv):
I only intentionally changed it to assign it to you. Perhaps I was working
off an outdated version of the page itself and it reverted other fields?
___
Reply to this item at:
URL:
http://gna.org/bugs/?15747
Summary: bizarre compile error in gtk2 popup_pillage_dialog
Project: Freeciv
Submitted by: jdorje
Submitted on: Monday 03/29/2010 at 15:12
Category: client-gtk-2.0
Follow-up Comment #1, bug #15747 (project freeciv):
As far as I can tell the message is in error. Replacing either one of the
what - S_LAST - 1 formulas with just what fixes it. But replacing both
breaks it again. This is either the cause of a compiler bug (unlikely) or a
hidden bug somewhere
Follow-up Comment #2, bug #15741 (project freeciv):
Unfortunately I can't reproduce it. All I can say is that I was clicking
around a lot in the change-production dialog when it happened. I don't
believe any relevant code changes have happened since then (which was a few
moments before I
Follow-up Comment #20, bug #15377 (project freeciv):
The patch I sent should fix bug #15658 which appears to be the same as this
one. However rather than that patch I think someone should take the time to
write proper ascii versions of those functions, just in case we end up with a
Update of bug #15377 (project freeciv):
Operating System:None = Microsoft Windows
___
Reply to this item at:
http://gna.org/bugs/?15377
___
Message sent
Follow-up Comment #6, bug #14205 (project freeciv):
There is not any culprit other than the too-small buffer. MAX_LEN_NAME+8 is
an incorrect byte length since the translated text is not a player name and
has no fixed limit; the buffer is just too small. At 40 bytes it is easily
enough to fit
Follow-up Comment #7, bug #14205 (project freeciv):
The attached patch improves buffering in many places using g_strdup_printf
instead of fixed-width buffers. In a few locations this was too much work so
I just made the buffers bigger instead. As previously mentioned, in several
places the
URL:
http://gna.org/bugs/?15741
Summary: SDL client crashes in build dialog
Project: Freeciv
Submitted by: jdorje
Submitted on: Monday 03/29/2010 at 00:33
Category: client-sdl
Severity: 4 - Important
Follow-up Comment #10, bug #15377 (project freeciv):
Actually I came to the exact same conclusion Ulrik: we should simply rewrite
the character functions to work only on ascii (range 0 to 127) characters,
and leave others alone. Using the system-provided functions (such as
tolower) which work
Follow-up Comment #11, bug #15377 (project freeciv):
And, unfortunately limiting the functions to ascii-only is not going to work
very well either for the is_ functions. is_alnum is most likely used for
instance to check for valid ruler/city names and will fail on any non-ascii
names now. Even
Follow-up Comment #16, bug #15377 (project freeciv):
Having 2 sets of functions is trickier than it sounds. For one, you have to
be extremely careful which you use where. For a second, neither one should
really be using the libc character functions. And for a third, the functions
we're
Follow-up Comment #2, bug #14205 (project freeciv):
How can I reproduce this?
___
Reply to this item at:
http://gna.org/bugs/?14205
___
Message sent via/by Gna!
http://gna.org/
Follow-up Comment #4, bug #14205 (project freeciv):
Ah, well that's simple. It's a simple bug in update_conn_dialog that doesn't
check the width of the AI name, probably a remnant from before when they were
given artificial player names. Attached patch will fix this. It is likely
to occur in
Follow-up Comment #5, bug #15377 (project freeciv):
Yep, that is surely correct.
These functions check whether c, which must have the value of an
unsigned char or EOF, falls into a certain character class according to the
current locale.
Each of the character function wrappers in
Follow-up Comment #1, bug #15377 (project freeciv):
The catalan.ruleset is in utf8, in both S2_2 and trunk. This is correct and
all characters are utf8. It's loaded into the server where it remains utf-8.
It's then sent over the network in utf-8. It's received by the client and
converted by
On Sat, Jan 2, 2010 at 1:30 PM, Pepeto pepet...@gmail.com wrote:
I guess those removal would be a solution to speed up the development of
Freeciv which is very slow nowadays. There cannot be more clients than
active developers!
Rather than preemptively remove them, IMO just label them as
On Wed, Sep 23, 2009 at 6:25 AM, Marko Lindqvist cazf...@gmail.com wrote:
Adding translator list to cc
2009/9/22 Jordi Negrevernis i Font jnegrever...@jnfprogramari.com:
String found in es.po after running 'update po' or alike...
By changing this option you change the active theme. This is
Follow-up Comment #3, patch #1306 (project freeciv):
This seems like it should imbalance things in the other direction, and a lot
further than the current inaccuracy. Though a ship may be able to attack 5
times, with decreasing health after each attack its usually only viable to
hit 1-2x. So
We made the decision a few years ago to support some of the features
of C99, with a check for each. Variable-length arrays was one of
them, and a very useful one in a lot of the code it's used in. I
don't think we should go back.
-jason
___
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40591
Offhand I recall the major issue with this was the AI, which would
persistently waste units attacking while tired and without chance of
victory. However you'd think the AI would do success-chance
calculations which would include the
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40581
I thought the request_id was intended to associate a packet sent to
the client with the particular request that the client had sent to the
server.
Perhaps I digress, but - for instance: the player requests to buy
something. The client
Can you elaborate more on the freeciv-web application? What's the
difference between that and gui-web?
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Okay, I admit at the start that I've missed a lot of discussion on
this, so I may be quite ignorant about what's going on.
The freeciv-web interface seems conceptually sound, and at least
partially playable (I haven't played more than a couple turns with
it). But where's the code? In the
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40508
Tonight I intend to delete trunk, replacing it with the S2_2 branch.
I'll be on irc for it if anyone wants to discuss.
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40514
I have to say, those changes are ugly. They'd be a lot better if some
comments explained what was going on.
Why can't iconv do these conversions, by setting the internal encoding to ucs-2?
-jason
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40508
No objection from here.
I spent a fair chunk of time comparing diffs from 2.2 and trunk to see
if the development branch had any patches that were missing from 2.2.
I found a few minor ones (all mine IIRC) but eventually bogged down in
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40507
Would it be possible to make the savegame.c interface modular, so that
freeciv could directly load multiple savegame formats?
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40495
This is a significant bug and should be backported, possibly even back to 2.0.
To avoid crashes maybe a placeholder data could be sent instead? Like
anarchy rather than NULL government.
-jason
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40489
On Mon, Sep 15, 2008 at 6:58 PM, François Marlier [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40489
Maybe some of you have already seen these
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40420
Or it could bring the dead player back to life...could be desirable
for scenario editing but is a bit more work to code I'm sure.
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40416
I quick google search indicates the AS_HELP_STRING use may be a typo:
possibly just changing it to AC_HELP_STRING will fix things.
Though I don't know that we want to be fiddling with imported m4 files.
-jason
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40411
On 7/27/08, Frank Van Geirt [EMAIL PROTECTED] wrote:
I would like to report a bug. When my workers irrigate grassland the
food production stays at 2. It should be 3. I irrigated next to ocean
squares and river squares. Road building
Some games give the option of showing enemy start positions. This
would potentially show the enemy's first city as fogged terrain, for
instance.
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40177
On Sat, Jul 26, 2008 at 10:51 AM, Andreas Røsdal [EMAIL PROTECTED] wrote:
I'm wondering if a shared common library, as implemented in this
patch, would reduce the memory usage when running many civclient
processes on the same
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40408
On Sat, Jul 26, 2008 at 7:47 PM, Nicolas R. Wadhwani [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40408
Hi,
In current trunk version if you capture an enemy city it still looks like it
would belong
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316
Indeed Marko is right; this is a server problem after all. You should
be sending the city ID of the dumb city. This code has been rewritten
however and apparently I no longer have any clue how it works. See
maphand.h.
-jason
The problem we had before was this:
* All borders were drawn.
* Border information was only given for visible tiles.
* The end result was that you couldn't see many tiles that you owned,
causing a massive patchwork of borders within your own territory as
you re-explored it.
* Also when an enemy
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316
On Wed, Jul 23, 2008 at 6:13 PM, guest user Freeciv wrote:
There is the catch: Between the versions the ptile-city member has been
replaced by ptile-worked which points to the city working on the tile,
so many tiles are pointing to
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40370
A lower granularity should be possible. Either the setting should
allow the border_sq value to be set or it should be a floating-point
value. Note for instance that the citymap is of radius sqrt(5) which
is neither 2 nor 3.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316
On Tue, Jul 22, 2008 at 4:34 PM, guest user Freeciv wrote:
Attached patch will let the cities be visible in the fog after you
viewed them with a unit or something else. Note that if you test it on a
savegame affected by the current
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40177
It would be good to get feedback from packagers - like Jordi Mallach,
the debian packager - on this concept.
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40389
On Mon, Jul 21, 2008 at 10:40 AM, Marko Lindqvist [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40389
After rates are adjusted, message about rate exceeding is sent about
all changed values - also
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40386
On Sun, Jul 20, 2008 at 6:07 AM, Nicolas R. Wadhwani [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40386
Hi,
If you play a lot with islands (especially with the 1x1 tiny_isles option
activated) the
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40383
Probably to do with the way auto-improvements were changed in handling.
City squares automatically get irrigation. Hill + irrigation = 2
food. Of course you can mine the hill too, then you get the
irrigation and the mining bonus,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40365
Can we get a fix for 2.1 that uses an optional capability?
-jason
On 7/19/08, Daniel Markstedt [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40365
On Sat, 19 Jul 2008 07:25:41 +0900, Madeline Book
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384
On 7/19/08, Marko Lindqvist [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384
With altering movement phase can end being 32, causing crash in
client update_info_label(). Fix attached.
I'm pretty
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384
On 7/19/08, Marko Lindqvist [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384
2008/7/19 Jason Dorje Short [EMAIL PROTECTED]:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384
On 7/19/08
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40375
Marko Lindqvist wrote:
2008/7/14 Madeline Book:
Since there is a maximum of 255 packet types
Is this likely to be problem in 2.2.x lifetime? If yes, we should
change packet type size to 16 bits as soon as possible. We can break
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40374
Nicolas R. Wadhwani wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40374
Hi,
This feature may have been in the editor previously but is probably commented
out now, so I tried to implement it the proper way. With
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40370
Marko Lindqvist wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40370
2008/7/10 Jason Dorje Short:
Yes, sucks. Whoever designed it obviously never actually played the
game. Borders never expand, even to the area
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40366
auth.c:100: error: ISO C forbids forward references to ‘enum’ types
When compiling with --std=gnu99 -pedantic. This is an actual error in
that the code is technically not valid C. Easily fixed by reordering it.
-jason
Index:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40368
Madeline Book wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40368
What is the purpose of having resources defined in the
civ1 terrain ruleset, but with 'name' field set to unused?
It seems completely unnecessary, and
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40360
It is my intent to merge these two, in some form or fashion. After
discussion, I believe it is best to keep 2.2 as the development version
for another cycle. Therefore first we need to find any patches that
were accidentally
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40360
PR#40052 was committed to trunk but not to 2.2. This gives some
differences to autogen.sh, ser.in, and civ.in.
Marko can you take a look at this?
-jason
___
Freeciv-dev mailing list
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40357
This patch fixes several buggy GGZ server event handlers:
* The spectator events are actually unused since we don't support
spectators yet. But they should all go to the spectator handler.
* The error event must be handled, by
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40356
Marko Lindqvist wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40356
We already had some discussion about multiple bases on same tile.
Let's continue, and gather information, in its own ticket.
I'm currently aware
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40351
Marko Lindqvist wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40351
Uninitialized extra cost from dangerous ocean drove valgrind crazy in
S2_2 and TRUNK. Of course, there is no such thing as dangerous ocean
in S2_2
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40349
I haven't looked up documentation on this but my feeling is these are
bad - and, in every case I could find, unnecessary.
make dist assumes all conditionals pass to find out what needs to be
distributed. Thus, if you ever DID have to
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40165
Marko Lindqvist wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40165
2008/3/24 Marko Lindqvist:
TERRAIN_XXX_IDENTIFIER definitions have to go, and terrains must be
selected by properly checking their flags,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40342
[EMAIL PROTECTED] wrote:
Anything else I could/should try ?
Run the server inside gdb (gdb civserver) and when it crashes get a
backtrace (bt full) which you can send us.
-jason
___
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39568
Daniel Markstedt wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39568
[dmarks - Sun Jun 29 01:22:46 2008]:
[jdorje - Sun Jun 29 01:17:09 2008]:
[pepeto - Mon Oct 15 17:07:29 2007]:
Isn't this ticket resolved? Or
Marko Lindqvist wrote:
2008/6/29 Jason Dorje Short [EMAIL PROTECTED]:
aiparatrooper.c:37:23: error: utilities.h: No such file or directory
Include path problem. I cannot reproduce.
1) Makefile.am should contain $(top_srcdir)/server/generator -path.
2) Are your Makefile.in and Makefile
1 - 100 of 263 matches
Mail list logo
