Debian building

[zb]

Hello, I trying to make new debian package 112.3 for simutrans, i successfull built binaries version, but can't understand how to make pak packages, because i can't find proper sources for them (i have svn  link, but how do I get 112.3 version of pak ? not latest trunk) Almost same problems was with binaries, but i just copied the missing files from trunk and it compiled, but with pack, I have no idea how to get proper version of pak sources.

[DrSuperGood]

Hello, I trying to make new debian package 112.3 for simutrans, i successfull built binaries version, but can't understand how to make pak packages, because i can't find proper sources for them (i have svn  link, but how do I get 112.3 version of pak ? not latest trunk) Almost same problems was with binaries, but i just copied the missing files from trunk and it compiled, but with pack, I have no idea how to get proper version of pak sources.

You answered your own question on how to get the sources. That is unless you are new to SVN (which is strange since usually Linux users know all about this sort of thing).

Basically SVN (Sub-Version Numbering) can be though of as a code management system that makes developing software/file related projects easier. On top of keeping an active "current" view of the project showing the result of all changes ever made applied in order, it also keeps a history of all changes ever made (up to a policy determined point I imagine but this might as well be all of them). The idea is that in case a certain "commit" (change made to the source code / files in the project) was bad and should not have been made, it can be "reverted" (undone). It also logs what changes were made to certain files allowing one to "blame" people for any errors or mistakes introduced and how long they existed for. It also allows you to have "stable" milestones for people to acquire where the software will build and is reasonably bug free and not coupled to the active development that is going on (which may not build or be full of errors, aka what the "nightly" builds are).

You just need to locate the revision of the pak build you intend to use and then check that out using SVN.
r1215 appears to be for 112.3 pak64 as an example.

[Ters]

appears to be for 112.3 pak64 as an example

I don't think "appears to be" is really a proper answer in this situation. And how can one know, without reading through the commit messages or looking at the diffs? If done correctly, there should be tags in SVN for each released version, but there isn't.

But is the sources for the pak sets really needed at all? The pak sets are platform independent since they are just data. I don't see any reason not to use the ready-made pak set zip-files in this case.

[kierongreen]

Debian likes to use source data whereever possible so if you were trying to get Simutrans to build for including in Debian then you'd need sources. At the moment Debian only has 111.2.2.

[Ters]

I can understand that for the executables, for they are tuneable and there are linking issues. There is no advantage I can see of running makeobj oneself, unless one explicitly want a pak set different from the released version. Even Gentoo doesn't bother compiling the pak set, and they have an even greater build-from-source fetish than Debian.

And what is the sources for a pak set anyway? Why stop at makeobj? That's just the last step in a long pipeline. The true source might be some xcf or blend files. And the translation source is the translation site, not SVN, but the translation site doesn't seem to have any versioning whatsoever.

[DrSuperGood]

I think the problem is that the new pak builds for double height are not compatible with 112.3? I remember hearing that somewhere. If there are pre-built 112.3 pak sets still lying around (probably are for backwards compatibility) then it may be a good idea to link them so he can download them and avoid having to svn out old copies that were hopefully the release versions.

That said the question that people should be asking is why use 112.3 now when nightly or RC are pretty good and both do include double height support so are compatible with the latest pak sets.

I don't think "appears to be" is really a proper answer in this situation. And how can one know, without reading through the commit messages or looking at the diffs? If done correctly, there should be tags in SVN for each released version, but there isn't.

You can browse the changes for specific files (those that represent version increments which usually are done just before release). That is what I did and found that revision for 112.3 pak64. I am not sure if it was the actual release build version of the pak but it certainly was intended to be at that stage. If this is not possible from the command line you can use the GUI over at the website that hosts the SVN.

[Ters]

I think the problem is that the new pak builds for double height are not compatible with 112.3? I remember hearing that somewhere. If there are pre-built 112.3 pak sets still lying around (probably are for backwards compatibility) then it may be a good idea to link them so he can download them and avoid having to svn out old copies that were hopefully the release versions.

All releases remain available on Sourceforge. Here's pak64 as an example: http://sourceforge.net/projects/simutrans/files/pak64/
This is the only certain way of getting matching game (source or binaries) and pak sets (in pak format). I'm not sure all pak sets have coordinated versioning in VCS.

[Vladki]

Once I did look for older releases of pak128, so here are the svn revision numbers:

pak128-1.99     r494
pak128-2.0      r615
pak128-2.1      r806
pak128-2.2      r1123
pak128-2.3      r1188

HTH.

[Ters]

Once I did look for older releases of pak128, so here are the svn revision numbers:

