<div class="gmail_quote">On Sun, Aug 30, 2009 at 09:08, Jonas Smedegaard <span dir="ltr"><<a href="mailto:dr@jones.dk" target="_blank">dr@jones.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why do you patch to install into /usr/sbin rather than /usr/bin? Aren't those binaries supposed to be executed by ordinary users?<br>
</blockquote><div><br>rainbow-run and rainbow-easy can only be run as root, thus they are (IMHO) <b>s</b>ystem <b>bin</b>aries. rainbow-xify, mkenvdir, and rainbow-sugarize probably belong in /usr/bin though... I'll fix that shortly.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I notice that you include ${cdbs:Recommends} and similar in debian/control, but still include explicit dependencies as well. The intend of those variables is to move all package dependency handling to debian/rules. See debian/rules of e.g. sugar for an example.<br>
</blockquote><div><br>Okay, I removed the ${cdbs:Recommends}.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why provide a virtul package olpc-security? Do you plan to package other alternative ABI-compatible security mechanisms?<br>
<br>
Similar with nss-rainbow - why provide such virtual package?<br></blockquote><div><br>Both removed.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Short descriptions should avoid leading "a" or "the", I believe.<br>
<br>
Long descriptions says "on the OLPC" which is incorrect, I believe: OLPC is an organization - I suspect that you mean "on the XO laptops by OLPC" or something similar.<br>
</blockquote><div><br>Fixed. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Where is the "upstream" branch holding the virgin upstrema code? Did you not use git-import-orig to bootstrap the packaging? "pristine-tar" branch is missing too. Please use both --pristine-tar and --sign-tags options to inject upstream tarballs.
</blockquote><div><br>No idea. I used "git-import-dsc" per the <a href="http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/" target="_blank">http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/</a> , which seemed an authoritative guide. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Here's how I usually start a new packaging:<br>
<br>
wget http/<a href="http://example.org/pkgname-1.2.tgz" target="_blank">example.org/pkgname-1.2.tgz</a><br>
mv pkgname-1.2.tgz pkgname_1.2.orig.tar.gz<br>
mkdir pkgname<br>
cd pkgname<br>
git init<br>
git-import-orig --sign-tags --pristine-tar ../pkgname_1.2.orig.tar.gz<br>
<br>
You can either start from scratch again (and please do apply each change as a separate commit to help tracking what is what), or I can try merge a virgin proper bootstrap with your branch. Tell me how you want us to deal with it.<br>
</blockquote><div><br>Can you do it? I tried and can't seem to do so "properly".<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Long decription of the NSS module includes its licensing - I find that irrelevant there.<br>
</blockquote><div><br>Fixed.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why do you include the version number of the NSS module? I suspect only shared libraries should include a trailing major version, and that NSS modules are not normal shared libraries. Again, compare with other NSS modules for how they do things (without duplicating blindly - e.g. we use CDBS while some of them might use incompatible debhelper 7 "dh").<br>
</blockquote><div> <br>At least two NSS modules include trailing version numbers. Lintian was tossing a warning unless I did so. If you'd rather, I can drop it and silence Lintian.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why do you install /var - that looks odd to me.<br>
</blockquote><div><br>That directory is required by Rainbow, as that is where isolated instances will be located. Rainbow will not work without this directory. Should I create it in the postinst?<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Are you sure you should install /usr/lib/python*? - I suspect that is taken care of by the <a href="http://python-distutils.mk" target="_blank">python-distutils.mk</a> snippet, and installing directly actually violates Python policy!<br>
</blockquote><div><br>If you look at the build .debs, there shouldn't be anything in /usr/lib/python, but that snippit was required for me to get the right code in the right place. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why do you set DEB_MAKE_MAKEFILE?</blockquote><div><br>Hm? I don't see that anywhere in my debian/rules file. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why set DEB_PYTHON_MODULE_PACKAGES - I believe that should be autodetected if using proper package names. Even if not, I still suspect that you should rename the package to include a leading "python-" to not violate Python Policy.<br>
</blockquote><div><br>How about this: I'll split it off into three packages: rainbow, python-rainbow, and libnss-rainbow2. <br><br>python-* packages shouldn't install anything into /usr/sbin/ or /usr/bin as far as I can tell, so just renaming rainbow to python-rainbow would not be acceptable.<br>
<br>If that's acceptable to you, I'll make the changes. As it is, I think we're fine with just rainbow and libnss-rainbow.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I dislike you claiming authorship of the manpages, when in fact autogenerated using help2man. I recommend stripping that sentence from debian/help2man.<br>
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I suggest renaming debian/help2man to either debian/help2man.include or debian/help2man.addon. to clarify its purpose.<br></blockquote><div><br>Both done.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I suggest renaming *.md to *.mdwn (the extension used by e.g. Ikiwiki for Markdown files - I am not entirely sure that there is consensus about that extension, though).<br></blockquote><div><br>There isn't much consensus, and pandoc uses .md in their examples.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Did you write those Markdown files from scratch yourself, or did you bootstrap from data pulled from e.g. some web pages? If so, it might make sense to setup a target in debian/rules to regenerate using newer upstream web sources. Such target should not be used in normal builds (that's illegal!) but can be used by us to check once in a while if there are updated documentation.<br>
</blockquote><div><br>I wrote them myself. I'm talking with Michael Stone to get those integrated upstream.<br></div><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I suggest dropping the patch to clean egg file, and instead do that in clean:: of debian/rules: We want to limit patching to the least possible.<br></blockquote><div><br>Done. <br></div><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Why not use the patch naming policy that I suggested in previous mail?<br></blockquote><div> </div></div>Also implemented.<br clear="all"><br>Thanks,<br>Luke Faraone<br><a href="http://luke.faraone.cc" target="_blank">http://luke.faraone.cc</a><br>
<div style="border-style: solid; border-color: rgb(60, 143, 167); border-width: 1px 1.5px 1px 0.5px; padding: 1pt 3pt; background-color: white; font-size: 10pt; color: rgb(0, 0, 0);">
</div>
<div style="border-style: solid; border-color: rgb(60, 143, 167); border-width: 1px 1.5px 1px 0.5px; padding: 1pt 3pt; background-color: white; font-size: 10pt; color: rgb(0, 0, 0);">
</div>