[Freeciv-Dev] [bug #13857] [Patch] Debian package building

2009-07-09 Thread Marko Lindqvist 

Update of bug #13857 (project freeciv):

Category:None => bootstrap  
  Status:None => Fixed  
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  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] Patch tracker

2009-07-09 Thread Marko Lindqvist 
2009/7/8 Daniel Markstedt :
>
> How about this for the definitions of bug and patch:
> * A patch is an issue for which you have prepared a fix or is planning
> to prepare a fix yourself. Typically used by regular contributors.
> * A bug is an issue for which you do not have a fix and wish for
> someone else to find one. Typically used by users.

 No, I think this is worse than obvious bug/feature division. Bug
report should be always in bug tracker (and searchable there) and not
depend on if I will have time to fix it myself or not.

 Votes seems to be 2-2 among all developers, and 1-1 among
Maintainers. But as this is not so big deal for me, okay, let's use
two trackers (assuming nobody else weights in at the last moment).


 - ML

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] Supporting multiple clients

2009-07-09 Thread Marko Lindqvist 
Pepeto is #13879:

> I'm sorry to remake an old discussion, but do we still continue to maintain
> all this ancestral clients that nobody didn't update for a long time?  I
> think a complicate project like Freeciv would concentrate into one only good
> client instead of having x incomplete clients.

I don't remember such discussion from the past. Do you have some
pointers for me?

Keeping clients in a compiling state is not thta much work, typically
just search and replace. At least they exist if somebody steps up and
starts actie development on some of them, like cproc did with 2.1 SDL
client.

Developers and hardcore players usually prefer GTK client for its
feature completeness.SDL client has large user base among average
players for its much better look.

IIRC some old versions of Windows cannot use gtk or sdl client, only
native client. There might be other portability issues in providing
any one client to some platforms.

Support for multiple clients has served us well in the past. That
allowed us to develop gtk client and later gtk2 client so that they
were eventually made default client. Had we decided that we will
maintain only the best client of the time, we would still be using xaw
client.


All that said, we could consider level of maintenance for each client.
FTWL has been inactive project for a long time.


 - ML

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #13867] [patch 01/07] get game settings via wrapper functions

2009-07-09 Thread John Keller 

Follow-up Comment #4, bug #13867 (project freeciv):

Ah, oops - my apologies for the noise.

I really should have read the patch before sounding off (since I clearly
misunderstood the translation tags as being used for static text rather than
calculated text). :-p

[Still... it's unfortunate that Gna doesn't attach patches to the mailed copy
of the ticket like was the case with bugs filed using RT.]

___

Reply to this item at:

  

___
  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 #13867] [patch 01/07] get game settings via wrapper functions

2009-07-09 Thread Matthias Pfafferodt 

Follow-up Comment #3, bug #13867 (project freeciv):

the idea was to switch from a translation after the
wrapper function, i.e.

_(setting_short_help(pset))

to a structure which does the translation within the
wrapper functions, i.e.

const char *setting_short_help(const struct setting *pset)
{
  return _(pset->short_help);
}

but this is not (easily) possible as both - the
untranslated as well as the translated - text
is needed. 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] Patch tracker

2009-07-09 Thread Matthias Pfafferodt 
note to myself: remember to send emails also to the mailing list ...

Am Wednesday 08 July 2009 20:50:19 schrieben Sie:
> 2009/7/8 Matthias Pfafferodt :
> >> Patch-for-bug vs. patch-for-new feature might seem clear to those
involved for a time, so it'd probably would give similar results to
simply set up tags/keywords that can be assigned by the maintainers
to
> >> sort the two types for later searches. (Assuming that, like on
bugzilla,
> >> it's possible to create/assign arbitrary tags.)
> >
> > You are right. At the moment there is one lonely patch waiting in the
patches section. I don't know if anybody found the new nation.
>  First you were for using both trackers, but then you agreed on some
> points of John's mail. Could you clarify which way you would vote at the
moment.

Sorry if it was not clear. I'm for the use of two different tracker (bugs /
patches). But I see John's point that it will create confusion.

At my first look on the new bug tracker at gna I also found it strange to 
find 'bugs' as well as 'patches' and interpreted it as said in my first
mail:

> I would like to see the split bugs <> patches into two trackers, there
bugs includes crashes / errors (+ the patches to correct them) and
patches
> contains new features to freeciv. This way it would also be easier to
check if a bug was reported before.

After nothing was posted in the section 'patches' I started to use 'bug'
for this. A clear text stating that should be reported into which tracker
on top of the corresponding pages would be helpful.

Matthias

>  Until we have agreed on something, I continue using current practice
> of posting bug reports, bugfixes and feature patches all to the same
tracker.
>  - ML

-- 
Matthias Pfafferodt - http://www.mapfa.de
Matthias.Pfafferodt  mapfa.de





___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40853) Freeciv crash

2009-07-09 Thread Ben 

http://bugs.freeciv.org/Ticket/Display.html?id=40853 >

Apple Bug report follow:

---

