I chose to post this here instead of the RiscPkg list, since that is slightly user oriented, although it would be just as appropriate there.
The mysterious failure with the Firefox 2.0.0.14 packages on riscos.info is in general, due some of the filenames in the zip file containing the '@' sign. This is translated by SparkFS into a '=', and possibly by InfoZip et al into a '_', which is the UnixLib mapping for riscosify. RiscPkg only does swapping on '.' and '/'. I changed one of the calls to use riscosify instead, which helped it proceed, but later it does a reverse call, expecting to get the same name back (does another . and / swap) and the mapping in UnixLib isn't one to one either, unavoidably. So, there's a couple of things here: * Probably extensions in Firefox don't work, due to path name issues. * RiscPkg needs better error reporting - it was just saying "name not recognised", which it gets back from FileSwitch. * We need to be more careful with filenames in packages. Whether this involves post-processing/checking with our packaging scripts, or some other better approach with RiscPkg, I'm not certain right now. Arguably, I could just fix the filenames in Firefox, and we might never see this again - but then again, we might. Comments welcome. _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
