Hi, first of all thanks a lot for the answer. El Dimecres, 9 de setembre de 2015, a les 23:06:24, James Cowgill va escriure: > Hi, > > [I have trimmed the CC list quite a bit on the basis that it's the > games team who actually maintain the package] Yes, but I added the people that maintain packages that uses libode, that's why I put them. > On Wed, 2015-09-09 at 14:30 +0200, Leopold Palomo-Avellaneda wrote: > > I have been working with libode and I have done some changes. Some > > important changes. > > > > * New upstream version. I have packaged 0.13.1~git20150309 because this > > version contains a patch to select the libccd of the system instead the > > internal version. Now that we have libccd I have preferred to check out > > that. > > > > * New Soname. Upstream uses 4 as its Soname, instead the 1 that we use in > > debian. I have not check it it, and I don't know if they are binary > > compatible. > > I had a brief look, a few symbols were removed so the soname does need > to change. Ok, thanks to look it. > > > But, I'm almost sure that with gcc5 it will be incompatible with > > > > the previous version. > > There doesn't appear to be any public C++11 symbols exported by libode > so its ABI is not affected by the libstdc++ transition (it just needs a > rebuild). As we changed the ABI, it will work. > > * Dropped sp and dp versions. I have used this criteria: 64 bits platforms > > double precision; 32 bits platforms single precision. > > There is a reason libode is built for both double and single precision. > See bug #534177 > > Also why are 64-bit platforms 'better' at doing double precision > floating point math? Well, this is a point that I was thinking and arrive to the conclusion to drop it. Let me expose my idea: That bug made a reference about that, in lower hardware (32 bits) ode is too slow. Why? because include/ode/common.h: #if defined(dSINGLE) typedef float dReal; #ifdef dDOUBLE #error You can only #define dSINGLE or dDOUBLE, not both. #endif // dDOUBLE #elif defined(dDOUBLE) typedef double dReal; #else so, with DOUBLE ode uses doubles, and with SINGLE ode uses floats. That means that with 32 bit platforms, if we use floats (4 bytes = 32 bits), every operation is done with one cpu step (?), but if we uses doubles (8 bytes = 64 bits), every operation needs two, so it becomes slooow. I think that we can have the same package in debian, but with the platforms with 32 bits using single precision and with 64 double. With this solution I think that all the needs would be covered. It's more simple to maintain and we don't have duplication of packages. > > So, if I'm not wrong, > > > > Debian Archs 32 bits: armel, armhf, i386, powerpc, powerpcspe, sh4 > > > > Debian Archs 64 bits: alpha, amd64, hppa, mips, mipsel, ppc64, ppc64el, > > s390x, and x32 > > > > If I have done some mistake, please tell me it, because it has been a bit > > laborious to obtain this info. > > You want 'dpkg-architecture -qDEB_HOST_ARCH_BITS' - this will ensure > you package still works if any new architectures are added (also mips > and mipsel are 32-bit). Changed!!!! thanks to you and Guillem. > > * This change has simplified the rules file. No soname hacks, double > > compilation, etc. > > In the rules file, you should also be able to remove all the CFLAGS > (and other flags) handling since debhelper will sort it all out for > you. Debhelper will also set prefix, mandir and libdir for you (when > building an autotools package). > the CFLAGS were set in the old rules. I drop it. > Use should use dh-autoreconf instead of autotools-dev. > See this page: https://wiki.debian.org/Autoreconf and bug #752463. Well, this point has been difficult for me. I must admit that I'm not comfortable with autotools. But I don't agree about your recommendation. ode needs a bootstrap to generate the needed files. As the Autoreconf wiki says: > In general dh-autoreconf is a superset of autotools-dev and using it is > sufficent and best practice. However it's actually a bit complicated so > sometimes you need both, and sometimes getting dh-autoreconf working with > an old package involves some work and using autotools-dev (invariably > straightforward) is a much simpler and often-sufficient fix. So, I used it. > Most packages use automake and/or libtool as well as autoconf, in which case > using dh-autoreconf is all that's needed. It didn't work for ode, or I didn't know know to make it work. > automake, libtool and autotools-dev all contain config.{sub,guess} files. > autoconf, cdbs, debhelper and dh-autoreconf don't include these files (and > don't depend on packages that do) ode needs them. > So this means that using dh-autoreconf on packages which only use autoconf > (but not automake) (even with debhelper or CDBS) is not enough to update > config.{sub,guess}. In this case you need to use both dh-autoreconf and > autotools-dev. with previous version of ode, upstream provided configure and so on. Since 0.13, I think, upstream doesn't provide it, so I need to create them. I have done several tries with dh-autoreconf and none worked for me. I insist, I'm not an expert (I prefer cmake) and the current option builds fine in a pbuilder env. > Why are you removing debian/ode-config.1 in override_dh_auto_clean? because is autogenerated, so I would like to clean when I do a clean. But, you are right. Deleted. > > * I have still pending to rewrite the copyright file. As it's a boring and > > tedious work (necessary ...) I would prefer to have some kind of sponsor > > before. > > > > * Still pending to MultiArch. But the work is half done. > > > > * Added myself as Uploader > > > > So, please, could some of you review it, comment it, and possibly be an > > sponsor (after revision)? > > A few more things: > > There is a syntax error in debian/control (blank line in top section). Thanks, solved. > libode0c2 and ode-dev do not exist anywhere in Debian anymore so you > don't need to conflict/replaces against them. Thanks, deleted. > Do not conflict/replaces libode4 against libode1 since it prevents > clean library transitions. There doesn't seem to be any file conflicts > in the two packages anyway. true, my mistake. > > debian/changelog does not contain an entry for version 2:0.11.1-4.1 True, I worked from the svn and import the history. I add that entry. Thanks. > > Best regards, > > > > Leopold > > > > PD lintian is clean or errors. Some warnings but. > > Most sponsors will require all the errors and warnings to be fixed (or > a valid reason why they shouldn't be). Working on, thanks, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia ------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Attachment:
signature.asc
Description: This is a digitally signed message part.