project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Punkie

Pages: [1] 2
1
Linux / Re: Download
« on: December 12, 2010, 09:03:32 am »
scroll to the top of your screen. Look for "download".
http://ufoai.ninex.info/wiki/index.php/Download

2
Linux / Re: No Linux download package for 2.3.1? (besides source)
« on: December 06, 2010, 10:50:01 am »
Universal linux package? That calls for a universal linux distro if you ask me.

Perhaps something like
Zero Install
Listaller
Mojosetup
Autopackage

3
Linux / Re: No Linux download package for 2.3.1? (besides source)
« on: December 05, 2010, 02:52:41 pm »
Which flavor would you like? A lot of distros have a package in their repos. If it aint in yours, you might snatch the one from a distro that is closely related.

4
Bugs prior to release 2.4 / Production time displayed as 0
« on: November 29, 2010, 09:29:58 pm »
In production, each tab contains 2 lists: the list of the items being queued for manufacturing and the list of items one can choose to add to the queue. Upon selecting an item in the second list, the detail pane on the right displays the details, amongst them the "Production time". The time is always zero, '0'. Mark that the details of the items in the first list, the queue, are displayed correctly, thus not zero.

The version is from 24th of November,
commit dd30499e279c61b8bd85814bead98b79f7784b5f
or
git describe --tags
ufoai_2.1-dev1-27329-gdd30499
The 27329th commit since ufoai_2.1-dev1(rev gdd30499) :)

5
Coding / Re: "git describe" or svn revision numbering style
« on: November 20, 2010, 01:10:44 pm »
IANAGitExpert (I Am Not A Git Expert) and currently i dont have access to git.

AFAIK You dont need to look up the hash/sha1 because you can use the describe string as if it was a hash.
You can get from a sha1 to a tag decribe like experssion
Code: [Select]
% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99^0~940
The other way around? Got to be a way I suppose.
git-show ??
or maybe a shell function is needed, like
git log ufoai_2.1-dev1-27253-g51bc5ea | egrep "^commit "

For functions like rev-list that return sha1 you can make a lookupscript that processes the output
foreach s sha1 (with egrep "^commit "?)
d=`git name-rev $e`
sed -e "s/$e/$d/"
...

6
Coding / Re: "git describe" or svn revision numbering style
« on: November 20, 2010, 11:07:02 am »
How would you go from the date to a (single) hash/revision number (not a range) that git understand?

For "git describe" this is supported by git as the output is a valid revision number and thus can be used with other commands
Code: [Select]
#the revision
git checkout ufoai_2.1-dev1-27183-g3be0bf3
# list between 2 revisions before and the last
git rev-list HEAD ufoai_2.1-dev1-27183-g3be0bf3~2

7
Coding / "git describe" or svn revision numbering style
« on: November 19, 2010, 10:51:55 pm »
It is kind of hard to refer to a particular revision in git. Not only are they 40 chars long (although the first 7 are quasi unique)  but they are not a monotone increasing sequence. As a result ppl are not referring to version numbers anymore and it is hard for developers to remember a version or to know where in the timeline it is situated. But behold, numerous ppl value those same properties and they suggest the following

"git describe" as explained here and here.
In short what i understood of it:
Code: [Select]
[punkie@fed ufoai]$ git describe --tags
ufoai_2.1-dev1-27183-g3be0bf3
This revision is 27183 commits seperated from the last tag (ufoai_2.1-dev1) which is identified by the first 7 chars "g3be0bf3". In other words, we can identify this revision as 27183 though we can reset the counter whenever we can. Via a hook this string can be added to the log.

8
Coding / Re: More help needed: GIT
« on: November 19, 2010, 10:21:19 pm »
I take it those files are needed in the repo because the tools need them to be there, at least for starting the first time. But the tools change them as you work.

If so, you can move them to a subdir in the repo, then add a script that copies them. The script should be started (only) the first time thus it can be added as a target in the new Makefile.
If needed, add crc check to see if the repo'ed version changed (look at it as if it was the template). Upon a failed check, the template in the subdir and the actual user modified copy should be merged. I dont know if its needed.

9
Linux / Re: More Packages
« on: November 19, 2010, 01:11:52 pm »
btw http://ufoai.ninex.info/wiki/index.php/Manual:Installation_on_Linux is outdated and seems to relfect the same information.

10
Linux / Re: wiki dependencies
« on: November 19, 2010, 12:44:28 am »
isnt libogg-devel  necessary?

11
Coding / Re: Trailing blank lines
« on: November 19, 2010, 12:43:07 am »
How can we saveguard our own git copy? Pushing the checks as early as possible...

12
Coding / Re: Trailing blank lines
« on: November 18, 2010, 01:32:58 pm »
From the coding guidelines
Quote
# remember to put a blank line at the end of the file (GCC will complain if you don't.)
# don't put more than one blank line at the end of the file (GIT will complain if you do.)

I thought that some form of automatic formatting might take away these sorrows and guard the repo against unwanted coding.

13
Coding / Trailing blank lines
« on: November 18, 2010, 12:56:47 pm »
gcc needs one, git reject two.
It is possible to check, and adapt, any file automatically using git hooks. As this mail illustrates it can happen client side. I suppose that saveguarding the official git repo of ufoai should be useful, shouldnt it?

Is there some mechanism that might push those hooks to the clients? Such that everyone can have this enabled on their own gitclone?

14
Linux / Re: More Packages
« on: November 18, 2010, 12:30:53 pm »
How about this for the download page?

The RPM Fusion repo contains UFO:AI releases. Check RPM Fusion configuration page to setup your package manager to install it.
DIY installation:
Fedora 14, x86_64: Install binaries + game data. View the source code.
Fedora 14, i386: Install binaries + game data. View the source code.

15
Linux / Re: wiki dependencies
« on: November 18, 2010, 12:16:36 pm »
imo they should be removed completly (the deps) - they are in the package descriptions already. there is no need to maintain them twice.

I am not talking about the dependencies on the packages that distribute ufoai. They are handled by the package managers anyway.
I was referring to the packages you need to compile the source when you take it from git. These dependencies are resolved manually afaik.

I might edit it but I dont know how to maintain one list in the wiki and to display that in a couple of pages.

Pages: [1] 2