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.