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, quidame wrote (20 Jul 2013 10:56:58 GMT) : 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 ? No, unstable should be fine. 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. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85ioy97ye7@boum.org
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,
intrigeri wrote (04 Jul 2013 06:49:08 GMT) :
I plan to review, and hopefully upload bilibop next week.
Here we go.
First, was the target distribution change in debian/changelog
intentional? (0.4.12 has experimental, 0.4.13 has unstable.)
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?
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?
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.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
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/854nbqh0g2@boum.org
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.1 (ITP #675467)
Hi, quid...@poivron.org wrote (16 Jun 2012 00:52:22 GMT) : http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.3.0.dsc Hopefully, I'll review this before the end of the month. Other potential sponsors: if you can be faster than me, please do. So, I don't understand the interest/benefit to build a non-native source package that would be used only on Debian. The only benefit, and the reason why I mentionned this as a possibility, would be to have a way to differentiate, in the version numbers, new releases that only change the packaging, from releases that change things deeper. All this because you seemed to be reluctant to increase the version number for minor changes in debian/control and stuff. But I don't care, really. Both native and non-native would do. Surely it is entirely possible, but I don't think everything possible must be done. Obviously. Cheers! -- 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/85zk81omwv@boum.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)
quid...@poivron.org wrote (08 Jun 2012 22:35:21 GMT) : 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. Well, as you see fit. 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? 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. -- 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/8562b063me@boum.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,
quid...@poivron.org wrote (08 Jun 2012 10:46:14 GMT) :
+ * 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.
[...]
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 ?
Ooops, I missed it, sorry. This comment of mine shall be
ignored, then.
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) ?
I'd rather not see differing code or packaging called the same.
In that case, is it possible to put the 'new' version to
mentors.debian.org and overwrite the previous one ?
No idea.
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 :)
3. ?
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.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
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/85pq9a80gp@boum.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: RFS: bilibop/0.1 (ITP #675467)
Hi, quid...@poivron.org wrote (07 Jun 2012 12:53:34 GMT) : 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. We don't need a versioned dependency, but we need to depend on the *Linux* kernel. 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. Sure. It's a tiny bit sad, but this set of packages is *not* arch:all, given it does not work on kfreebsd-* architectures. So, I'm not sure that it is the best way. Maybe, for bilibop-common, Architecture: linux-any, and for the others, Architecture: all ? This would for sure avoid some stupid duplication, but it would nevertheless create a set of packages that are uninstallable on some architectures, without that fact being made clear to the users of those architectures. So, really, I think the only sane way is to move everything (that is or depends on bilibop-common) to arch:linux-any. 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. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85bokvb7ce@boum.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
Bug#675532: Fwd: Re: Bug#675532: RFS: bilibop/0.1 (ITP #675467)
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. + * 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! :) -- 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/85vcj2a76j@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Hi, bilibop project wrote (02 Jun 2012 00:07:22 GMT) : I am looking for a sponsor for my package bilibop Here is a first, quick review. First of all, this is great work. In case this is your first Debian packaging work, as you seem to indicate in the ITP bug, then congrats! 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? Quotes such as in « disk » are no international symbols, and I've seen English native speakers misinterpret those. 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). Any Vcs-Git / Vcs-Browser field? If you have none ready, I suggest setting up a Git repository in collab-maint on Alioth. 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. Why does bilibop-common's postinst and postrm run update-initramfs? The debian/changelog entry must close the ITP bug. The debian/rules header about Sample debian/rules that uses debhelper should be removed. Why the need to disable override_dh_pysupport by hand? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85aa0hio3c@boum.org
Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package bilibop * Package name: bilibop Version: 0.1 Upstream Author: bilibop project quid...@poivron.org * URL: https://poivron.org/~quidame/bilibop_project/ * License: GPL-3.0+ Section: admin It builds those binary packages: bilibop - run Debian from external media - metapackage bilibop-common - shell functions for bilibop scripts bilibop-lockfs - lock filesystems and write changes into RAM bilibop-rules - udev rules for OS running from external media To access further information about this package, please visit the following URL: http://mentors.debian.net/package/bilibop Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.1.dsc To know more: The bilibop suite is designed to help admins to maintain a Debian OS installed on a removable and writable media. One of its main goals is to fix security issues or harden standard rules and policies, to make the system more robust in this particular situation. bilibop-common functions use proc, sysfs and udev databases to query informations about block devices. The drivemap command shows them in a tree of dependencies. bilibop-rules fixes bug #645466: using the bilibop-common functions, the udev rules file fixes the external disk hosting the running system, and all its partitions, as members of the 'disk' group instead of 'floppy'; dm-crypt, LVM, loop devices and aufs root filesystems (and any combination of them) are supported. bilibop-lockfs can be used as an alternative to the 'fsprotect' package (especially for OS on USB stick), with additional features: - whitelist based configuration: all is protected but the listed fs/mountpoints - not only filesystems are set readonly, but also block devices - swap device management - notifications are send to the user about filesystems status (about temporary or permanent changes) Thanks for your attention quidame -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120602000722.19937.26710.reportbug@xporter
