On 15/01/2008, Eike Nicklas wrote: > Ah, I did not check the source package. Now I actually noticed that > 'lintian <package>.changes' checks both source and binary packages...
Note that it depends on the options you possibly passed to debuild:
-S -> source only, *_source.changes,
-b -> binary only, *_$arch.changes,
-> source & binary, *_$arch.changes, but including both.
> 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?
Some persons are actively working on embedding Debian, and
crosscompiling. I guess it's just nice to try and not break cross
compilation, and not to enter crosscompilation mode when not needed.
It's just about doing the Right Thing©®™ (IMHO).
> 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?
The templates (and usual practices) lead to:
-$(MAKE) clean
(or the same with distclean)
But that meant ignoring errors that could happen during (dist)clean, and
it is now reported by lintian, which also suggests the following idiom:
[ ! -f Makefile ] || $(MAKE) clean
> 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?
It's a bit of a hot topic (successive revisions uploaded to mentors),
but a point on which most agree is that one upload to the archive = one
changelog entry, so you would either keep on working on the same single
revision (and mentors.d.n should do/provide with whatever is needed to
ensure mentors can look at the diffs between successive revisions), or
work on several ones, merging the changelog entries afterwards.
Anyway, you want to read about the -v option of dpkg-buildpackage, which
help including the appropriate changelog entries when it's not just the
last one (the default). You could also have a look at backports.org,
which contain detail instructions on how to provide with backports, to
see why such an option can be needed.
> Thanks for your feedback,
You're welcome.
Cheers,
--
Cyril Brulebois
pgpGK1jQTKMM0.pgp
Description: PGP signature
