Branched for 0.2.8

Website · Post by **Z-Man** » Mon Aug 01, 2005 6:00 pm

As planned, I branched the CVS repository for the upcoming release. The branch's name is b0_2_8, its basepoint has been tagged Root_b0_2_8 for future reference.

Maybe this is repeating the obvious to most readers: The purpose of the branch is to split bugfixing and cleanups for the next version (will be on the branch) from dirty day-to-day development (on the trunk).

Developers should
- Check out or update one of their working local repositories with the extra "-r b0_2_8" argument to CVS
- Do bugfixes ONLY on the branch if the branch is affected
- Don't do massive refactoring or reformatting in either the branch or the trunk at least until 0.2.8.0 is out (mainly a reminder to myself)
- New features should go to the trunk by default. Really tiny ones like turning a hardcoded number into a configuration item and features required to fix bugs are examples of sensible exceptions.

The reason for the second and third rule is that I'll periodically merge the canges on the branch back into the trunk (It's quite possible without confusing CVS). Fixing a bug twice is not required, and massive changes make merging difficult or impossible.

Note also that all modules have the branch, so don't forget to tune armagetronad_build_* to the branch as well. This goes especially for the two modules that contain build setups for Windows.

Users can also use the "-r b0_2_8" option to tune their CVS checkouts to the branch. Certainly the first weeks will be a bit chaotic and stability of the branched code may go down initially. After that, it should be expected that the average quality of the branch will be higher than that of the trunk, and the branch contains what will become 0.2.8.0 eventually, so we can always use people who test it.

Users who don't use CVS, but rely on the snapshots on AABeta can use the Branch selection and set it to 0.2.8 to fetch snapshots built from the branch. Of course, there's nothing there yet.

Post by **Lucifer** » Mon Aug 01, 2005 7:42 pm

I assume we're moving the release discussion here now?

Trying to build the mandriva package with the branch's head (heh heh), I found a couple of interesting problems.

1. RPM is very limited on what characters it takes in the version. So I had to put 0.2.8.0 in the spec file.

2. Because I had to put 0.2.8.0 in the Version: field in the spec file, I put 0.betaDATE.1mdk in the Release: field. (This is an important detail, pay attention)

3. So rpm -ba mandriva/blahblah.spec caused rpm to look for a file called "armagetronad-0.2.8.0.tar.bz2" to use to build the package.

4. This is where it starts getting nasty.

So I went to my RPMROOT/SOURCES directory, unpacked the armagetron package, renamed the directory (to match the new name of the package) and the package, and repacked it.

5. The build succeeded all the way up until it had to build the documentation, which depended on a different version than what I'm trying to build with. I'm going to try hacking something to get it to look like 0.2.8.0 so I can build the package, but then I'll have to really test it before I release it to make sure it'll actually work.

Ack, building packages is fun, it really is, it truly is.

Post by **Lucifer** » Mon Aug 01, 2005 7:54 pm

I hate building packages, I think. I don't know why I do it so much. Heh.

Ok, changing the version in the source tree worked. I'm understanding how rpm handles the versioning a lot better now.

So, in the specfile I set the version to 0.2.8.0 and then made armagetronad/minor match, removing the _preDATE stuff. So automake then builds the package as armagetronad-0.2.8.0 and rpm builds it as that, except I suppose that in the rpm database it stores the version number + release given in the spec file.

klax · Post by **klax** » Mon Aug 01, 2005 8:16 pm

First time commiting changes to a branch with tortoisecvs.
I hope I did it right...

Website · Post by **Z-Man** » Mon Aug 01, 2005 8:55 pm

Well, actually I thought this thread was more of an information for those who did not want to follow the other ugly 200 posts thread and keep traffic low, with only occasional updates maybe to announce that an organized beta is available for download. But I guess I should have written that

But beta release announcements naturally belong into the beta forum, so I'll just respond here.

Here's what I did for the generic rpm:
Say the source has version 0.2.8.0_beta1, so there is a source archive armagetronad-0.2.8.0_beta1.tar.bz2 that unpacks into the directory armagetronad-0.2.8.0_beta1. For the RPM, I rewrite the version to be 0.2.8.0 and the release to be 0.5.beta1.1. In the specfile, I use

Code: Select all

Version: 0.2.8.0
Release: 0.5.beta1.1
Source: armagetronad-0.2.8.0_beta1.tar.bz2
...
%prep
%setup -n armagetronad-0.2.8.0_beta1

This respects RPMs preference for pristine sources. The extra argument to %setup tells RPM that the archive does not extract into armagetronad-0.2.8.0 as it would normally expect. AA itself will report version 0.2.8.0_beta1 when run.

What was the reason again that we keep the mandriva RPM build separate? Would it not make more sense to integrate the bits special to mandriva into the generic RPM and make their usage configurable in make.config?

Klax: yes, spanish.txt is updated in the branch.

Post by **Lucifer** » Mon Aug 01, 2005 8:59 pm

The reason the Mandriva rpm is separate is because of desktop entry handling, which as far as I know Mandriva does it totally differently than all other rpm-based distributions.

First run of the new Mandriva rpm shows me that "Brisish English" is spelled and spoken identicially to Spanish, but if I set the language to "American English" I get the expected language.

Marcin · Post by **Marcin** » Mon Aug 01, 2005 9:15 pm

Why I can't see my full name?

Invisible name

Incomplete name1

Incomplete name2

klax · Post by **klax** » Mon Aug 01, 2005 9:22 pm

I have the same invisible man error, but only in Windows builds (not in linux).

Website · Post by **Z-Man** » Mon Aug 01, 2005 9:36 pm

About the RPM: these bits?

Code: Select all

#menu
mkdir -p $RPM_BUILD_ROOT%{_menudir}
cat << EOF > $RPM_BUILD_ROOT%{_menudir}/%{name}
?package(%{name}):\
   command="%{name} -s '%u'"\
   icon="%{name}.png"\
    needs="x11"\
    title="Armagetron Advanced"\
    longtitle="Armagetron Advanced Light Cycle Game"\
    section="Applications/Games/Arcade"
EOF

#icons
mkdir -p $RPM_BUILD_ROOT/%_liconsdir
cat %SOURCE2 > $RPM_BUILD_ROOT/%_liconsdir/%name.png
mkdir -p $RPM_BUILD_ROOT/%_iconsdir
cat %SOURCE3 > $RPM_BUILD_ROOT/%_iconsdir/%name.png
mkdir -p $RPM_BUILD_ROOT/%_miconsdir
cat %SOURCE4 > $RPM_BUILD_ROOT/%_miconsdir/%name.png

%post
%update_menus

%postun
%clean_menus

(and the corresponding entries in %files) Indeed, they are special to Mandiva. But it should be possible to selectively include them into the generic RPM when a Mandrake machine is doing the build; this is one reason the generic specfile is composed automatically with m4 (my lazyness to update the version on every build is the stronger reason, I have to admit).

About "British English": El diablo! It may be because "British" was renamed to "British English"; was your menu still set to "British"? If so, my translation code did not work for you

(The outdated setting should be migrated to the new setting automatically) Or it was not in your build, I only committed it yesterday or so.

About the names: there is some name filtering going on now (to filter out non-ascii characters that make it difficult to /msg or kick players). The filtering may fail in Windows only because of signed/unsigned mayhem. However, your own name should not be affected by it. In theory. I'll check it when I get into Windows the next time.

Post by **Lucifer** » Mon Aug 01, 2005 9:36 pm

Oops, didn't read this whole paragraph, excuse me.

z-man wrote: What was the reason again that we keep the mandriva RPM build separate? Would it not make more sense to integrate the bits special to mandriva into the generic RPM and make their usage configurable in make.config?

The reason was nominally desktop entries. Mandriva uses a bastardized version of the same stuff Debian uses (doesn't internationalize as well, iirc, which is weird because otherwise Mandriva gets high marks for internationalizing). So special handling is needed for that stuff. Also, Mandriva has a tendency to organize itself differently in many ways from other rpm-based distributions. This wasn't a problem when everything went into PREFIX/games with wrapper scripts in PREFIX/bin, but it may become a problem later.

Most importantly, my ulterior motive is to build a Mandriva specfile that will allow Mandriva to bundle a newer version of the game for free, essentially, and if they want to adopt maintenance of the Mandriva package they can start with what I've put together (and hopefully ultimately relieve me of it). I was very disappointed when Your_mom downloaded and burned MandrakeMove so he could play Armagetron in Linux, saw his fps go from 15 to 150, and have it turn out he had to go back to 2.5.1 for all that (2.7.0 was current). Then I was additionally frustrated when 2.6.1 had some important security fixes, 2.7.1 came out too, but Mandriva only upgraded their packaged version to the faulty 2.6.0. So I'm hoping that having our own special Mandriva package that Mandriva can use as they will will allow them to include newer versions of the game than they've been including. After we've made a solid release with a good, solid Mandriva rpm (hopefully it'll be 0.2.

I'm going to break open the specfile they have now for the package they're using and email the guy listed to tell him about it.

Keeping in mind always that screenshots of Armagetron have graced Mandriva's marketing for as long as I can remember and were very much a part of what got me to install Mandrake back in the day.... (it's still in the slideshow, too, iirc, but I usually turn that off during installation)

Website · Post by **Z-Man** » Mon Aug 01, 2005 9:40 pm

Aha, I see. Of course, with these goals it would be contraproductive to jam it all together.

Post by **Lucifer** » Mon Aug 01, 2005 9:41 pm

z-man wrote: About "British English": El diablo! It may be because "British" was renamed to "British English"; was your menu still set to "British"? If so, my translation code did not work for you (The outdated setting should be migrated to the new setting automatically) Or it was not in your build, I only committed it yesterday or so.

I checked out the branch this morning to work on the Mandriva specfile, so if you committed it before branching (or to the branch directly) before today around 1pm CDT (-6 UDT, I think), then it should be there. My menus were all in Spanish and when I navigated to the language menu, it said "Brisish English".

Website · Post by **Z-Man** » Mon Aug 01, 2005 10:22 pm

Oh. I think I should get my eyes checked. I'll commit a fix shortly and make sure the fallback language is not what comes last in the alphabet (resp. first in languages.txt).

Post by **Lucifer** » Mon Aug 01, 2005 10:54 pm

Can you make the fallback language Klingon?

Website · Post by **Z-Man** » Tue Aug 02, 2005 12:18 am

Sure. Can you do the font (We do want real Klingon, right?) and the translation?
The replacement error is fixed and until the Klingon translation is ready, BE is the fallback language (and if that's not available, Spanish again). AE is already the default language and a bit of ballance is called for. I don't want a gang of Soccer Hooligans to pay me a visit next year...