Re: RFS: boot-repair
On 12/30/2011 06:14 PM, yannubuntu@gmail.com wrote:
> Dear mentors,
>
> I am new here.
> I am looking for help to upload my package "boot-repair" and its
> librairies. (total of 5 binary packages)
>
> It has already been used by thousands of Debian&Ubuntu users for
> ~2years via my PPA,
> and i read that Canonical plans to integrate it into Ubuntu 12.04 CD
> (i think deadline is mid-January).
>
>
> * Package name : boot-repair
> Version : 3.02
> Upstream Author : Yann Mrn (yannubuntu@gmail.com
> <mailto:yannubuntu@gmail.com>)
> * URL : https://launchpad.net/boot-repair
> * License : GPLv3
> Section : admin
>
> Quick solution: upload these 5 packages separately (Lintian clean):
> http://mentors.debian.net/package/boot-repair
> http://mentors.debian.net/package/clean
> http://mentors.debian.net/package/clean-gui
> http://mentors.debian.net/package/clean-ubiquity
> http://mentors.debian.net/package/os-uninstaller
Hi,
It's ok to give the link to your mentors.debian.net page, but next time,
please as well provide direct links to your .dsc files.
On 12/30/2011 11:47 PM, yannubuntu@gmail.com wrote:
> (i thought that was the uploader, not me, who had to modify the
> changelog before uploading)
No, we just build your source package with:
dpkg-buildpackage -k<Debian-Key-ID-for-signing-before-upload>
Your sponsor will normally never touch your package, he will make YOU
change it.
> Alternative: group them into 1 package, by making the "boot-repair"
> package build the 5 binary packages.
> Alessio kindly suggested a method (
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636977 ), but i don't
> know
> how to do it, so any further help would be much appreciated.
I really do think it would be a lot more easy to maintain if you had
only one source package instead of 5. I personally don't really mind
if you are using "/usr/share/clean" (others may differ here, up to
them to voice their concern and explain why), but I really don't
think it's needed to ship "clean" as a standalone package.
I also see absolutely no reason why using a complicated python
setup thing for your "clean" package, when really, the only thing
you are packaging is a bash script. That's overly complicated,
when the only thing you need is a debian/install file.
Let me do a quick review of boot-repair (I didn't check all packages,
but it seems this applies to all of them as well).
Please follow the guidelines available here for your python things:
http://wiki.debian.org/Python/TransitionToDHPython2
Since your package is using a setup.py, shouldn't you build-depends
on python-setuptools Or ispython-distutils-extra enough? To me, you
should also do: --with python2 in your debian/rules. Have you tried
using a pbuilder, or to build in a new chroot? Does it work?
When building, I got a bunch of the below output, and this for all
dh_helper called by the dh 8 sequencer:
Unknown option: buildsystem
So your thing here doesn't work:
export DH_OPTIONS=--buildsystem=python_distutils
please use the normal --with python2
but in all your packages, I think it's weird. You just have few
bash scripts, and never (right?) python stuff. However, you do use
python for installing your bash scripts. Why do you do this? It
especially doesn't make sense since your packages are all native
(so the: "I'm using python setup tools so that it can be installed
on any platforms" argument doesn't make sense, or you should
be using a non-native format).
If debian packaging == upstream author, you don't need to specify
Files: * then later Files: debian/*, just one entry for both would be
enough here. (if other differ, please voice your opinion here!)
Starting from here, these are stuff found by Lintian which you should
have been able to fix by yourself. Next time, before uploading, please
run lintian with the options: "-Ii -E --pedantic", so that you can fix it.
The debian/control following sections are repeated in both the
source package section, and in the binary package: priority, section,
homepage.
In your debian/copyright, please use:
Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=174
(or whatever is the last SVN commit in the DEP5 specifications).
BTW, please also fill the "Upstream-Contact:" field.
That was for the packaging only of boot-repair. Now few remarks
on your "boot-repair" script.
Your script does:
if [[ "$1" = "--dev" ]];then
touch /tmp/clean_dev
elif [[ "$1" = "--debug" ]];then
touch /tmp/clean_debug
fi
Don't do this, this would be a security issue (symlink attack is possible)
if you have predictable file names in /tmp. Please use mktemp.
Your software is manipulating /etc/apt/sources.list, and then using
apt-get install. If your software is in Debian, why would we need you
to install your PPA source list in /etc/apt/sources.list? This is
unacceptable
for Debian. Also, you are installing your PPA with names matching
Ubuntu releases. This has nothing to do in Debian!
There's a lot more issues I'm sure, like the long description of
clean-ubiquity (why do you split each line as if it was paragraphs?). As
a general remark, your long descriptions aren't good enough, by reading
them I don't understand what your software is doing. They should use
better wording. Let me give an example:
Package: boot-repair
Description: Simple tool to repair frequent boot problems
In some situation, you might do <explain-what> and then you may
run into <explain-what-problem>. Boot-Repair is a graphical tool
which will repair these problems by <explain what it does>, which
then restores access to the operating systems you had installed
before the issue.
.
Also, boot-repair has advanced options for reinstalling GRUB,
restoring an MBR restore, or repair a broken filesystem. I can also
restore the original bootsector if it has been saved previously by
clean-ubiquity.
When writing long descriptions, imagine that you are the reader,
and that you are discovering something new. The long description
should be enough to give you a rough idea why you may use the
described software.
I hope this helps. Please fix the above in all packages, then come back
to ask on the debian-mentors list.
Happy new year,
Thomas Goirand
Reply to: