Paul Wise wrote: > On Nov 14, 2007 6:50 PM, Robin Cornelius <robin.cornelius@gmail.com> wrote: > >>> Where did the orig.tar.gz really come from? I can only find tarballs >>> and zip files that use dates as version numbers instead of 1.1.1-2. >>> >> This is where the problems start, because upstream is a mess and I have >> made the situation much worse. > > I think the best idea is to work with upstream to get it in shape > first, and then work on a Debian package. Looks like the LindenLabs > folk are interested in getting it into Debian and other distros > anyway: > > http://lwn.net/Articles/257032/ > > So, perhaps contact Rob Lanphier and find out what the situation with > llmozlib is, get involved in the development and fix up the > versioning, linking against xulrunner and so on. I have patches to create a build environment, create a shared library and use xulrunner filed in their bug tracker already. I have had discussions with Rob and Callum and they are interested but it can take a very log time to get things into there tree. I also attend the "in world" open source development meetings so its happening slowly. The one thing i do know is llmozlib is important to them (and secondlife), the latest RC release yesterday uses it more than ever. > >> I presume I should set the home page field as >> http://www.ubrowser.com/llmozlib.php set the uscan to look at the >> https://wiki.secondlife.com/wiki/Source_downloads page and make a note >> in README.debian about this? > > Right, but I don't think you need any README.debian, just the correct > URL in debian/copyright. > >> The 2nd problem is the .tar.gz file is a mess. The .orig.tar.gz came >> from http://jira.secondlife.com/browse/VWR-2977 > > Oh, so that is what you should put in debian/copyright for the > download location. I guess that URL isn't suitable for uscan though. I have changed this to the actual source code download page now and added in all the changes necessary so they appear in the debain diff. It seemed a bit crazy trying to patch in a whole autotools suite. uscan works of the source download page but they are using dates as version numbers. The 1.1.1 i used came from inside the code, it reports 1.1.1 via a function when asked but releases are date tagged. I am reluctant to commit a date tagged version at the moment until I know the situation about releases. > >> I assume the *correct* solution for this is to use the original .tar.gz >> (wiki.secondlife.com/......) and create dpatch diffs to bring it up to >> the required version. In fact the diffs would 99.99% be adding code to >> the tree (eg a Makefile and autoconf stuff and additional cpp and h >> files that are needed) as upstream has no build system at all. > > Yeah, quilt (or dpatch) would be the right way to do it, but it would > be preferable to fix upstream first, and then package the results of > that fixing. Well the plan may have to be to hold this packaging for the moment, put a little more effort into my build environment so it can build my way or the lindens way from the configure script and push this upstream and as you say package the results that come back down. Regards Robin
Attachment:
signature.asc
Description: OpenPGP digital signature