[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ode package: working on



El Dissabte, 4 d'octubre de 2014, a les 23:51:04, Markus Koschany va escriure:
> [dropping Barry from CC because he is subscribed]

> On Fri, 03. Oct 15:43 Leopold Palomo-Avellaneda <leo@alaxarxa.net> wrote:
> > Hi,
> > 
> > 
> > I'm working on the ode package. I will try to propose a upload next week.
> > However, after look at the package I have some doubts that I would like to
> > comment:
> > 
> > - libode has libccd embed. I did a petition to extract it to upstream and
> > make a check to use the external version, if not the internal one, but no
> > answer.
> Hi,
> 
> If you can use the shared system library without breaking ode, that
> would be preferable. But if this is not possible for whatever reasons,
> better document it in README.source with a link to the corresponding
> upstream bug report.

Ok, I'll do it.

> 
> > The build system is autotools and I'm not so expert to make a patch. So,
> > can we provide libode with this code embed?
> 
> We have been doing this for the past five years, so probably the answer is
> yes but...(see the paragraph above)

ok

> > - Upstream has changed SONAME. Also, we have had two packages, one with
> > single precision test and another with double precision. I think that we
> > could drop the single precision package and release the double precision
> > as default in 64bit arch and single precision in 32bits arch. What do you
> > think?
> A SONAME change means changing the name of the binary package too. That
> would require a transition for all reverse dependencies but the
> timeframe for transitions is already closed for Jessie. Of course you
> could upload a new version to experimental. About single- vs. double
> precision: Your suggestion sounds reasonable but are there any r-deps
> that still require the single-precision package? Why was this package
> created in the first place?

Well, I would like to upload to Jessie this version. I didn't known the 
question of transitions closed, but libode has this r-dependencies:

The easiest:
$ apt-cache rdepends libode1sp
libode1sp
Reverse Depends:
  libode1sp:i386
  python-soya-dbg
  python-soya
  libode-sp-dev
  mokomaze

--> mokomaze and python-soya needs the single precision version. I can ask to 
the maintainers.

the difficult ...

leo@indiana:~$ apt-cache rdepends libode1
libode1
Reverse Depends:
  k3d
  libode1:i386
  xmoto
  libtaoframework-ode0.9-cil
  stormbaancoureur
  python-pyode
  python-pyepl
  libompl9
  libode-dev
  mu-cade
  k3d
  darkplaces-server
  darkplaces
  libcrystalspace-2.0


if I ask to the maintainers and comment the situation and if they agree it 
could be possible to upload the new packages?


> 
> > - I think that we can drop dh-autoreconf. It was introduced in the
> > previous
> > version, not released in debian. I would prefer it, because not, recreate
> > the autotools files and it's a mess when the devscripts make the diff
> > with the orig version. What do you think?
> 
> dh-autoreconf is usually the preferred method when building packages
> with autotools. I suggest to convert debian/rules to dh-sequencer and to
> use the --with autoreconf option. I don't understand the last sentence.
> Shouldn't dh_autoreconf_clean remove all files that are recreated during
> the autoreconf step?

No, maybe I have not been clear and probably it has been my fault. This is the 
problem:
- Upstream release a sources with config.guess, configure, aclocal.m4, 
aclocal.m4, Makefile.in, etc files. T

- I work on the package in a chroot with sid and I do a debuild. As rules 
regenerate this file, the original sources are different so it complains that I 
have a different version of sources. And the only difference is that the 
original ones are for instance:

-[AM_AUTOMAKE_VERSION([1.14])dnl
+[AM_AUTOMAKE_VERSION([1.14.1])dnl

 dh $@ --with autoreconf

is who do that. If you explain me another way to solve it, perfect.


> > - Someone knows why 0.12 was never uploaded to unstable?
> 
> Sorry, no idea. Probably the usual lack of time to complete the upload.
> 

Ok,

Thanks,

Leopold

-- 
--
Linux User 152692     PGP: 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.


Reply to: