0.2.8_beta4: release process and bugs
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: luke@dashjr.org
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
You didn't close a font tag.
It is either a bug in Safari or Firefox. Safari showed all the text green. Firefox did not.
Edit: hmmm, that's odd. The w3 validator says the page is valid.
Code: Select all
Forums: <font color="green">Online</font<br/>
Edit: hmmm, that's odd. The w3 validator says the page is valid.
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: luke@dashjr.org
Nope.z-man wrote:For the record, it was Luke-Jr himself who fought long in favor of the extra zero.
IIRC, RCs were going to be just like alphas/betas, but your reasoning is sound so I don't care either way.z-man wrote:Also, the RCs WILL have the extra zero. There won't be a 0.2.8.1_beta, but maybe a 0.2.8.1_rc.
Safari is standards-compliant. FireFox is not.nemostultae wrote:It is either a bug in Safari or Firefox. Safari showed all the text green. Firefox did not.
Problems with Autopackage 0.2.8_beta4.2 (also with beta4)
The attached logs are from a red hat enterprise distribution.
I can provide additional information if needed.
The archive contains 2 logs and a filtered list of installed packages.
I can repeat the whole process with debugging / logging enabled, if I figure out how to do that .
My guess is that the problem migth be the skipped "Autopackage graphical interface" ... though autopackage installed a autopackage-gtk-frontend binary.
On the system I tried to install it, it did not run. I got the following glibc error there: (it had some pointer information, too, which I have not here @ home)
After switching to another (slightly older) system ArmagetronAd worked.
(I used the same installation which was done in text mode on the other computer. I just logged in to my home directory from another workstation).
Does ArmagetronAd's autopackage assume SDL_image to be installed ?
As I manually added SDL_image libs with LD_LIBRARY_PATH which ArmagetronAd demanded.
Hope this helps
The attached logs are from a red hat enterprise distribution.
I can provide additional information if needed.
The archive contains 2 logs and a filtered list of installed packages.
I can repeat the whole process with debugging / logging enabled, if I figure out how to do that .
My guess is that the problem migth be the skipped "Autopackage graphical interface" ... though autopackage installed a autopackage-gtk-frontend binary.
On the system I tried to install it, it did not run. I got the following glibc error there: (it had some pointer information, too, which I have not here @ home)
Code: Select all
*** glibc detected *** double free or corruption...
(I used the same installation which was done in text mode on the other computer. I just logged in to my home directory from another workstation).
Does ArmagetronAd's autopackage assume SDL_image to be installed ?
As I manually added SDL_image libs with LD_LIBRARY_PATH which ArmagetronAd demanded.
Hope this helps
You do not have the required permissions to view the files attached to this post.
Joda: the text mode installation log looks succesful, what was the problem with the resulting install? The warning about the missing trailing semicolon should be fixed in the next iteration.
The autopackages assume right now that all libraries are already installed, the 32 bit packages bring libxml2 with them. Neither me nor Lucifer could wrap our head around the skeleton files for dependencies and building AP versions of the libraries just yet.
I'll run the program throug some memory debugger with double free detection for the glibc runtime error. Strict testing is memory intensive, so I don't usually do it.
Lucifer: What build were you using?
And could you look at the graphical installer log Joda attached? Would this be the same/a similar problem than with Debian and a previous version? The logs are in German, but you'll spot the line where it says "Speicherzugriffsfehler".
The autopackages assume right now that all libraries are already installed, the 32 bit packages bring libxml2 with them. Neither me nor Lucifer could wrap our head around the skeleton files for dependencies and building AP versions of the libraries just yet.
I'll run the program throug some memory debugger with double free detection for the glibc runtime error. Strict testing is memory intensive, so I don't usually do it.
Lucifer: What build were you using?
And could you look at the graphical installer log Joda attached? Would this be the same/a similar problem than with Debian and a previous version? The logs are in German, but you'll spot the line where it says "Speicherzugriffsfehler".
It's only the GCC build. VC6 and VC8 appear to work fine, and the GCC client seems to work in server mode as well. I'll remove/unlist the build.
The reason seems to be that our custom memory manager is used (DONTUSEMEMMENAGER is undefined), but the linker order (tMemManager needs to come first or last, can't remember) was not correct. Quirky stuff, memory management, unless you use shared libraries. Well, I disabled the memory manager, and everything seems to be fine.
You can tell Joe to just grab the vc6 build.
The reason seems to be that our custom memory manager is used (DONTUSEMEMMENAGER is undefined), but the linker order (tMemManager needs to come first or last, can't remember) was not correct. Quirky stuff, memory management, unless you use shared libraries. Well, I disabled the memory manager, and everything seems to be fine.
You can tell Joe to just grab the vc6 build.