URL: http://bugs.freeciv.org/Ticket/Display.html?id=39815
AFAICT, there are many uses of the word gold:
treasury accumulation
coin (objects)
resource (in terrain)
trade value
Should we add qualifiers to all terrain resources? In the next version?
Original Message
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39811
Some months ago, I began a project to review iterators, and covered
most of the major ones. Here are those remaining, infrequently used,
mostly only in one or two files. Where they have the lack of name
qualification nesting problems,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39813
After changing to Turkish, somebody forgot to update the civilwar nations.
Note these names are the rule name=_(...) in the ruleset, not the ruleset
name, nor the section name (too many names)
Also, Bosnian-Herzegovinian!
Patch
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39811
Marko Lindqvist wrote:
There seems to be some regression. Autogames differ.
A regression is the return of a previously reported and fixed bug.
What bug are you reporting has returned?
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39811
Come to think of it, I hadn't been applying these iterator patches
against 2.1. They were trunk-only (nee 2.2). It's kinda nice to
hear that they apply cleanly, but wasn't my expectation. They were
written for 2.2.
When I was testing
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39801
The most common source of goto crashes (actually assert failures, but
reporters don't know the difference), goto_map_list in goto.c is a
parallel list to pfocus_units in control.c. The assert ensured the
lists were still the same.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39801
Too hard to merge, at least not in a few hours, as they are fairly
embedded in too many files. Instead, added a single new function to
keep them synchronized whenever a unit is killed: goto_unit_killed().
This allowed the unit number
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798
I'm trying to understand the goto problem reports, and one common thread
seems to be that folks are trying to use goto to explore. Then, they
complain that it won't goto an unknown location (PR#15629), or the trireme
sinks, or the unit
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39797
sebastien jousten wrote:
I attached to this mail the problematic saved game.
Thanks.
When I load this game and that I click on next turn the client is
disconnected to the server at the end of the moves.
Maybe the server is
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39797
Erik Johansson wrote:
I managed to get an unreproducible crash with this savegame on Linux,
I'm not sure how.. It segfaulted before the CMA error was emitted.
The segfault backtrace might be helpful
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39795
Daniel Markstedt wrote:
AFAIK these are the colors used to represent the terrain on the minimap.
Not in GTK2, it uses the overview_* colors. Perhaps somewhere else.
Anyway, it was a trivial fix to point at the [tile_*] tags, and it
Traditionally, that's trunk!
Try things out in trunk. Get feedback. When a new release is planned,
pullup the specific release features into a fresh branch (trunk to
branch is up). The branch log is an annotated list of the new features.
Requires actual planning and coordination of a release,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39784
Sounds good. And thanks!
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39790
As in PR#39435, it's time to update from 2.0 to 2.1 (and 2.2) Caught
some 1.15.0 again, too!
This is a simple replacement, so no need for fuzzy or translation effort.
In 2.1 (2.2 and trunk are similar):
Index: server/srv_main.c
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39790
Committed S2_1 revision 13858.
Committed S2_2 revision 13859.
Committed trunk revision 13860.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39791
I've been running server-only autogames, and haven't had a crash yet.
Could you post the savegame here, and the next action(s) you take to cause
the crash? It sounds like a client-server interaction.
The logs are straightforward and
URL: http://bugs.freeciv.org/Ticket/Display.html?id=15947
With the editor and new terrain, the generator will get a thorough review
in 2.2
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39785
Daniel Markstedt wrote:
I tried to reproduce on 2.1.0-rc1 and the gtk client, but no crash.
Do you use another Freeciv version or are there perhaps other factors
involved?
No crash here, either, but he's certainly not using -rc1,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39712
Confirmed working now.
Can you set the date/time? Or better yet, run ntp? (PR#39759)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39787
Daniel Markstedt wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39787
The Ubuntu package maintainers refuse to redistribute Freeciv's
stdsounds citing licensing unclarities.
See
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39785
Timothy Brownawell wrote:
Sorry, yes, it's trunk.
Last Changed Rev: 13844
I wouldn't bother running trunk, as it's not currently maintained. I'm
hoping to poke S2_2 some more as soon as 2.1.0 is released, so try S2_2
instead,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39784
Regarding the recent SDL additions to 2.1, I'm comfortable going ahead
with the release without another rc# cycle. SDL isn't (yet) finished,
but the new SDL features will make it *much* more likely to be tested in
the future (2.1.1 or
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39716
Christian Prochaska wrote:
The attached patch fixes the bribe/incite crashes. Now I only need to
find a savegame that allows researching Future Tech...
There was a good one on the list recently, look for amer.sav.bz2 in:
Date:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=38363
Pepeto _ wrote:
[EMAIL PROTECTED] - Dim. Mar. 18 10:05:18 2007]:
Version: freeciv-2.0.9.
Do you mean: Use the SDL sound plugin or Use the SDL client?
What is your OS? Did you compile Freeciv yourself?
Actually, 2.0 is at
URL: http://bugs.freeciv.org/Ticket/Display.html?id=37935
Pepeto _ wrote:
Do you still have a savegame please? Thank you to send us.
Actually, 2.0.9 is at end-of-life. Would still like to ensure the
problem doesn't occur in 2.1 and later.
___
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39784
Pepeto _ wrote:
Sorry I didn't know about it. I didn't read any comment about it before
yours.
That is not true. I explicitly pointed you at the 2.0.10 (PR#39441) ticket
as of (PR#39575) Thu, 16 Aug 2007 06:48:37 -0700.
Both of
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39624
Per Inge Mathisen wrote:
Keeping fixed tickets open until release has never been done by anyone
around here before, and your fixed-but-open tickets really did confuse
me sometimes too, so please be civil on people who misunderstand
Daniel Markstedt wrote:
What the bug tracker lacks IMO is a way to indicate that a bug
actually has been fixed, or a feature actually implemented the way it
was intended. I'd like to have a ticket status after Resolved that
indicates this; it could be called Verified or Closed for example.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=33538
Fixed in PR#39364.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=36854
Daniel's answer was considerably more polite.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=15135
Pepeto _ wrote:
Fixed, see PR#15137.
While you are partly correct, the author of the ticket deliberately left
the ticket open, and posted a message to that effect. This ticket
should only be closed by somebody after extensive
URL: http://bugs.freeciv.org/Ticket/Display.html?id=34672
Pepeto _ wrote:
Tested in 2.1: The new settler is created in the settlers' homecity
instead of at the former city tile.
Yes, we (the reporters) both tested in 2.1.
Are you making this assertion based on actual examination of the
URL: http://bugs.freeciv.org/Ticket/Display.html?id=16196
this wasn't about the crash, it was about a possible loading
problem in the savegame. But as already described, the real
problem is the AI took over and changed everything by the next
autosave. The only solution to this particular
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39773
Pepeto _ wrote:
In the default/ ruleset, teams are numbered 0-31, in civ1/ and civ2/
they are numbered 1-32. This is quite illogical.
For some odd reason, Per didn't update civ1/2 at the same time as default.
(PR#39343) 2.1.0-beta4
URL: http://bugs.freeciv.org/Ticket/Display.html?id=20125
The documentation is at:
http://freeciv.wikia.com/wiki/Install-MacOSX
Needs some updating.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39780
Note: I have no problems when executing ./civ in the compile directory.
However, followed the instructions at:
http://freeciv.wikia.com/wiki/Install-MacOSX
export CC=gcc -no-cpp-precomp -I/opt/local/include -L/opt/local/lib
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39781
Note: I have no problems when executing ./ser and ./civ
However, followed the instructions at:
http://freeciv.wikia.com/wiki/Install-MacOSX
export CC=gcc -no-cpp-precomp -I/opt/local/include -L/opt/local/lib
./autogen.sh
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39780
I have now tested against S2_0 and it has the same problem. Therefore,
not an issue to be resolved before release of 2.1.0.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39778
Could you please try to give more concrete examples? And savegames?
Do you mean that a 2.1 server doesn't load 2.0 teams?
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39730
You forgot to change the main mandatory capability.
In 2.1, I'm expecting that to change with a new (+2.1g) release
tomorrow. Since there's no possibility of backward compatibility,
both ReportFreezeFix and CF can go away, too.
In
Daniel Markstedt wrote:
Let's wait 24h before tagging, to let some final fixes go in. Between
now and final, docs need some attention too. Especially translated
docs.
Ok, cool. How long after the tag is the final release? 7 days?
___
Freeciv-dev
Assuming we're following the usual commercial release criterion,
problems that would stop the cycle now would be:
1) reproducible crashing bugs,
2) that aren't already in previous 2.0.x releases.
Anything else waits until the next release (2.1.x or 2.2.0).
I'm presuming that we still want
Pepeto _
You seem to have interpreted these 2 criteria as /or/, but the
usual English interpretation of *and* applies: both criteria must be
met to delay the release.
Bugs in 2.0 are *especially* not applicable. They are known and
didn't affect the current/previous release cycle. If they are
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39730
Eliminated both city incite cost and unit bribe cost variables. The
incite cost was never properly initialized in either the client or
server. The bribe cost was -1 in the server and 0 in the client.
Pass them as a parameter instead.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39730
Pepeto _ wrote:
maybe_cause_incident() removed in void spy_send_sabotage_list(): is it
normal?
Yes, it was special cased in maybe_cause_incident(), and now the symbol
will no longer exist. It's a dialog/support query, not a unit
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39730
Pepeto _ wrote:
All looks work well now. Thank
you for your fast work.
Thank you for your initial report and rapid testing!
Admittedly, my first patch was fast trying to be done before the
release. It just followed the
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39765
S2_1 r13741
S2_2 r13742
trunk r13743
Here's the patch variant applied to S2_2 and trunk:
Index: server/settlers.c
===
--- server/settlers.c (revision 13741)
+++
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39730
Pepeto _ wrote:
Sounds a good idea. This packets could be considered as diplomat actions.
Looks quickly doable for 2.1. Writing patch now.
Waste of time for 2.0, as nobody found this cheat in a decade, it's not
important enough, and
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39730
You're correct, I was concentrating on the network and dialog
compatibility issues, and forgot to look at the cost itself.
I don't think it should be saved at all! It really exists for
the client side, and I'm not sure it's needed
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39765
In the earlier reports (PR#14969), only part of the proposed patch
was committed to 2.1, as that was easiest to quickly review.
However, the remainder of the patch optimized the performance by a
significant change to the packet and map
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39756
Pepeto _ wrote:
The best thing would be to update automatically the science report when
the stock change, but the problem is you cannot change it in the already
distributed clients, could be an idea for S2_1, S2_2.
Here again, the
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39757
Thank you for your interest in 2.0.9. Current efforts are for the
release of 2.1, where this code does not appear. This will be
queued for the (unlikely) future release of 2.0.10.
___
URL: http://bugs.freeciv.org/Ticket/Display.html?id=1
There are actually quite a few reports on this topic (see PR#14969),
and several proposed solutions.
The most comprehensive requires new data structures to support the
commercial civ variants (and import of those scenarios). This
URL: http://bugs.freeciv.org/Ticket/Display.html?id=10400
Lately, your patches have been formatted with base64 as
application/octet-stream, usually reserved to binary data.
That actually makes them much longer than the original text,
and difficult to review (and impossible to search for later).
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39756
Pepeto _ wrote:
Why 2.0.10 should be different?
Because 2.0.10 does not yet exist.
The idea of compatibility (and the concept of capabilities in the
professional programming world and computer science) is that
versions interoperate
URL: http://bugs.freeciv.org/Ticket/Display.html?id=14969
The existing patch made the testing and network slightly more efficient --
using a bitvector instead of a list of pointers -- but that's too much
change for the current state of 2.1 release. I'm not sure it is really
helpful in
Daniel Markstedt wrote:
We're already a week into October, the month when 2.1.0-final is
expected. Can't we make a final effort to patch this up, releasing
beta7 followed by RC1 and shipping it with this list of known bugs?
We need to get this out of the door; it's now or never!
Forget
Marko Lindqvist wrote:
Only remaining showstopper level problem is air goto. We do have
Pepeto's patch for that, but it might require closer inspection.
Will handle.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39755
Daniel Markstedt wrote:
Backtrace from a crash attached.
A singularly non-useful trace, no symbols? It does seem to be from a
packet that does a move_unit(), I'll see whether I can reproduce
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39759
The rt.freeciv.org time has been getting progressively worse. Today,
it's more than 1/2 hour early.
In http://bugs.freeciv.org/Ticket/Display.html?id=39755
As is clear by the Correspondence added, I sent a message
Sat, 06 Oct 2007
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39755
Frozen client, who knows what's happening So far, no crash.
Anybody else with a crash traceback?
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39743
Pepeto _ wrote:
1-Static or dynamics datas?
The most of the main structures (player, connection, advance, ...)
except city and unit are declared static (for example
game.players[MAX_NUM_PLAYERS + MAX_NUM_BARBARIANS];). Is this a
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39725
Pepeto _ wrote:
There shouldn't have any rule about freelog() level translation. It must
just be adapted to the every case. It always was like this, I don't
think there is any reason to change it.
Pepeto, you are wrong. They have
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39723
Upon inspection, noticed other grammatical errors, too.
Committed trunk revision 13663.
Committed S2_2 revision 13664.
Index: settings.c
===
--- settings.c (revision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39725
Upon inspection, more errors found. Only LOG_NORMAL should be translated.
Committed trunk revision 13665.
Committed S2_2 revision 13666.
Index: client/gui-sdl/gui_string.c
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39725
Marko Lindqvist wrote:
Messages meant for end-user should be translated.
Error messages meant for users are sent as message packets.
LOG_ERROR is *never* meant for users, it is for developers.
See HACKING:
Messages and text in
Daniel Markstedt wrote:
Most of the discussion took place in PR#39690 IIRC.
Not somewhere I'd expect such a major decision to be discussed, buried at
the end of a thread discussing something else entirely.
I'm opposed to removing embassies from the game code. It's required for
proper civ*
Thanks, see (PR#39715) Crash when discovering a Future Tech.
In the future, please post to [EMAIL PROTECTED] for tracking.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39715
Also reported by [EMAIL PROTECTED] on freeciv-dev list with savegame
and proposed patch:
Re: [Freeciv-Dev] Segfault bug in advance_has_flag in common/tech.c
Committed trunk revision 13640.
Index: server/techtools.c
Per I. Mathisen wrote:
On Mon, 24 Sep 2007, William Allen Simpson wrote:
Apparently without discussion, 2.1 has been officially abandoned, as 2.2
has been branched in the repository.
If you did not read the discussion, how could you reach the conclusion it
has been abandoned? The plan
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39718
Great! Normally, this would be svn moved first and then updated.
Also, all the other nations have to be updated for cross-references.
I think this kind of thing should definitely be fixed for 2.1!
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39609
William Allen Simpson wrote:
Does anybody remember? Otherwise, I'm getting rid of it.
Going, going, gone.
Index: client/control.c
===
--- client/control.c(revision
Brian Dunstan wrote:
This soon produced a segfault which I traced to
advance_has_flag() in common/tech.c
Thanks for the savegame. Your proposed patch should not be applied, as
the whole point of the function is to find bad indices, and use the
segfault to locate the bad call!
The proper
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39714
Petr Baudis wrote:
... Server crashed to me when I was researching
the last technology in tree and entered a hut with a unit.
Mine, am looking at this end case
___
Freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39714
Yes, debugging accidentally left during commit for PR#39525. Thanks for
the clue! Committed revision 13614.
Index: common/tech.c
===
--- common/tech.c (revision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39715
That's correct. This is related to the debugging in PR#39714.
The flags aren't valid for A_FUTURE (or A_UNKNOWN or A_UNUSED), and these
should never be set to TECH_KNOWN. Where is that happening?
Please send traceback! And savegame
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39698
Daniel Markstedt wrote:
So is it impossible to create a ruleset for 2.1.99 that defines only
one ocean type?
Well, I'm pretty sure there are a couple of ways
The easiest would be to create the world, and then hand edit the file
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39698
Daniel Markstedt wrote:
Ok, so instead of backtracking with 2.2, would it be possible to add a
forward-compatibility layer to 2.1? Simply speaking, the savegame code
would read a 2.2 map and interpret ' ' '.' ',' ';' etc as identical
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39698
It may be possible to use the trunk (2.1.99) editor for 2.1, but it's not
practical. The 2.1 files are two years older and incompatible. Sadly,
some powers that be decided not to include the editor in 2.1.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39693
Daniel Markstedt wrote:
It's IMHO ok to add new translatable strings while implementing new
functionality. What should be avoided is making minor adjustments to
existing ones.
Wasn't new functionality, was a 2.1 bug fix. But OK,
Egor Vyscrebentsov wrote:
This change cause snapshots tarball making to break. No errors in this
commit, every change of api.pkg will break 'make dist': tolua is not
made. One more reason I'm againt of just removing generated files
from svn. (Not that our Makefiles are ok, though)
My
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39637
My mistake. Checking the history, it should be building.
Committed revision 13559.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39609
As I was testing several related bugs (PR#29982, PR#39339, PR#39430):
goto_get_turns: Assertion unit_is_in_focus(punit) failed
I found that hitting escape caused the list of focused units to disappear.
Clicking anywhere on the map
URL: http://bugs.freeciv.org/Ticket/Display.html?id=18010
Pepeto _ wrote:
15) the first tile (the unit tile) is an invalid destination when the
unit just entered in the goto state whereas, it's valid if you move
first the cursor on an other tile.
Odd, pf_* code is sometimes returning a
URL: http://bugs.freeciv.org/Ticket/Display.html?id=29982
The described test works in current code. Moreover, there was no assert
anymore in goto_get_turns(), even before PR#18010 revisions.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39339
There was no assert anymore in goto_get_turns(), even prior to recent
PR#18010 revisions.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39339
Correction, it was hidden in goto_map_iterate() definition.
However, this may be related to PR#29982 and/or PR#39340, dealing with
unit focus during clicks on sidebar and popups respectively.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39430
The described test works in current code, presumably due to recent
PR#18010 revisions.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=18010
11) request_unit_connect() doesn't update the cursor (to show invalid).
12) Escape to back out of waypoints doesn't work for HOVER_CONNECT
(missing in test of hover_state).
13) The number of turns displayed in client/text.c (and
URL: http://bugs.freeciv.org/Ticket/Display.html?id=18010
The working patch for trunk handles all the above issues. (The patch
for S2_1 differs in 2 lines, but we're waiting for a beta release.)
Index: client/control.c
===
---
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39596
Consolidate mandatory capabilities.
Left ReportFreezeFix, as this is not in trunk and therefore may be removed
before conclusion of beta cycle.
Not yet checked in, as PR#19481 (Commits 13355 and 13356) broke compile for
non-windows
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39597
PR#19481 (commits 13355 and 13356) broke compile for non-windows systems.
In file included from netintf.c:57:
netintf.h:64: warning: redefinition of `socklen_t'
/usr/include/sys/socket.h:79: warning: `socklen_t' previously declared here
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39597
Specifically, for all BSD systems!
socklen_t was originally created and defined for BSD, belongs in
sys/socket.h, and is always 32-bits (as a field in a struct).
Apparently, some other systems toss it in the wrong place, and are not
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39596
Daniel Markstedt wrote:
Compiles here on OSX 10.3.9. Setup-specific problem?
Doesn't compile on MacOS 10.3.9 here, running up-to-date MacPorts.
Of course, I seem to remember there were header differences in Daniel's
setup that throw
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39596
Committed S2_1 revision 13366.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
(PR#39596) 2.1.0 capability cleanup
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Daniel Markstedt wrote:
Fine, I'll schedule a new release for Friday then. Would that give you
enough time to root out any obvious issues?
Friday?!?! I thought we were going to do it yesterday
I'll see whether I can re-architect Pepeto's goto fixes. Cannot promise
anything. But I was
URL: http://bugs.freeciv.org/Ticket/Display.html?id=18010
I've tracked the problem to:
r11378 | jdorje | 2005-12-23 -- PR#14365, battlegroups, and
r11391 | jdorje | 2005-12-26 -- PR#14992, unitlists.
The code is still almost identical in both S2_1 and trunk.
There are quite a few problems
Marko Lindqvist wrote:
But we agree that earlier release would be better than waiting for
this? I can accept waiting up to Sunday, though.
Oh, absolutely!
The only thing I see is the PR#39599 and PR#39600, as they are needed to
compile
___
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39584
Marko Lindqvist wrote:
No po/Makefile of any kind is generated if there is --disable-nls
configure option.
To reproduce:
mkdir completely_empty_builddir
cd completely_empty_builddir
../freeciv.src/autogen.sh --disable-nls
401 - 500 of 666 matches
Mail list logo
