Updating Mawk in Debian
Dear all, any news about updating Mawk with the last upstream version? Regards Yann 2012/5/28 Gert Hulselmans hulselmansg...@gmail.com The Debian version of mawk has a lot of bugs (v1.3.3) http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mawk;dist=unstable Thomas Dickey (other dev than the original mawk dev) has an improved version of mawk (without those bugs): ftp://invisible-island.net/mawk/ but for some reason the debian maintainer doesn't want to update. Thomas Dickey: If the Debian packager were responding, it would be about a week. However, he's ignored most of my bug reports (aside from the one about incorrect license). Look here - I've marked fixed-upstream on the ones that I believe are done... http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mawk https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/400409 I use the fixed version of mawk a lot for my work. If you can force the debian maintainer to update mawk, I would be happy. I tried it a while back, but failed. One of my bug reports at Ubuntu (still not any comment on it): https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/716920 It would be nice to get it bumped by somebody else. - Gert 2012/5/27 yannubu...@gmail.com yannubu...@gmail.com: Hello Gert, Mawk package description says, that Mawk is smaller and much faster than gawk. What about using Mawk instead of Gawk in BIS ? Regards Yann
RFS: boot-repair ( 2nd try )
2012/1/12 Dear mentors, I am looking for a sponsor for my package boot-repair. * Package name: boot-repair Version : 3.04 Upstream Author : Yann Mrn (yannubu...@gmail.com) * URL : https://sourceforge.net/p/boot-repair/home/Home/ * License : GPLv3 Section : admin It builds those binary packages: boot-repair - Graphical tool to repair boot problems boot-sav - Librairies for Clean-Ubiquity, OS-uninstaller Boot-repair boot-sav-gui - Librairies for OS-uninstaller and Boot-repair clean-ubiquity - Make the Ubiquity installer safer os-uninstaller - Operating System Uninstaller To access further information about this package, please visit the following URL: http://mentors.debian.net/package/boot-repair Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/boot-repair/boot-repair_3.04.dsc I took into account all remarks from last reviews: - fixed /usr/share/clean (became /usr/share/boot-sav) - fixed (removed) self-update - fixed X: boot-repair source: python-depends-but-no-python-helper boot-repair... - fixed temporary files created in an insecure way. (now uses mktemp) - fixed the packaging in order to group the 5 binary packages (via .install files) Package is lintian (--pedantic -E -i -I) clean. I would be glad if someone uploaded this package for me. Kind regards, Yann MRN
RFS: boot-repair (v3.04)
Dear mentors, I am looking for a sponsor for my package boot-repair. * Package name: boot-repair Version : 3.04 Upstream Author : Yann Mrn (yannubu...@gmail.com) * URL : https://sourceforge.net/p/boot-repair/home/Home/ * License : GPLv3 Section : admin It builds those binary packages: boot-repair - Graphical tool to repair boot problems boot-sav - Librairies for Clean-Ubiquity, OS-uninstaller Boot-repair boot-sav-gui - Librairies for OS-uninstaller and Boot-repair clean-ubiquity - Make the Ubiquity installer safer os-uninstaller - Operating System Uninstaller To access further information about this package, please visit the following URL: http://mentors.debian.net/package/boot-repair Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/boot-repair/boot-repair_3.04.dsc I took into account all remarks from last reviews: - fixed /usr/share/clean (became /usr/share/boot-sav) - fixed (removed) self-update - fixed X: boot-repair source: python-depends-but-no-python-helper boot-repair... - fixed temporary files created in an insecure way. (now uses mktemp) - fixed the packaging in order to group the 5 binary packages (via .install files) Package is lintian (--pedantic -E -i -I) clean. I would be glad if someone uploaded this package for me. Kind regards, Yann MRN
Re: RFS: boot-repair (v3.03)
Dear mentors, There's also thousands of example packages in the Debian archive that you can look into. As said before i don't know any package using dh_install (if someone knows one, please tell me), and i didn't find any relevant documentation about implementing dh_install. If [dh_install instead of setup.py], and [grouping the 5 packages into 1] are not packaging optimization, but blockers, i will need help. If not here nor in ITP, please indicate where i should ask help for this. why do you bother re-uploading? So that other people who review won't loose time with errors that have already been fixed. Looks logical to me, but if i do something wrong, don't hesitate to tell me. For the moment, my remaining concerns are: 1) i don't understand the X: boot-repair source: python-depends-but-no-python-helper boot-repair 2) i am waiting for Jakub details concerning temporary files created in an insecure way.. Please cancel RFS (review only) until these 2 issues are solved. Best regards
Re: RFS: boot-repair (v3.03)
Thanks Jakub for your review.
I think a single source package with multiple binary packages would make
more sense.
i agree, but until now i didn't find how to do it, so it is same as
dh_install: if really required, i will need someone to do it for me.
What is python-distutils-extra build-dependency for?
removed.
You have empty Suggests, Recommend etc. fields in debian/control. Just
remove them.
XB-Python-Version is deprecated, remove it.
done
Don't use Provides: ${python:Provides} unless you know what you're doing.
removed.
Licence and copyright of glade2script.py is not documented in
debian/copyright.
done.
I also added another one (MIT) in the copyright of boot-repair.
Various scripts create temporary files in an insecure way.
which ones ?
- You should remove *.egg-info from binary packages, they are useless or
this package.
removed.
- This setup.py creates an .installed_file, which you didn't remove in the
clean target.
removed.
With informative and experimental tags enabled, I get:
X: boot-repair source: python-depends-but-no-python-helper boot-repair
X: boot-sav-gui source: python-depends-but-no-python-helper boot-sav-gui
X: boot-sav source: python-depends-but-no-python-helper boot-sav
X: clean-ubiquity source: python-depends-but-no-python-helper
clean-ubiquity
X: os-uninstaller source: python-depends-but-no-python-helper os-uninstaller
i don't understand these ones. help!
E: boot-sav-gui: python-script-but-no-python-**dep usr/share/boot-sav/**
glade2script.py
added python and python-gtk2 dep for boot-sav-gui package.
I updated the packages (same download links). Thanks again, i'm learning a
lot.
Yann
RFS: boot-repair (v3.03)
Dear mentors, I am looking for a sponsor for my package boot-repair. * Package name: boot-repair - Simple tool to repair frequent boot problems Version : 3.03 Upstream Author : Yann Mrn (yannubu...@gmail.com) * URL : https://sourceforge.net/p/boot-repair/home/Home/ https://launchpad.net/boot-repair * License : GPLv3 Section : admin Description: Simple tool to repair frequent boot problems In some situation, you might loose access to one or several of your operating systems, because of a buggy update, a bootloader problem, a broken filesystem, or after installing a new OS (e.g. installing Windows breaks Linux bootloader). . Boot-Repair is a graphical tool that will repair these problems, generally by reinstalling GRUB, which then restores access to the operating systems you had installed before the issue. . Boot-Repair also has advanced options for reinstalling GRUB, adding kernel options, restoring a generic MBR, or repair a broken filesystem. It can also restore the original bootsector if it has been saved previously by Clean-Ubiquity. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/boot-repair http://mentors.debian.net/package/boot-sav-gui http://mentors.debian.net/package/boot-sav http://mentors.debian.net/package/os-uninstaller http://mentors.debian.net/package/clean-ubiquity Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/boot-repair/boot-repair_3.03.dsc dget -x http://mentors.debian.net/debian/pool/main/b/boot-sav-gui/boot-sav-gui_3.03.dsc dget -x http://mentors.debian.net/debian/pool/main/b/boot-sav/boot-sav_3.03.dsc dget -x http://mentors.debian.net/debian/pool/main/o/os-uninstaller/os-uninstaller_3.03.dsc dget -x http://mentors.debian.net/debian/pool/main/c/clean-ubiquity/clean-ubiquity_3.03.dsc I took into account remarks from last reviews: no more /usr/share/clean , no more self-update... Package is built via setup.py . (if dh_install is absolutely required i need someone to implement it for me ) Package is now lintian (--pedantic) clean. I would be glad if someone uploaded this package for me. Kind regards, Yann MRN
Re: RFS: boot-repair
Hello consider writing more interesting information in RFSes, such as what this software actually does. Sorry if i expressed wrong, i just wanted to say to Boot-Repair can be a useful software for Debian. Here is the long description (thanks Thomas for your advice): Description: Graphical tool to repair boot problems In some situation, you might loose access to one or several of your operating systems, because of a buggy update, a bootloader problem, a broken filesystem, or after installing a new OS (e.g. installing Windows breaks Linux bootloader). . Boot-Repair is a graphical tool that will repair these problems, generally by reinstalling GRUB, which then restores access to the operating systems you had installed before the issue. . Boot-Repair also has advanced options for reinstalling GRUB, adding kernel options, restoring a generic MBR, or repair a broken filesystem. It can also restore the original bootsector if it has been saved previously by Clean-Ubiquity. Screenshots: https://sourceforge.net/p/boot-repair/home/Home/ Regards Yann
Re: RFS: boot-repair
Happy new year ! I disabled the update from PPA, removed the setup.py, created the packages.install files, moved data to debian/tmp and changed the rule to %:dh_install --sourcedir=debian/tmp See http://anonscm.debian.org/gitweb/?p=collab-maint/boot-repair.git But now I get this error when i try to package: dpkg-genchanges: error: cannot read files list file: No such file or directory dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 debuild: fatal error at line 1348: dpkg-buildpackage -rfakeroot -D -us -uc failed any idea? Regards
Re: RFS: boot-repair
Currently this is an optional feature: at start-up a window appears asking the user if he wants to update from the PPA . Choice is left to the user (Yes/No buttons). Is this forbidden by Debian policy? if yes, i will deactivate this window. Regards, Yann Yann, I didn't check the Debian policy regarding this issue, but... Just think about it. We already have software in Gnome to let us know when there are updates for any software we use in Debian. Please note that Boot-Repair is a special software: - Boot-Repair is mostly used by users who have just tried installing Linux for the first time - Boot-Repair is often a last-chance tool before the user formats everything, or abandons Linux installation to return to Windows... (e.g. when installing Ubuntu breaks Windows boot, or GRUB menu doesn't appear). - Boot-Repair is mostly used in live-CD (when no access to any OS), and the default Update tools will update all packages, which is useless, very long, and even problematic (kernel updates require reboot). - new boot problems appear frequently (especially new PC with UEFI boots... ), so i think it's important to give the user an easy way to update Boot-Repair (i repeat: update is optional and not silent). I repeat i will deactivate it if needed by Debian Policy, i simply hope you understand why i added this update option. Regards and best wishes for 2012 ! Yann
Re: RFS: boot-repair
2011/12/31 Alessio Treglia ales...@debian.org Hi, On Fri, Dec 30, 2011 at 4:47 PM, yannubu...@gmail.com yannubu...@gmail.com wrote: Reason is that Boot-Repair allows to update its packages and librairies at start-up, but not the packages of Os-Uninstaller and Clean-Ubiquity. Please keep in mind that, as per Debian's policy, no program is allowed to update itself the way you mean! When it needs to update, we'll upload a new revision of the package. Cheers! Hello Alessio, Currently this is an optional feature: at start-up a window appears asking the user if he wants to update from the PPA . Choice is left to the user (Yes/No buttons). Is this forbidden by Debian policy? if yes, i will deactivate this window. Regards, Yann
Re: RFS: boot-repair
Hi Thomas, thanks for your review. Comments below: 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. ok No, we just build your source package with: dpkg-buildpackage -kDebian-Key-ID-for-signing-before-upload Your sponsor will normally never touch your package, he will make YOU change it. ok I really do think it would be a lot more easy to maintain if you had only one source package instead of 5. ok 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. ok. 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). thanks. (yes, all packages are same type) 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). The setup.py files are not from me, they were automatically created by the tool i use for PPA upload (LaunchBash). My knowledge is null about this subject, i can't answer your questions. So feel free to replace the setup.py files by whatever method you feel more appropriate. 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!) ok, i will correct this. 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. ok thanks for the tip. The debian/control following sections are repeated in both the source package section, and in the binary package: priority, section, homepage. i will correct this. In your debian/copyright, please use: Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=174 (or whatever is the last SVN commit in the DEP5 specifications). ok BTW, please also fill the Upstream-Contact: field. ok 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. ok, I can remove this. 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. please see my previous email (answer to Alessio). Also, you are installing your PPA with names matching Ubuntu releases. This has nothing to do in Debian! because all packages are same for all distros (Debian and Debian derivatives) and versions (Lucid packages = Precise packages) . But i agree this can change some day, so I should create a rep for Unstable. There's a lot more issues I'm sure, i hope not too many ;) 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
RFS: boot-repair
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 DebianUbuntu 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 (yannubu...@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 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. Kind regards, Yann MRN
Re: RFS: boot-repair
Thanks Ansgar. Below my answers: Is it really necessary to have five binary package? yes, because: clean is a library used by boot-repair, os-uninstaller and clean-ubiquity. clean-gui is a library used by boot-repair and os-uninstaller At least clean and clean-gui are too generic to me. No problem to rename these packages (into cleanpack and cleanpack-gui for example). The problem is that (i think) I should then use the /usr/share/cleanpack folder instead of /usr/share/clean , which would have these consequences: - it will potentially break OS-Uninstaller and Clean-Ubiquity for all people using both applications at same time (which means several thousands of people using distros including these tools: Hybryde, Ubuntu Secured Remix, OS-Voyager...). Reason is that Boot-Repair allows to update its packages and librairies at start-up, but not the packages of Os-Uninstaller and Clean-Ubiquity. I can workaround this by allowing Boot-Repair to update also Os-Uninstaller and Clean-Ubiquity. - all users who have saved their MBR via Clean-Ubiquity won't be able to restore them simply any more, except if I add a big workaround which scans both /clean and /cleanpack folders - a short path is more convenient - it will require several changes in the code -- potential bugs / big loss of time - i would have to change all documents/posts on forum using this path that's why i would be very happy if i could keep the /usr/share/clean path ... Please do not use Solves bug #636977 but the way documented in policy so that the bug will be closed automatically on upload. Is this ok ? * Initial release. (Closes: #636977) (i thought that was the uploader, not me, who had to modify the changelog before uploading) Regards Yann