pak128-1.99     r494
pak128-2.0      r615
pak128-2.1      r806
pak128-2.2      r1123
pak128-2.3      r1188

HTH.

But which Simutrans versions do these correspond to? As I understand it, the OP wants to know how to find the pak128 that belongs to Simutrans 112.3 (according to Sourceforge, there isn't any new one for that version), and prossibly for future releases as well.

[DrSuperGood]

pak128-2.3      r1188

When starting up 112.3 with pak128 the loading bar says 2.3 above it.

[zb]

So I really not understand, why the releases not tagged, (for main repo also, i just downloaded sources from sourceforge, not for svn), how one can semiautomate upstream build ? I think this is one of reasons which make old  maintaner to stop maintanace simutrans. With git I ususaly do

git pull
git checkout 112.3

but github branch also stopped tags on 111 version... why that ?

[Vladki]

svn checkout -r 1188 svn://svn.code.sf.net/p/simutrans/code/pak128 pak128.stable

[DrSuperGood]

The main problem with paksets is that potentially the same stable version of simutrans could receive multiple versions of a pakset since nothing forces that they undergo the same revision cycling. I think this is what is happening with the one German comic pak since it is developed privately and unrelated with the development of the standard pak sets and game.

[Ters]

So I really not understand, why the releases not tagged

Because nobody bothered, or nobody knew how, or both. We Simutrans developers don't have much need for it.

how one can semiautomate upstream build ?

By using the source snapshots from Sourceforge.

but github branch also stopped tags on 111 version... why that ?

The github mirrors are unofficial pet projects of some individuals, only a few of which belong to the Simutrans developer "team".

The main problem with paksets is that potentially the same stable version of simutrans could receive multiple versions of a pakset since nothing forces that they undergo the same revision cycling. I think this is what is happening with the one German comic pak since it is developed privately and unrelated with the development of the standard pak sets and game.

This is very important. pak64, which is the successor to the original "pak set" (from before there were pak sets), is the only one that I know has synchronized releases to the game itself. Since pak64 is maintained by one of the veteran developers, it is generally the first to make use of new features.

[Leartin]

The main problem with paksets is that potentially the same stable version of simutrans could receive multiple versions of a pakset since nothing forces that they undergo the same revision cycling. I think this is what is happening with the one German comic pak since it is developed privately and unrelated with the development of the standard pak sets and game.

No need to force anything, you know, it's enough to kindly ask. Or explain what's going on, since I never guessed there would be a need to match them. (though technically, version 0.2.2 was for 112.2, so you could say 0.3 was for 112.3 so we neither had more nor less releases then the base game)
What are the standard pak sets anyway?

[zb]

svn checkout -r 1188 svn://svn.code.sf.net/p/simutrans/code/pak128 pak128.stable

so next time release done I will have to ask here to get the commit id ?

[zb]

No need to force anything, you know, it's enough to kindly ask. Or explain what's going on, since I never guessed there would be a need to match them. (though technically, version 0.2.2 was for 112.2, so you could say 0.3 was for 112.3 so we neither had more nor less releases then the base game)
What are the standard pak sets anyway?

Ok, how to get simutrans release ? not pack by now, from svn please, because one which  sourceforge gives as zip not buildable. (it has no some important files for build)

[Vladki]

so next time release done I will have to ask here to get the commit id ?

Not here. You can find it yourself. Go to svn web  ASAP after release and browse the comments in commits. The version number is in one of the dat files.

Sent using recycled electrons.

[Ters]

one which  sourceforge gives as zip not buildable. (it has no some important files for build)

Could you be specific, because if it's not usable, then something is really wrong? This zip is probably the only supported way of building versioned releases. SVN might be messed up, but the zip can always be fixed if something went wrong in the release process. I would actually have expected the opposite problem, because there are files needed to produce a game distribution that are not in svn (although they might be missing from the zip as well, I only do modified head builds from svn anyway).

Go to svn web  ASAP after release and browse the comments in commits.

What if they don't have the time for such things, both to constantly check for new releases or to do changelist archeology? Is a few months later soon enough?

[kierongreen]

What if they don't have the time for such things, both to constantly check for new releases or to do changelist archeology? Is a few months later soon enough?

Exactly - we should be helping maintainers who want to build for distributions like Debian (which also transfers to Ubuntu) as much as we can. At the very least an email to them when there has been a release giving the revision numbers for the svn for the code and paksets which work with that release.


It's also worth pointing out that if we get things sorted out properly we can have nightly svn commits going into Debian unstable giving a larger audience for fixing bugs.

[Ters]

Exactly - we should be helping maintainers who want to build for distributions like Debian (which also transfers to Ubuntu) as much as we can. At the very least an email to them when there has been a release giving the revision numbers for the svn for the code and paksets which work with that release.

If we do as much, it shouldn't be much more trouble to tag it as well. At least the main program repository has the proper structure, except that the tags directory is missing. The pak sets are much more difficult, but they have their own release cycles and versioning as well, beyond the control of the core Simutrans and pak64 maintainers.

It's also worth pointing out that if we get things sorted out properly we can have nightly svn commits going into Debian unstable giving a larger audience for fixing bugs.

For this to really work, we need a stable branch to do bug-fixes on.

[zb]

Could you be specific, because if it's not usable, then something is really wrong? This zip is probably the only supported way of building versioned releases. SVN might be messed up, but the zip can always be fixed if something went wrong in the release process. I would actually have expected the opposite problem, because there are files needed to produce a game distribution that are not in svn (although they might be missing from the zip as well, I only do modified head builds from svn anyway).

yes, it has no makeobj and nettool buildable versions (makeobj not builds because uncommon.mk not present, nettool has no Makefile , also it has almost empty simutrans/ subdirectory

What if they don't have the time for such things, both to constantly check for new releases or to do changelist archeology? Is a few months later soon enough?

Exatly, this is my point.  If the things would be more clean I plan to make release builds in semi-automated mode + nightly builds of current trunk, also I plan to escalate this to bring simutrans back to Debian repository, by finding maintainer or maintain it myself,

[kierongreen]

Exatly, this is my point.  If the things would be more clean I plan to make release builds in semi-automated mode + nightly builds of current trunk, also I plan to escalate this to bring simutrans back to Debian repository, by finding maintainer or maintain it myself,

This would be brilliant

The only uncommon.mk I can see is in the trunk/ directory - what is this used for? makeobj builds fine on my Debian system without it.

[zb]

This would be brilliant

The only uncommon.mk I can see is in the trunk/ directory - what is this used for? makeobj builds fine on my Debian system without it.

I don't know why it need uncommon.mk, but Makefile has the following sting in Makefile

include ../uncommon.mk

[Ters]

The only uncommon.mk I can see is in the trunk/ directory - what is this used for? makeobj builds fine on my Debian system without it.

uncommon.mk seems to be common.mk for makeobj and nettool. There is no way these can build without it, as it contains all the basic rules.

[cheesehead]

so next time release done I will have to ask here to get the commit id ?

Well, I have always used the commit ID from the release announcement.
Admittedly not the easiest to parse. But not terribly difficult either.
I used to keep a semi-automated tracker of commit IDs, the corresponding release number, and which version was in the various releases of Debian and Ubuntu. Perhaps I should dust it off...

There are problems with the Debian package beyond getting the most recent upload. There are bug patches, lintian warnings to fix, a manpage to write, and figuring out why 111.3.1 hasn't migrated out of experimental in two years. See https://tracker.debian.org/pkg/simutrans

I think it will take a few of us to work  all those issues...but the promise of updated (and more) Ubuntu packages is a tempting reward.

zb, are you by chance a member of Debian Games? Do you have upload permission?

[zb]

Well, I have always used the commit ID from the release announcement.

Ok, why not just simply tag release commit ? (I not so fammilar with svn, it is so hard there?)

Admittedly not the easiest to parse. But not terribly difficult either.
I used to keep a semi-automated tracker of commit IDs, the corresponding release number, and which version was in the various releases of Debian and Ubuntu. Perhaps I should dust it off...

There are problems with the Debian package beyond getting the most recent upload. There are bug patches, lintian warnings to fix, a manpage to write, and figuring out why 111.3.1 hasn't migrated out of experimental in two years. See https://tracker.debian.org/pkg/simutrans

I think it will take a few of us to work  all those issues...but the promise of updated (and more) Ubuntu packages is a tempting reward.

zb, are you by chance a member of Debian Games? Do you have upload permission?

No I would just try to make stable buildings  and 3rd party repo, but stuck with just versioning.

[Ters]

Ok, why not just simply tag release commit ? (I not so fammilar with svn, it is so hard there?)

It's not particularly hard, but it is of little or no use to us in the Simutrans community. Simutrans development does not use branches, and since tags in svn are technically branches, updating our local copies forward to a specific revision rather than moving sideways to a branch is easier and much the same as updating our local copies to head. We also don't have to move sideways to keep up with trunk afterwards. Knowing what revision a release is also gives us building from trunk head an indication of whether our local working directories are older, newer or equal to the released version.

So it's not that tagging is hard to do, it's just that tags have not proven useful to us. And in a sense, the absense of tags have now proven useful, because it gave us feedback that the source release zip doesn't work.