[Freeciv-Dev] [patch #3814] Remove gui-win32 from S2_4
Follow-up Comment #1, patch #3814 (project freeciv): - Update documentation - Remove gui-win32 from doxygen exclude directories - Remove gui-win32 specific options. This changes contents of the configuration file, but that's not breaking compatibility as those values have never been really used in S2_4 - Removed some code comments referring to gui-win32 (file #17655) ___ Additional Item Attachment: File name: Win32Rm-S2_4-2.patch Size:11 KB ___ Reply to this item at: http://gna.org/patch/?3814 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3825] Remove nonexistent directories from doxygen exlude list
URL: http://gna.org/patch/?3825 Summary: Remove nonexistent directories from doxygen exlude list Project: Freeciv Submitted by: cazfi Submitted on: Tue 02 Apr 2013 11:27:13 AM EEST Category: docs Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Remove completely removed directories from doxygen configuration list of directories to exclude. ___ File Attachments: --- Date: Tue 02 Apr 2013 11:27:13 AM EEST Name: DoxygenExclude.patch Size: 702B By: cazfi http://gna.org/patch/download.php?file_id=17656 ___ Reply to this item at: http://gna.org/patch/?3825 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Movement-shared roads
For my ruleset, I'd like to have some roads that share movement. Two examples that may be useful for discussion: having a Track with move_cost 3 be a prerequisite for road for only certain terrains, and having a Canal that acts like a river, except it needs building, requires technology, and has some other unfortunate side effects. In the case of Track, the easy way to implement it in the ruleset would be to have two different sorts of road (Road, Mountain Road) that share a flag, and set Rail to depend upon that flag rather than depending on a road being emplaced. Mountain Road could then be dependent on the appropriate terrain flag and the presence of a Track. In the case of Canal, the easy way to implement it in the ruleset is to ignore move_cost entirely, and only make it native for unit classes without UCF_TERRAIN_SPEED. In the first case, this is frustrating because units would require SINGLE_MOVE (or more) move points to move from Road to Mountain Road. In the second case, this is frustrating because it's hard to have a logical justification for why it might be easy to travel along a river but hard to travel along a canal: both surely have banks (and early canals usually had parallel oxtracks or similar), or, if the rationalisation involves little river rafts that the user doesn't need to micromanage (similar to the planes that fly out to drop paratroopers), then it doesn't make any sense *not* to allow them on canals. So, the solution would be to have some road compatibility check in map.c:tile_move_cost_ptrs(). There are two methods to do this in the ruleset that seem to have precedent: either define the road_class concept, and have all roads that belong to the same road_class be compatible, or to have an integrates field that takes a bitvector of roads with which the current road is compatible. The former is less expensive in terms of the necessary operations in tile_move_cost_ptrs() (because we can iterate over the road classes, and then only iterate over members internally when checking nativity, rather than having to recursively iterate all the roads for roads*roads operations), but the latter may be more comprehensible to ruleset authors (because it looks just like so many other lists in the rulesets, and there are no new concepts involved). If anyone has a recommendation for one or the other of the above mechanisms, or has some other suggestion (I'd really like something that let different unit classes have different move_costs for the same road, but haven't figured out any sane way to do that), please share. In the absence of opinion, I'd probably select the road_class implementation, because it means that implementing the reqs for canals doesn't require first allowing disjunctive requirement specification (which has it's own large set of dependencies). Thanks for your help. -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19073] Minimap is not resizable, and does not navigate properly on click.
Follow-up Comment #1, bug #19073 (project freeciv): I noticed that when scrollbars are active map is centered in wrong coords ( in gtk2 and gtk3 client ) probably overview_to_map_pos() must be updated to notice scrollbars. ___ Reply to this item at: http://gna.org/bugs/?19073 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20702] Cannot move to unknown tiles via diagonal
URL: http://gna.org/bugs/?20702 Summary: Cannot move to unknown tiles via diagonal Project: Freeciv Submitted by: mir3x Submitted on: Tue 02 Apr 2013 12:33:00 PM CEST Category: client Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: trunk Discussion Lock: Any Operating System: Any Planned Release: ___ Details: Units cannot move to black fog (unknown tiles) via diagonal using keyboard ( goto is ok ) ___ Reply to this item at: http://gna.org/bugs/?20702 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Movement-shared roads
On 2 April 2013 12:53, Emmet Hikory per...@shipstone.jp wrote: So, the solution would be to have some road compatibility check in map.c:tile_move_cost_ptrs(). There are two methods to do this in the ruleset that seem to have precedent: either define the road_class concept, and have all roads that belong to the same road_class be compatible, or to have an integrates field that takes a bitvector of roads with which the current road is compatible. The former is less expensive in terms of the necessary operations in tile_move_cost_ptrs() (because we can iterate over the road classes, and then only iterate over members internally when checking nativity, rather than having to recursively iterate all the roads for roads*roads operations), but the latter may be more comprehensible to ruleset authors (because it looks just like so many other lists in the rulesets, and there are no new concepts involved). Either is doable, even with quite clean SW architecture, but for casual modder relations of different entities might get a bit too complicated if we mix 'extras' and 'road class', which would be used with some extras (roads) only. To avoid bitvector solution being computationally expensive, cache similar to what road drawing already uses for hider roads, constructed ruleset loading time, should be implemented. (I'd really like something that let different unit classes have different move_costs for the same road, but haven't figured out any sane way to do that) In the past that kind of tables for having separate values for every combination have been rejected on basis of being unnecessary detailed for the resolution of the freeciv. That's more like Wesnoth's realm. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] S2_5 branching
As it's 30 days to S2_5 branching, my take on new feature patches coming in will now on be that they get targeted to 2.6 unless: - It complements 2.5 feature (already committed or agreed about) OR - It's very low impact: almost trivial = not bugprone, not increasing requirements in a significant manner - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Movement-shared roads
On Tue, Apr 02, 2013 at 03:27:26PM +0300, Marko Lindqvist wrote: On 2 April 2013 12:53, Emmet Hikory wrote: So, the solution would be to have some road compatibility check in map.c:tile_move_cost_ptrs(). There are two methods to do this in the ruleset that seem to have precedent: either define the road_class concept, and have all roads that belong to the same road_class be compatible, or to have an integrates field that takes a bitvector of roads with which the current road is compatible. The former is less expensive in terms of the necessary operations in tile_move_cost_ptrs() (because we can iterate over the road classes, and then only iterate over members internally when checking nativity, rather than having to recursively iterate all the roads for roads*roads operations), but the latter may be more comprehensible to ruleset authors (because it looks just like so many other lists in the rulesets, and there are no new concepts involved). Either is doable, even with quite clean SW architecture, but for casual modder relations of different entities might get a bit too complicated if we mix 'extras' and 'road class', which would be used with some extras (roads) only. To avoid bitvector solution being computationally expensive, cache similar to what road drawing already uses for hider roads, constructed ruleset loading time, should be implemented. Towards extras, I was thinking that move_cost would be a extras_class attribute, and that one would set a very high value (e.g. 99) for things which would be implemented as bases on current trunk, or similar (because 0 is a valid move_cost value, so can't safely be used as a boolean check). Depending on what other attributes might be easily considered shared, I would expect several extras_classes to be used for the current rulesets. Although this may reduce the volume of data entry for individual extras, I certainly agree that it raises the bar for ruleset authors, and may cause unnecessary confusion or reduce accessibility. I'll go with the bitvector for this then, and thanks for the pointer to cache code to make it not terribly expensive. To make sure I understand, one would iterate over the road types, and then iterate over the (presumably smaller) bitvector of identified compatible roads in map.c, and would populate the cache bitvector in ruleset.c when loading the ruleset, which precached values would be sent to the client in the road packet (no, this isn't quite the same as hiders, but this needs to also be available on the server for the AI). (I'd really like something that let different unit classes have different move_costs for the same road, but haven't figured out any sane way to do that) In the past that kind of tables for having separate values for every combination have been rejected on basis of being unnecessary detailed for the resolution of the freeciv. That's more like Wesnoth's realm. Thanks for the hint. I'll try to find a way to model what I want without these sorts of details then. I suspect I can do a lot with judicious use of UCF_TERRAIN_SPEED (as in the experimental ruleset, where Settlers and Trireme have the same movement on Rivers). -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] S2_5 branching
On Tue, Apr 02, 2013 at 03:37PM +0300, Marko Lindqvist wrote: As it's 30 days to S2_5 branching, my take on new feature patches coming in will now on be that they get targeted to 2.6 unless: - It complements 2.5 feature (already committed or agreed about) OR - It's very low impact: almost trivial = not bugprone, not increasing requirements in a significant manner I have two features for which I have yet to publish patches that I'd like to land sooner than later, as they block my local ruleset testing (and I would prefer not to port them to 2.6 later if I can avoid it). Beyond that, while there are certainly interesting features to add, I'm happy to wait until much later (as there's plenty more data entry, balancing, and graphics production to do to make my ruleset work). A) Allow constructed bases and roads in cities Currently, cities automatically get every road, and don't get (and can't build) any bases. This makes it very hard to model Mine as a base (which I want because I want to use Mining for transformation), and limits a few other things. This patch allows ruleset authors to define some bases to be automatic in cities, some to be permitted to be constructed, and some to be denied from construction. The same automatic/permission/restriction structure is also provided for roads. I'm just doing final testing on this, and ruleset adjustments for shipping rulesets (to make sure it both doesn't work for them, and doesn't cause any other behavioural difference), and expect to publish to GNA within the next several hours. B) Road compatibility Design finalisedi (see other thread): should be ready by Thursday at the latest, but probably tomorrow. Would either of these need to wait for 2.6? -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16164] Aircraft commit suicide if 'autoattack' is set
Follow-up Comment #6, bug #16164 (project freeciv): I would prefer them to not autoattack at all when on their last turn of fuel. This test should also catch units away from refuel point. Wait, what does this mean for Fighter-type units [fuel = 1]? I don't use them, and didn't think about them until i started looking more closely at a ruleset. ___ Reply to this item at: http://gna.org/bugs/?16164 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16164] Aircraft commit suicide if 'autoattack' is set
Follow-up Comment #7, bug #16164 (project freeciv): Bombers mix two concepts that may affect autoattack: 1) They are OneAttack units, which means that if they autoattack, they cannot then either move or attack again, rendering the unit useless for human control that turn. 2) They are fueled units, which means that if they autoattack in such a way that they cannot return to a refueling base, they will be destroyed at the end of the turn. The combination is especially annoying, because if they do attack, since they are OneAttack, they cannot return to base for fuel *unless* they happen to have already been on a base when they attacked (attacking tile adjacent to base) and they do not advance (occupychance=0, or the random number generator favors the player). For fighters, or other fueled units that are not OneAttack, the main consideration is whether they can return to a fueling point if they attack: fueled units presumably should not automatically perform an action which is known will prevent them for refueling that turn (causing unit loss). So a fighter *might* autoattack, as long as there was a good chance that the result of the attack would allow a return to base (even with occupychance=100). Since fighters start all turns at refueling points, and has movement far in excess of vision, there's little reason for fighters *not* to autoattack, unless they are fairly wounded, or have already fought a lot that turn and need to stay put to get fuel. For helicopters, or other OneAttack units that are not fueled (but may have other limitations, like hitpoint loss each turn), the main consideration is the balance between denying the player manual choice over their action that turn (in the case of helicopters, perhaps weakening them) and providing automanagement of initiative for response to actions by other players. There's a decent argument that they should not autoattack (because the player then has no choice about their action), but this same argument might be applied to move_rate=1 units of other types (who are OneAttack based on limited mobility, rather than explictly), which are the units that most folk *do* want to auto-attack, so it's hard to code sensibly. For units that are both OneAttack and fueled, any autoattack on their last turn of fuel is surely suicide, and it ought be a player decision to sacrifice the unit, rather than a result of automatic action (unless one happens to like playing a game where there is a strategy involved in denying opponents air power by forcing auto-attacks on weak sacrifice units, but that is probably a special case). That said, if the unit happens to be on a refueling point at the time of autoattack consideration, and has not yet attacked that turn, it is not suicide, so may be worth consideration, as they player is unlikely to want to move the unit again that turn (as it needs to be refueled, and this is a good refueling point), but that is complicated by occupychance, which may force them off the refueling point from the attack (which would then be suicide). ___ Reply to this item at: http://gna.org/bugs/?16164 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] S2_5 branching
On 2 April 2013 17:40, Emmet Hikory per...@shipstone.jp wrote: On Tue, Apr 02, 2013 at 03:37PM +0300, Marko Lindqvist wrote: As it's 30 days to S2_5 branching, my take on new feature patches coming in will now on be that they get targeted to 2.6 unless: - It complements 2.5 feature (already committed or agreed about) OR - It's very low impact: almost trivial = not bugprone, not increasing requirements in a significant manner Would either of these need to wait for 2.6? Can't make any final decisions before seeing the patches, but at least they should fit in to complement road types -feature -category. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Movement-shared roads
On 2 April 2013 17:14, Emmet Hikory per...@shipstone.jp wrote: I'll go with the bitvector for this then, and thanks for the pointer to cache code to make it not terribly expensive. To make sure I understand, one would iterate over the road types, and then iterate over the (presumably smaller) bitvector of identified compatible roads in map.c, and would populate the cache bitvector in ruleset.c when loading the ruleset, which precached values would be sent to the client in the road packet (no, this isn't quite the same as hiders, but this needs to also be available on the server for the AI). I would implement it to construct the compatible road types lists independently in the client end rather than send it over the wire, but AFAICS it doesn't much matter which solution you take. Independent construction would provide us more freedom to change the implementation during network protocol freeze. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3826] Allow bases on city tiles
URL: http://gna.org/patch/?3826 Summary: Allow bases on city tiles Project: Freeciv Submitted by: persia Submitted on: Tue 02 Apr 2013 04:29:57 PM GMT Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: This patch allows one to build bases in cities, allows cities to have inherent bases (for example, if one wanted some basic infrastructure that was best implemented with a base and upgraded appropriately with the tech tree), and allows one to only have *some* bases or roads automatically built for cities. All of this only supports ruleset authors: there should be no change in the behaviour for any shipping rulesets. Note that I'm a little uncertain about whether to set AlwaysOnCityCenter or AutoOnCityCenter flag for road_type road in civ1, civ2, and civ2civ3 rulesets, as I don't have enough historical experience playing them, nor have I ever played the games they apparently intend to model. I've done my best based on guessing from various comments in the code or reference websites, but if someone knows the intended behaviour better, these values could be adjusted. For alien, it doesn't matter because there is no requirement for Bridge Building. For classic/experimental/multiplayer, historical behaviour has been to provide a road even on river tiles prior to the discovery of Bridge Building, so AlwaysOnCityCenter is correct unless someone had intentionally changed this behaviour. Also note that while I've set Buoys to be automatically destroyed if a city is built upon them, in most of the rulesets, this is irrelevant, as they don't permit Oceanic cities: I added this mostly so that anyone performing minimal modifications to add oceanic cities wouldn't suddenly end up with buoys not being deleted. Lastly, I'm not sure I understand precisely why the previous code wanted to block base effects before creating the virtual city, but also couldn't find a good way to eliminate unsuitable bases much earlier in create_city(): there may be some interaction between the effects of unsuitable bases and some of the earlier actions taken while setting up the city. I don't believe the call can be any earlier than tile_set_owner() and map_claim_ownership(), because at that point pcity doesn't get defined in player_can_build_base(). ___ File Attachments: --- Date: Tue 02 Apr 2013 04:29:57 PM GMT Name: allow-bases-in-cities.patch Size: 37kB By: persia http://gna.org/patch/download.php?file_id=17657 ___ Reply to this item at: http://gna.org/patch/?3826 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3826] Allow bases on city tiles
Follow-up Comment #1, patch #3826 (project freeciv): whether to set AlwaysOnCityCenter or AutoOnCityCenter flag for road_type road in civ1, civ2, and civ2civ3 civ1/civ2 always had the road on city center. As up to freeciv-2.4, freeciv always gave, and expected, road to all city center tiles, including oceanic ones! AlwaysOnCityCenter is correct unless someone had intentionally changed this behaviour. That was intentionally changed when it became possible to have city center without road (one of the first commits to TRUNK after S2_4 was branched). Idea was to test how it works in gameplay and somehow change it if need arises. So far nobody has complained. Note that code has evolveld so that when city center *needs* road was first changed to roads requirements are always respected, it was impossible to have ruleset with road always on city center. AlwaysOnCityCenter flag was only later introduced. ___ Reply to this item at: http://gna.org/patch/?3826 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3826] Allow bases on city tiles
Follow-up Comment #2, patch #3826 (project freeciv): Aha! revision 21864. Sorry about that. allow-bases-in-cities+fixed-rulesets.patch should restore the prior behaviour properly, unless I missed something between 21864 and 22649 that further adjusted the values. (file #17658) ___ Additional Item Attachment: File name: allow-bases-in-cities+fixed-rulesets.patch Size:37 KB ___ Reply to this item at: http://gna.org/patch/?3826 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)
Follow-up Comment #3, bug #20682 (project freeciv): Haven't checked if something similar happens with Marines. I checked, and it happens similar. ___ Reply to this item at: http://gna.org/bugs/?20682 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20699] Bugs in undisbandable unit drowning
Follow-up Comment #1, bug #20699 (project freeciv): jtn: This particular bug was my mistake in bug #20442, reggression since 2.4.0-beta1. No need to mention in beta2 NEWS (as change relative to beta1) assuming that fix gets committed before it. ___ Reply to this item at: http://gna.org/bugs/?20699 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20663] Unloading assert failure when autoattack kills transport
Update of bug #20663 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20663 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3823] Fix gettext warnings about buildings.ruleset comments
Update of patch #3823 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3823 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3817] Generalise MR_BAD_TYPE_FOR_CITY_TAKE_OVER_BY_SEA
Update of patch #3817 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3817 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20689] Maxplayers setting gets set to number of game start players when loading savegame
Follow-up Comment #1, bug #20689 (project freeciv): This feels a bit like kludge on top of kludge. Shouldn't scenario file be giving correct maxplayers setting in the first place? Current patches are probably best thing we can get to stable branches (don't want to break scenarios that currently work on them), but in the future it should at least warn if maxplayers setting in scenario does not make sense. ___ Reply to this item at: http://gna.org/bugs/?20689 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19989] client assertion unit_list_size(ptile-units) failed
Update of bug #19989 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #6: Attached patch moves unit_move_consequences() after send_unit_info_to_onlookers(). There's several things happening between old unit_move_consequeces() call place and send_unit_info_to_onlookers(), but I don't think any of them require consequences() to be handled before them - if they do, we have a cyclic dependency, as send_..._onlookers() needs those things to be done to send correct information. (file #17660) ___ Additional Item Attachment: File name: MoveConsequencesLater.patchSize:1 KB ___ Reply to this item at: http://gna.org/bugs/?19989 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3681] Non-native tile graphic for supplied non-Amplio tilesets
Update of patch #3681 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3681 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3827] Remove obsolete isc-posix.m4
URL: http://gna.org/patch/?3827 Summary: Remove obsolete isc-posix.m4 Project: Freeciv Submitted by: cazfi Submitted on: Wed 03 Apr 2013 01:44:28 AM EEST Category: bootstrap Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Upon closer examination isc-posix.m4 appears to be unused too. Remove it. ___ File Attachments: --- Date: Wed 03 Apr 2013 01:44:28 AM EEST Name: IscPosixM4Rm.patch Size: 354B By: cazfi http://gna.org/patch/download.php?file_id=17661 ___ Reply to this item at: http://gna.org/patch/?3827 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3828] Update gtk-3.0.m4 syntax
URL: http://gna.org/patch/?3828 Summary: Update gtk-3.0.m4 syntax Project: Freeciv Submitted by: cazfi Submitted on: Wed 03 Apr 2013 02:08:52 AM EEST Category: bootstrap Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Update gtk-3.0.m4 to get rid of constructs that are deprecated even in oldest autoconf version we support, 2.61. All the other files are up to date in this respect since patch #2555, but gtk-3.0.m4 file was added after that patch. ___ File Attachments: --- Date: Wed 03 Apr 2013 02:08:52 AM EEST Name: Gtk3m4Up.patch Size: 1kB By: cazfi http://gna.org/patch/download.php?file_id=17662 ___ Reply to this item at: http://gna.org/patch/?3828 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