Process: Freeciv [24839]
Path:/Applications/Freeciv.app/Contents/MacOS/Freeciv
Identifier:  freeciv.org.Freeciv-2.1.6
Version: Freeciv-2.1.6 version 0.2 (0.2)
Code Type:   X86 (Native)
Parent Process:  launchd [75]

Interval Since Last Report:  267827 sec
Crashes Since Last Report:   3
Per-App Interval Since Last Report:  8200 sec
Per-App Crashes Since Last Report:   2

Date/Time:   2009-07-09 00:21:03.956 +0200
OS Version:  Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  5E86B6D4-C2CC-448E-81AF-38EFD2D738D0

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0004
Crashed Thread:  0

Thread 0 Crashed:
0   freeciv.org.Freeciv-2.1.6   0xc339 city_buy_production + 9
1   freeciv.org.Freeciv-2.1.6   0x00021c53
ok_buy_prod_city_dlg_callback + 51
2   freeciv.org.Freeciv-2.1.6   0x0007c5f6 widget_pressed_action + 150
3   freeciv.org.Freeciv-2.1.6   0x00047b11
main_mouse_button_down_handler + 65
4   freeciv.org.Freeciv-2.1.6   0x000487ae gui_event_loop + 702
5   freeciv.org.Freeciv-2.1.6   0x00048edf ui_main + 671
6   freeciv.org.Freeciv-2.1.6   0xf395 SDL_main + 773
7   freeciv.org.Freeciv-2.1.6   0x2ae2 -[SDLMain
applicationDidFinishLaunching:] + 66
8   com.apple.Foundation0x9378543a _nsnote_callback + 106
9   com.apple.CoreFoundation0x955b564a __CFXNotificationPost + 362
10  com.apple.CoreFoundation0x955b5923
_CFXNotificationPostNotification + 179
11  com.apple.Foundation0x93782690 -[NSNotificationCenter
postNotificationName:object:userInfo:] + 128
12  com.apple.Foundation0x9378bee8 -[NSNotificationCenter
postNotificationName:object:] + 56
13  com.apple.AppKit0x9067642a -[NSApplication
_postDidFinishNotification] + 125
14  com.apple.AppKit0x90676339 -[NSApplication
_sendFinishLaunchingNotification] + 77
15  com.apple.AppKit0x905efe53
-[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 284
16  com.apple.AppKit0x905ef64c
-[NSApplication(NSAppleEventHandling)
_handleCoreEvent:withReplyEvent:] + 98
17  com.apple.Foundation0x937f -[NSAppleEventManager
dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 655
18  com.apple.Foundation0x937aa7bf
_NSAppleEventManagerGenericHandler + 223
19  com.apple.AE0x956a8648
aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned
char*) + 144
20  com.apple.AE0x956a857e
dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44
21  com.apple.AE0x956a8425 aeProcessAppleEvent + 177
22  com.apple.HIToolbox 0x95ace961 AEProcessAppleEvent + 38
23  com.apple.AppKit0x905ecf21 _DPSNextEvent + 1189
24  com.apple.AppKit0x905ec5c0 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
25  com.apple.AppKit0x905e55fb -[NSApplication run] + 795
26  freeciv.org.Freeciv-2.1.6   0x31cc main + 1436
27  freeciv.org.Freeciv-2.1.6   0x28a6 start + 54

Thread 1:
0   libSystem.B.dylib   0x953fa286 mach_msg_trap + 10
1   libSystem.B.dylib   0x95401a7c mach_msg + 72
2   com.apple.CoreFoundation0x955d404e CFRunLoopRunSpecific + 1790
3   com.apple.CoreFoundation0x955d4c78 CFRunLoopRunInMode + 88
4   com.apple.audio.CoreAudio   0x9305b5f8
HALRunLoop::OwnThread(void*) + 160
5   com.apple.audio.CoreAudio   0x9305b480
CAPThread::Entry(CAPThread*) + 96
6   libSystem.B.dylib   0x9542b155 _pthread_start + 321
7   libSystem.B.dylib   0x9542b012 thread_start + 34

Thread 2:
0   libSystem.B.dylib   0x953fa2e6
semaphore_timedwait_signal_trap + 10
1   libSystem.B.dylib   0x9542c2af _pthread_cond_wait + 1244
2   libSystem.B.dylib   0x9542db33
pthread_cond_timedwait_relative_np + 47
3   com.apple.audio.CoreAudio   0x9306abdf
CAGuard::WaitFor(unsigned long long) + 213
4   com.apple.audio.CoreAudio   0x9306c79a
CAGuard::WaitUntil(unsigned long long) + 70
5   com.apple.audio.CoreAudio   0x9306af3f HP_IOThread::WorkLoop() + 759
6   com.apple.audio.CoreAudio   0x9306ac43
HP_IOThread::ThreadEntry(HP_IOThread*) + 17
7   com.apple.audio.CoreAudio   0x9305b480
CAPThread::Entry(CAPThread*) + 96
8   libSystem.B.dylib   0x9542b155 _pthread_start + 321
9   libSystem.B.dylib   0x9542b012 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
 eax: 0x0004  ebx: 0x0003  ecx: 0xa0399a24  edx: 0x29b07710
 edi: 0x02e0102a  esi: 0x29b07710  ebp: