0.2.8.0 final: Release process and bugs

Help test release candidates for the next release
Post Reply
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:I'll have to revert your two path consistency changes, they broke relocatability.
'relocatability' itself is broken anyhow. binreloc presumes FHS, which nobody follows except [K]ubuntu, especially for games. I, at least, plan to find a sane alternative sometime in 0.3. In the meantime, I have the ebuild manually disabling binreloc and hardcoding paths.
Find something that works with it that doesn't break a regular install. I don't see how my change would even make a difference except in the non-default case where it was broken.
z-man wrote:The purpose of the sysinstall script is to rewrite some paths from the compiled prefix ${prefix} to the installation prefix ${PREFIX}. That I'm a braindead zombie is not the only reason why the installation process is so complicated :)
sysinstall does not change the location of scripts. It edits them in place.

armascriptdir is built on armadatadir
armadatadir is built on datadir
datadir does not need to contain prefix
therefore, you cannot assume that armascriptdir will contain prefix, which it doesn't in this case. you can only assume it contains 'datadir', the most specific build-specifiable path.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

relocatability is not broken. If, instead of assuming that things were broken because they're nto Luke's Way you actually spent some time finding out why it's there in the first place, you'd probably agree. There's a long explanation on the autopackage website on why they use FHS in the first place. Simply put, an autopackage can be installed anywhere, and in order to do that, the binary has to be relocatable. So the binary has to be able to find its data and its config files based only on its installed location, or the path it was executed from. That's what FHS is for here, it has *nothing* to do with what other distributions do. In fact, the whole point is to provide a package that's independent of distributions.

Which I explained to you once already, so you'll pardon me for being a little irritated that you blew it off since it doesn't work your way in Gentoo.

A solution that works with the binreloc stuff is best, imo, but there's no reason we can't have arguments to configure that disable it to allow for distribution-specific packages. But imo, unless you write a binreloc that's better than what we have, or find some other way to make the packages relocatable to satisfy autopackage (and rpm, which will relocate the package if you tell it to), then it's here to stay.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

We'll have the discussion on how to handle installation The Right Way later, as well as the dereaded category default. Which stays at it is, not just because it's leading in the poll.

Right now, we want autopackage and rpm to work. Last minute adjustments for bizarre distributions have to be handled with patches.

Sources are tagged, but I won't finish the builds today. Well, maybe I will, but I won't upload them. I've got installations of SuSE, Fedora, Ubuntu and Debian to test stuff on, that's going to take a while. As always, the tag is emergency-movable until a build is published.

Builders are invited to fetch v0_2_8_0 from CVS, do test builds and report or fix errors.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

Lucifer wrote:There's a long explanation on the autopackage website on why they use FHS in the first place. Simply put, an autopackage can be installed anywhere,
Anywhere with FHS, which would work just as well using ".." in paths.
Lucifer wrote:So the binary has to be able to find its data and its config files based only on its installed location, or the path it was executed from.
Or from the binary itself. My current solution idea is to have regular configuration variables for the data directories and use objcopy --add-section to insert a "DATADIR"-only config file into the binary itself.
Lucifer wrote:In fact, the whole point is to provide a package that's independent of distributions.
Great, and the package's post-install commands can inject the DATADIR into the binary just fine.

z-man: Please do not revert my fix. If your builds have issues with it, then fix whatever they have issues with. The old code is BROKEN and makes assumptions that are incorrect. There is no reason I can see that my fix will break anything, so if you expect me to figure out why it isn't working for you, don't just complain that it doesn't work-- give details.
Hopefully the new fix I did will handle your situation better. Please update the 0280 final tag to include it.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

The old code is not broken. Why did you wait until 0.2.8 is literally about to ship to raise all these issues? This is stuff that's been there for months and months, why wait until now?

For that matter, why don't you actually take some time to think about why the binreloc stuff is there in the first place? It's really irritating that you declare shit broken just because you don't like it. You've raised absolutely no reason why it's broken, other than "oh boy, gentoo doesn't like this".

LIke I said, there's a long explanation on the autopackage site for why FHS was chosen. If you're too lazy to spend the 5 minutes reading it, then I don't know what to say. How many hours are you planning on wasting because you refuse to understand the situation?
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

Lucifer wrote:The old code is not broken.
It is. Look at it.
Lucifer wrote:Why did you wait until 0.2.8 is literally about to ship to raise all these issues? This is stuff that's been there for months and months, why wait until now?
The final thread starting reminded me of the urgency to get the Gentoo stuff done.
Lucifer wrote:You've raised absolutely no reason why it (binreloc)'s broken, other than "oh boy, gentoo doesn't like this".
I certainly have. It supports only FHS, which works without binreloc.
Lucifer wrote:LIke I said, there's a long explanation on the autopackage site for why FHS was chosen.
Applications do not get the choice for filesystem layout. That is up to the OS. Autopackage has no say on the matter unless it is the native packager for the OS. If Autopackage only works on FHS compliant OS, then it is useless on most Linux-based OS.
User avatar
Self_Destructo
Round Winner
Posts: 317
Joined: Tue Jun 07, 2005 1:24 am
Location: HillBilly Country
Contact:

Post by Self_Destructo »

made a new topic, sry... had brain lag. lol
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Luke: yes, your new fix seems to work, the tag has been moved.

Problems encountered so far:
- Under SuSE, the menu icon appears twice. I'll probably remove the redundant, just-in-case ActionGame category variants in the application entry.
- The binary client builds crash on Fedora Core when run, the reason is the usual C++ library loading conflict: we want libstdc++5, the system sound library wants libstdc++6, both get loaded and the symbols get mixed. Explicitly using alsa as sound output using SDL_AUDIODRIVER works around that, so I'm thinking about hardcoding that (if it's not set by the user) for the binary builds.

A non-problem: autopackage manages to download SDL_Image on Fedora and Ubuntu where it was missing from my installation, hooray!
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:Luke: yes, your new fix seems to work, the tag has been moved.
Ok, great. I think the ebuild should work (albeit with a warning) now.
z-man wrote:- The binary client builds crash on Fedora Core when run, the reason is the usual C++ library loading conflict: we want libstdc++5, the system sound library wants libstdc++6, both get loaded and the symbols get mixed. Explicitly using alsa as sound output using SDL_AUDIODRIVER works around that, so I'm thinking about hardcoding that (if it's not set by the user) for the binary builds.
What about systems without ALSA? Or is the variable merely a preference?
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Unfortunately, no, it's an override. Which leaves several choices:
- Accept that sound does not work out of the box for some users, they'll have to set SDL_AUDIODRIVER manually (better than crashing)
- Rework the initialization order a bit so we initialize the audio system later at the moment we have crash protection (already now, if sound initialization crashes on the first start, sound will be disabled on the second start)
- Fix the crash. The only way do do that is double compilation with two versions of g++. Unfortunately, that does not work yet with our build setup, it chokes on our libraries.
- Double the number of binary packages, distribute gcc-3.3 and gcc-3.4 compilates.

I'll make sure that only the binary builds are affected, whatever I do, it'll be protected by preprocessor conditionals. For Distribution specific builds, the workarounds should not be required.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:Unfortunately, no, it's an override. Which leaves several choices:
How about try with SDL_AUDIODRIVER="alsa" and if SDL_AudioDriverName is NULL, try w/o alsa... only for those particular builds, of course...
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Yes, that was what I was thinking with "reworking the sound initialization" :) Guess I'll give that a try.

Sorry, more delays :( My laptop, holder of the Holy Release Source, wouldn't start today. It had these things often the last months. It's OK again, turns out all I needed to do was to swap the memory from one bank to the other.

The SuSE double icon is not something we do, Autopackage puts the applnks into two different directories and apparently, SuSE reads them both. We've got to live with that for now, it seems.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

Either rc5 or final should be released today... I'd suggest rc5 to get testing on the recent fixes and the ebuild... (in which case this thread should be renamed)
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

I say we go with the final release, and if we have to do 0.2.8.1 in a month or so, I'm cool with that. :)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Too late :) I'm not rebuilding the stuff I already have just so I can put it through tests on four Linuxes and four Windows again :)

Sources and 32 bit builds are up on AABeta, grab and rejoice!

64 bit autopackages to follow in a minute.

Tested systems:
Ubuntu 5.10 Breezy Badger, Debian Sarge, Fedora Core 4, SuSE 9.1 (a bit older, but that's what I already had installed), Win 98, Win 2000 Pro, Win XP Home, Win XP Pro
Testing results:
- XP Home: the GCC build of the client got stuck after screen initialization. XP Pro worked fine, so I assume it was a glitch. No other problems with the rest of the Windows builds
- Fedora Core: The RPM failed to install the menu entries correctly, the autopackage made menu entries, but the icons were missing
- SuSE: comes with libxml2 2.6.6 which is too old for our purposes, so the RPMs correctly refused to install. Autopackages work (libxml2 statically linked) only but every menu entry appears twice.
- Debian and Ubuntu: Autopackages work perfectly.
- I also have a SuSE 7.2, RPMs and Autopackage refuse to install as expected, it's a GCC 2.X system :)
Post Reply