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

Re: packaging advice and eventually RFS: osmo



Hi Cyril and others,

thanks a lot for your comments! I tried to fix the issues you mentioned
and updated the package:

- URL: http://mentors.debian.net/debian/pool/main/o/osmo
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/o/osmo/osmo_0.1.6-2.dsc


On Mon, 14 Jan 2008 01:47:17 +0100 Cyril Brulebois wrote:
> On 13/01/2008, Eike Nicklas wrote:
> > The package appears to be lintian clean and builds fine in pbuilder.
> 
> Actually, no for the lintian part:
> W: osmo source: desktop-file-but-no-dh_desktop-call
> 

Ah, I did not check the source package. Now I actually noticed that
'lintian <package>.changes' checks both source and binary packages...

> 
> You are already using LDFLAGS to pass -no-undefined. I'm wondering
> whether you see the (relatively new) dpkg-shlibdeps warning, stating
> that you're linking against things you shouldn't (because you're not
> using any symbol of those libs)? You could try to play with
> -Wl,--as-needed (together with the current flag) to see whether that
> helps. That's a nice occasion to learn a bit about the following:
>   objdump -x debian/osmo/usr/bin/osmo | grep NEEDED
> 
> You can also check how your Depends: line evolve, when this flag is
> passed or not.
> 
> libpthread remains, but that's AFAICT harmless and it's quite a
> particular problem (talked about with dpkg-dev developers IIRC).

Yes, I see the dpkg-shlibdeps warnings in pbuilder. Adding --as-needed
eliminated them (except for libpthread, as you mentioned).

> 
> About the --host and --build options passed to ./configure, I'd suggest
> reading autotools-dev's README.Debian. Depending on whether you're
> crosscompiling, you have to use the correct options. All details are
> there IIRC.

Thanks for the reading hint, now the package should only be
crosscompiled if necessary. By the way, I only used DEB_HOST
(BUILD)_GNU_TYPE because these lines were autogenerated by dh_make. Is
crosscomiling support actually necessary or common?

> 
> Instead of mkdir -p + install, you might just want to use “dh_install
> file location”.

done


> > One comment:
> > The upstream Makefile does not have a clean or distclean target and I
> > currently do the cleaning 'by hand' in the rules file. I contacted
> > upstream about adding a clean targed and they consider doing so when
> > time permits.
> 
> I'm able to “make clean”, which cleans “po”, “src”, and “.”, and even to
> “make distclean”. They might be doing an insufficient work but that's
> better than nothing. I'm happy to see you've already reported that
> upstream.
> 

Indeed, I tried to run 'make distclean' before the Makefile was
created :-) , i.e. on the first compilation, when the rules clean target
is called. I included a workaround that first checks whether the
Makefile exists and if so, calls 'make distclean'. Is that ok? What is
the recommended procedure here?

One more general question on closing bugs? Would a hypothetical upload
of the new revision close the ITP-bug or are only the very latest
Changelog entries considered when bugs are closed automatically on an
upload?

Thanks for your feedback,
Eike

-- 
Eike Nicklas
www.ephys.de

Attachment: pgpEvA7cHxYPG.pgp
Description: PGP signature


Reply to: