Hi,
Le 2012-06-08 04:06, intrigeri a écrit :
Hi,
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.2.dsc
Great!
+ * New OpenPGP key.
I doubt this is relevant to debian/changelog.
+ * debian/control: change 'Achitecture: all' to 'Architecture:
linux-any' for
+ all binaries.
I think you mean "all binary packages", right?
+ * debian/control: more precise description of the packages, their
purposes
+ and features. Add a statement about the required kernel
version.
I doubt this statement is in debian/control.
Excuse me, I don't understand: do you mean:
- this statement should not be in debian/control
or:
- this statement is missing in debian/control
The first paragraph of the description and the requirement, which are
common to all binary packages, are included with ${Description} and
${Requirement}, defined in debian/substvars. Not good ?
+ * Clean debian/rules.
Without specifics, this is mostly useless noise.
s/an heuristic/a heuristic/
s/an udev/a udev/
normal users
Perhaps "non-priviledged users" instead?
I'm not sure I like the concept of normality involved here.
A initramfs-hook was moved from bilibop-common to bilibop-lockfs.
AFAICT, this is not mentionned in debian/changelog (which is the main
place where changes must be documented, given this is a native
package, and you use no VCS to explain the rationale of each
atomic change.)
Things are progressing! :)
OK, what is the best way, now ?
1. Fix typos and other errors you mention above, modify the existing
changelog entry and keep the version number (0.2) ? In that case,
is it possible to put the 'new' version to mentors.debian.org and
overwrite the previous one ?
2. Fix typos and other things, add a new changelog entry and increment
the version number (0.2.1) ? In that case, how to deal with the
irrelevant or useless informations of the actual changelog ?
3. ?
Thanks for your attention
quidame
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
