changes file issue when packaging for backports
Hi, I try to backport bilibop_0.4.22 source package (native). If only changes from 0.4.22 to 0.4.22~bpo70+1 are copied in to the changes file, lintian complains with the 'backports-changes-missing' error tag [1]. If I add -v0.4.21 dpkg-genchanges, the resulting changes file says: Priority: medium [...] Closes: 750507 756086 This overrides the priority of thr bpo package (low, in wheezy-backports); medium is the priority of 0.4.22 in unstable. It claims to close two bugs that are already closed in 0.4.22; more, one of these bugs id specific to jessie/sid, and the bugfix is reverted in the bpo. should I edit the changes file to modify Priority: field and modify or remove Closes: field ? Or replave -v0.4.21 option by something more relevant (shortened changelog entry for 0.4.22) ? Or can I let it go 'as is' ? Cheers, quidame [1] https://lintian.debian.org/tags/backports-changes-missing.html -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/n1r-8jve8c2...@safe-mail.net
Re: changes file issue when packaging for backports
Oops, not Priority: but Urgency: quidame quid...@safe-mail.net wrote: Hi, I try to backport bilibop_0.4.22 source package (native). If only changes from 0.4.22 to 0.4.22~bpo70+1 are copied in to the changes file, lintian complains with the 'backports-changes-missing' error tag [1]. If I add -v0.4.21 dpkg-genchanges, the resulting changes file says: Priority: medium [...] Closes: 750507 756086 This overrides the priority of thr bpo package (low, in wheezy-backports); medium is the priority of 0.4.22 in unstable. It claims to close two bugs that are already closed in 0.4.22; more, one of these bugs id specific to jessie/sid, and the bugfix is reverted in the bpo. should I edit the changes file to modify Priority: field and modify or remove Closes: field ? Or replave -v0.4.21 option by something more relevant (shortened changelog entry for 0.4.22) ? Or can I let it go 'as is' ? Cheers, quidame [1] https://lintian.debian.org/tags/backports-changes-missing.html -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/n1r-8jve8c2...@safe-mail.net -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/n1r-nlwieok...@safe-mail.net
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi,
On 10/09/2013 12:40, intrigeri wrote:
Thanks for all the fixes. I've just reviewed and built 0.4.15 and
hoped to upload right away, but Lintian is still not happy:
W: bilibop-rules: extended-description-contains-empty-paragraph
N:
N:The extended description (the lines after the first line of the
N:Description: field) contains an empty paragraph.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: description, Type: binary, udeb
N:
W: bilibop: extended-description-contains-empty-paragraph
W: bilibop-lockfs: extended-description-contains-empty-paragraph
W: bilibop-common: extended-description-contains-empty-paragraph
W: bilibop-udev: extended-description-contains-empty-paragraph
Looks like some buggy variable substitution.
Oops, you're right.
It is due to a trailing ${Newline} in the Description variable.
It was added to work around a bug [1] affecting dpkg-dev; but this bug
having been fixed recently... the workaround becomes a bug :)
So, fixed:
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.4.16.dsc
Cheers,
quidame
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659814
signature.asc
Description: OpenPGP digital signature
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi,
and thanks for this review
On 19/07/2013 20:25, intrigeri wrote:
First, was the target distribution change in debian/changelog
intentional? (0.4.12 has experimental, 0.4.13 has unstable.)
Yes it is; the target distribution was set to experimental for the
wheezy's freeze duration... after what it was forgotten. Do you think
I should revert to experimental ?
Second, it looks like important changes and refactoring are flowing in
rather quickly, so I'd like to check that you are confident with the
current state of bilibop, and believe it is stable enough to be part
of a Debian release. Do you confirm this?
The most important changes are about debconf support, which has been
added to bilibop-rules. I consider this as an improvement. Maintainer
scripts are idempotent. I have tested bilibop-rules 0.4.13 installation
in several ways: fresh install (with or without preseeding it), upgrade
from 0.4.11, remove, reinstall, purge: all seems to work as expected.
Other things are mainly addition of comments in the shell library,
update of the documentation, and some changes in the code to take into
account some very specific usecases.
So yes, I am confident with the current state of bilibop (but yes, this
was not the case with 0.4.12 - less than one day of lifetime!). Also
note that bilibop is still in active development, and some enhancements
are planned for the next months or even next years; of course, important
attention is given to not break existing things.
Also, please keep in mind that once bilibop is uploaded to Debian, the
responsibility of backward compatibility will be yours, as the
maintainer. This being said, while I certainly wouldn't mind a bit
more abstraction / factorization at some places, the code looks solid
enough :)
Some nitpicking follows, that should be fixed before the initial
upload IMHO:
+myshell=$(awk -F: \$1 ~ /$(whoami)/ {print \$NF} /etc/passwd)
Maybe use `getent' instead?
Fixed.
Also Lintian says:
I: bilibop-common: spelling-error-in-manpage
usr/share/man/man1/drivemap.1.gz informations information
... and a few others, so you probably want to run it in verbose /
pedantic mode and take the results into account.
Mh... I already used '--info --verbose --pedantic' in my script. I
thought it was enough, as mentors.debian.net/package/bilibop says
'Package is lintian clean'.
The tags you mention are catched by '--display-info'. Fixed.
So, here is the new version:
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.4.14.dsc
Cheers
quidame
signature.asc
Description: OpenPGP digital signature
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, On 04/07/2013 08:49, intrigeri wrote: Hi, I plan to review, and hopefully upload bilibop next week. Nice to hear :) The last bilibop version is 0.4.13 [1]. The git repository [2] is ahead of 2 commits (fix minor errors). Thank you quidame [1]: http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.4.13.dsc [2]: http://un.poivron.org/~quidame/git/bilibop.git signature.asc Description: OpenPGP digital signature
Bug#675532: RFS: bilibop/0.3.2 (ITP #675467)
Hi, Le 2012-06-17 19:42, intrigeri a écrit : Hopefully, I'll review this before the end of the month. Other potential sponsors: if you can be faster than me, please do. There is a new version (after tests on freshly installed systems): http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.3.2.dsc Thanks, quidame -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/efec3b7d2dcc079432bc333161496...@poivron.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, Le 2012-06-09 15:01, intrigeri a écrit : quid...@poivron.org wrote (08 Jun 2012 22:35:21 GMT) : I am waiting: - for new comments from you or another DD - to find by myself something to optimize in the code How long do you intend to wait? This was not a question of time. Here is the new version: http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.3.0.dsc Another possibility would be to move to non-native and increment the Debian revision number only. In the present case, we would move from 0.2-1 to 0.2-2, which would reflect the actual changes quite better. For me, this solution, if it is one, implies a lot of issues: For bilibop-common, of course, no problem. With some minor changes, maybe bilibop-rules could be fully portable too. But bilibop-lockfs, in its actual state, is distribution dependent; it depends on initramfs-tools, which is a Debian native source package. If I rewrite bilibop-lockfs to make it more portable (i.e to integrate it in the 'dracut' infrastructure) it will never be installed on Debian, because the default initramdisk builder is initramfs-tools, which conflicts with dracut. But maybe I'm wrong and I have a bad overview on this issue. Maybe bilibop-lockfs could be only a debian patch. Or what ? I think it is entirely possible, even though not perfectly elegant, to turn the package into a non-native one without immediately making the code distro-independent and well separated between the Debian patch and the upstream code. Some tests with other distributions and some investigations in the udev source package have shown that bilibop-rules is distribution dependant too: for example, with CentOS or OpenSUSE, usb drives are owned by the 'disk' group. Bilibop-common is the result of the split of bilibop into bilibop-rules and bilibop-lockfs (because the first one can be used only on removable devices, including LiveUSB; and the second one can be used on any internal or external system except Live). So, I don't understand the interest/benefit to build a non-native source package that would be used only on Debian. Surely it is entirely possible, but I don't think everything possible must be done. Cheers, quidame -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9f984bcbedb01e9a0c2a4b57fcaaf...@poivron.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
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-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50691cc5e4f99ba4db939d9fbde12...@poivron.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, Le 2012-06-08 14:14, intrigeri a écrit : quid...@poivron.org wrote (08 Jun 2012 10:46:14 GMT) : 2. Fix typos and other things, add a new changelog entry and increment the version number (0.2.1) ? Yes. In that case, how to deal with the irrelevant or useless informations of the actual changelog ? Forget it :) OK. But packaging is not a goal in itself, so I think I will not send a new version with just (in the changelog): * Fix typos, unclear sentences and language errors in debian/control, in the documentation and in the comments of the scripts and functions. I am waiting: - for new comments from you or another DD - to find by myself something to optimize in the code Another possibility would be to move to non-native and increment the Debian revision number only. In the present case, we would move from 0.2-1 to 0.2-2, which would reflect the actual changes quite better. For me, this solution, if it is one, implies a lot of issues: For bilibop-common, of course, no problem. With some minor changes, maybe bilibop-rules could be fully portable too. But bilibop-lockfs, in its actual state, is distribution dependent; it depends on initramfs-tools, which is a Debian native source package. If I rewrite bilibop-lockfs to make it more portable (i.e to integrate it in the 'dracut' infrastructure) it will never be installed on Debian, because the default initramdisk builder is initramfs-tools, which conflicts with dracut. But maybe I'm wrong and I have a bad overview on this issue. Maybe bilibop-lockfs could be only a debian patch. Or what ? Cheers, quidame -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/44edc01d09dcf5a80fb8e78e2c676...@poivron.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Le 2012-06-05 20:57, intrigeri a écrit : Here is a first, quick review. Thank you. The whole thing is arch:all, but some shell functions require a Linux kernel shouldn't bilibop-common have a versioned dependency on Linux kernel = 2.6.37 (needed by backing_file_from_loop), and be arch:linux-any instead? I don't know exactly how to do a versioned dependency on the kernel. With a list of alternatives of *generic* (meta or dummy) packages? like: linux-image-486 (= 2.6.37) | linux-image-686 (= 2.6.37) | linux-image-686-bigmem (= 2.6.37) | linux-image-686-pae (= 2.6.37) | linux-image-amd64 (= 2.6.37) ... linux-image-itanium (= 2.6.37) | and so on with 'powerpc', 'sparc64', 'sparc64-smp', plus the 'openvz' and 'vserver' variants, the list is very long... Should I give an exhaustive list of kernels, including all exotic achitectures, some of them being relative to computers having even no USB, FireWire or eSATA ports (but I don't know which), or what? I'm looking for another package that could provide me an usable example of such versioned kernel dependency, but I fail. I've tried with just 'linux-image (= 2.6.37)', but lintian sends a warning: virtual-package-depends-without-real-package-depends. Can I override it (with override_dh_lintian in the rules) ? I think I need help. Additionally, changing 'all' by 'linux-any' leads to the creation of architecture dependent binaries (formally, by their names), but with exactly the same contents: shell scripts, udev rules, manpages and other plain text documents. So, I'm not sure that it is the best way. Maybe, for bilibop-common, Architecture: linux-any, and for the others, Architecture: all ? Do you think a NOTE in the extended description and/or in the README could be sufficient ? (due to the fact that bilibop-* already depend on base-files (= 6.4) and could be available from Wheezy or even later, is there really a chance that it can be installed on systems with a kernel older than 3.0 ?) Quotes such as in « disk » are no international symbols, and I've seen English native speakers misinterpret those. Fixed. You want an URI to a versioned copyright format: Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ (catched by lintian --pedantic). Fixed. Any Vcs-Git / Vcs-Browser field? If you have none ready, I suggest setting up a Git repository in collab-maint on Alioth. I will think about it, later (I have to learn git before). Given the Maintainer is a collective email address, we need at least one human listed in the Uploaders: field (Debian Policy §3.3) -- note that this field has nothing to do with who actually sponsors the uploads; either put yourself, a co-maintainer, or the first sponsor if they are willing to take the responsibility to act as co-maintainers. Fixed. Why does bilibop-common's postinst and postrm run update-initramfs? Ooops... yes, this is an error (remaining files from old version). Fixed. The debian/changelog entry must close the ITP bug. OK The debian/rules header about Sample debian/rules that uses debhelper should be removed. Removed. Why the need to disable override_dh_pysupport by hand? The need ? None. Removed Cheers, quidame -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2c2ad8eafefa26d173ed08224142b...@poivron.org
Bug#675532: Fwd: Re: Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Message original Objet: Re: Bug#675532: RFS: bilibop/0.1 (ITP #675467) Date: 2012-06-08 02:28 De: quid...@poivron.org À: intrigeri intrig...@boum.org Hi, Le 2012-06-07 15:05, intrigeri a écrit : So, really, I think the only sane way is to move everything (that is or depends on bilibop-common) to arch:linux-any. Done. Do you think a NOTE in the extended description and/or in the README could be sufficient ? It would be sufficient to address the minimal Linux kernel version requirement, but certainly not to address the needs Linux one. Done. A new version is available now: http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.2.dsc Cheers, quidame -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/161fee83228883759788aeacc3c49...@poivron.org
