aragorn (Was: Python package review)
Hi Sascha, I'm a bit in a hurry so I pick the easier part of your mail first and come back later to Genometools. On Sun, Feb 10, 2013 at 09:43:01PM +0100, Sascha Steinbiss wrote: > > P.S. On a side note, I am also preparing a package for a GPL2 program > called aragorn (not ITP'ed yet). Since this is my first package of > which I am not the upstream author, I wonder if it's good style to > contact him and ask whether he still maintains the source? The date on > the web site indicates he does. In general it is considered nice to contact the author and I would recommend doing so. I would also recommend the author to apply the two patches you created for the package. I guess he will be happy about this enhancement. It could make sense to recommend bundling the single source file into a compressed tarball - possibly by some added value of some documentation file. This would safe you the extra get-orig-source target. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130211095254.ga15...@an3as.eu
Re: aragorn (Was: Python package review)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2013 10:52 AM, Andreas Tille wrote: > Hi Sascha, Hi Andreas, > I'm a bit in a hurry so I pick the easier part of your mail first > and come back later to Genometools. Thanks! Remember, it's only the Python part -- I'm confortable with the rest. [...] >> P.S. On a side note, I am also preparing a package for a GPL2 >> program called aragorn (not ITP'ed yet). Since this is my first >> package of which I am not the upstream author, I wonder if it's >> good style to contact him and ask whether he still maintains the >> source? The date on the web site indicates he does. > In general it is considered nice to contact the author and I would > recommend doing so. I would also recommend the author to apply the > two patches you created for the package. I guess he will be happy > about this enhancement. It could make sense to recommend bundling > the single source file into a compressed tarball - possibly by some > added value of some documentation file. This would safe you the > extra get-orig-source target. Okay, thank you. I will write up an email right now. > Kind regards Andreas. Best regards, Sascha - -- Sascha Steinbiss Center for Bioinformatics University of Hamburg Bundesstr. 43 20146 Hamburg Germany Email: steinb...@zbh.uni-hamburg.de URL:http://www.zbh.uni-hamburg.de/steinbiss Phone: +49 (40) 42838 7322 FAX:+49 (40) 42838 7312 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEYyMsACgkQvCCdOseRus/sPACgptxP4HdXGXIAnCg52j7qFNBt U+sAoJsqAeN4xh0WfQfNyozKvMsyUJ4Y =LgC4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5118c8cb.3040...@zbh.uni-hamburg.de
Re: Python package review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 2/10/13 9:43 PM, Sascha Steinbiss a ?crit : > Hi everyone, > > could someone with some expertise in Python module packaging have a > quick look at the 'genometools' rules file and maintainer scripts -- I > have just packaged the Python bindings and while I *think* I have > followed chapter 2 of the Debian Python Policy, there may be other > issues I missed that will certainly catch the eye of an experienced > Python packager. I had a quick look at package. You manually do install steps etc... dh helper manage python. On a pure python package, all I had to do is: dh $@ --with python2 You should not need the .install files (to copy your python fileds) nor the setup.py install in your rules file. Maybe that a simple: override_dh_auto_install: ... dh_auto_install --sourcedirectory=gtpython could be enough. Additionally Python Policy states: http://wiki.debian.org/Python/Policy / Updating your packages / 5. If your package provides modules (either public or privates), you should use python-support or python-central to bytecompile them at installation time. Choose one of them and follow the specific instructions below. You does the byte compilation yourself in postinst/prerm, but I think it would be better to use provided tools. Olivier > > Thanks a lot in advance, > Sascha > > P.S. On a side note, I am also preparing a package for a GPL2 program > called aragorn (not ITP'ed yet). Since this is my first package of > which I am not the upstream author, I wonder if it's good style to > contact him and ask whether he still maintains the source? The date on > the web site indicates he does. > > > - -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRGQHOAAoJEHjcaNsybYQ4uH8P/jvXN5sFJBTtgx9BnIsGWMwp VFyOJeTZvXsXLuoayeO/HmjsrS8aHiCG8qUaD538o2gHnxzrz7f26W/yHV2aB4kE QJ/HtQZAtW1SMWHgqHRgWcNSeqkJ14kLu2LS3g+E/lZTZ/vPsbn0GayG3ZYiaaDA q1NR5agOLHirJcVwFiVdbWBFztdxYfZn6UdVgr8Vq1FzfQeSTnPe5sMN7+3jlmcr +jevdM22P+gLFmI5jbY038eRTqZYMEM6M8uOHnxI71VUcyCHraFF9VqFvQrECiuS y9vutu8hbcwEHURE1znO0DoGGYBjhsqWngmfsk6s6gSxru8bdjHTCpsFs6VZ09uG lKQytw/wGaZbCMfsA/QvOFHizUI4f2/p28ZGodOFAZZ2mKfH8Ukxqmx2+gTAnfGx dmAQT9X+Ld91zxbxA2y81g7D5RdTDlhDA1BE/vh3xa1LtGd89vLBfUHPhhiXOKY9 uXUm4dd0KLz5rUSHxOfCw+6cDL+CGtvFgHxkCOjlUw4lQGUz6mKfjaZFQ+6hTJkE 8iY9CWyOERL6uCnLzjIrdoxBxEw6EODR8d9HFuWzSmXjCmqUYUE8YlKPPZLyu9Gl +Sy9eq64y8yTOSa61rF5CYWwwyYG+NcOkFKeDurLZhFXC7Tk88DyZhX1UGNB5G/k 90AiygKQ2xTU6iiIQNPI =55QZ -END PGP SIGNATURE-
Re: [MoM] Debian Med MoM for February
Hi Sukhbir, Does a French/Deutsch translation exist ? If so where can I find them ? >>$ lintian hunspell-en-med_1-1_amd64.changes Eric, freemedforms.com -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/026a1988-e98b-4a4e-8c8b-32e3edf4f...@gmail.com
Re: [fis-gtm] builds with pbuilder
On 02/08/2013 01:41 PM, Yaroslav Halchenko wrote: On Fri, 08 Feb 2013, Amul Shah wrote: - The next GT.M release will eliminate the dpkg-shlibdeps warnings (Yaroslav suggested - -Wl,--as-needed) well -- you would need to verify that with this your build still functions properly and has all needed bindings (e.g. if plugin relies on some library to be loaded by the main process, but main process doesn't use those symbols -- it would have undesired effects) if you find that those are needed -- then better to live with the warnings ;) [amul:4] I meant to say "should eliminate" and not "will eliminate." :) The plan is to try both your suggestion and do my homework to learn which binaries require what libraries. I don't like warnings. While I'm typing up the explanation, can we get the changes tested on a Debian build server? pbuilder environment would be your 'Debian build server'. but you might like to create at least two -- amd64 and i386 (--architecture arg) on your 64bit box -- to verify build in both 32 and 64 bit mode [amul:4] pbuilder starter amd64 and i386 builds work on my machine (Debian 6 amd64). I can see day light! :) thanks, Amul _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51191c5b.9030...@fisglobal.com
Re: [MoM] Debian Med MoM for February
Hi Eric, Eric Maeker wrote: > Does a French/Deutsch translation exist ? If so where can I find them ? I am not sure about the French translation (I don't think it has been packaged yet), but the package for the Deutsch one is at: http://packages.debian.org/squeeze/hunspell-de-med -- Sukhbir -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130211163014.gb2...@gmail.com
Re: [fis-gtm] builds with pbuilder
Hi Andreas, On 02/08/2013 02:00 PM, Andreas Tille wrote: Andreas asked if we should use GIT. Yes please. How do I/we do that? I remember Charles has given a hint to a script which does the job. > From my *personal* perspective it is fine to forget about the history and just create a fresh Git repository as described in Debian Med policy document. I could imagine that V6.0-002 release might be a good starting point (if it is expected in the not so distant future) because you save the trouble with the dirty tarball and can straight import from upstream. But finally it is your choice to do it right now. [amul:5] For GIT conversion, I found the following links. I'll give them a try once we're ready to release the V6.0-001 package/ http://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git http://lists.debian.org/debian-med/2009/11/msg6.html [amul:5] Let's not wait for V6.0-002. I have a strong feeling that we will need some deployment changes to the package that we won't find in my simple tests. And by strong feeling, I mean that I've been burned often enough by small deployment problems What remains: - I need a DEP3 compliant explanation of the suppression of the gtmsechr setuid and permissions. [amul:5] Where should I put the explanation for the suppression options? [amul:5] How is the following for a DEP3 compliant explanation? --- Author: Amul Shah Description: FIS GT.M uses a setuid binary to facilitate multi-user access to database shared memory [description adapted from the Admin and Operations Guide] FIS GT.M (hereby referred to as just GT.M) processes run with normal UNIX user and group ids. GT.M has no database daemon that needs to run with elevated privileges. Process code written in M will be able to read a database file if and only if the process has read permission for that database file, and to update that database file if and only if the process has read/write permission for that database file. Processes with normal user and group ids do not have adequate permissions to effect necessary GT.M interprocess communication and cleanup after abnormal process termination. A process called gtmsecshr runs as root in order to effect the following functionality: - Interprocess communication, including sending SIGALARM and SIGCONT between processes where normal UNIX permissions do not permit such signals to be sent. - Cleanup after processes that terminate abnormally, including removing semaphores, shared memory segments, and flushing database file headers (but not database blocks) from shared memory segments to disk. Whenever a GT.M process lacks adequate permissions to effect any of the above operations, it automatically invokes gtmsecshr if it is not already running. In order to run as root, and to be invoked by a process that has normal user and group ids, the invocation chain for |gtmsecshr| requires an executable image that is owned by root and which has the |setuid| bit turned on in its file permissions. There are two images named gtmsecshr, one located in /usr/lib/fis-gtm/_/gtmsecshr and /usr/lib/fis-gtm/_/gtmsecshrdir/gtmsecshr. /usr/lib/fis-gtm/_/gtmsecshr exists to sanitize the UNIX environment and to validate that the permissions on /usr/lib/fis-gtm/_/gtmsecshrdir and /usr/lib/fis-gtm/_/gtmsecshrdir/gtmsecshr match its expectations. The permissions expectations for each path are listed in octal notation: 4755 /usr/lib/fis-gtm/_/gtmsecshr 0500 /usr/lib/fis-gtm/_/gtmsecshrdir 4500 /usr/lib/fis-gtm/_/gtmsecshrdir/gtmsecshr --- Thanks, Amul _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Re: Python package review
Hi, On Mon, Feb 11, 2013 at 03:35:59PM +0100, Olivier Sallou wrote: > I had a quick look at package. You manually do install steps etc... > dh helper manage python. On a pure python package, all I had to do is: > dh $@ --with python2 I was today traveling offline and came to the very same conclusion to use this line (also commited and removed the postinst / prerm). This works better because it simply implements what is written down in Python policy. > You should not need the .install files (to copy your python fileds) nor > the setup.py install in your rules file. > > Maybe that a simple: > > > override_dh_auto_install: > ... > dh_auto_install --sourcedirectory=gtpython > > could be enough. This might be even more simple than my solution that has the install file remaining. > http://wiki.debian.org/Python/Policy / Updating your packages / > 5. If your package provides modules (either public or privates), you > should use python-support or python-central to bytecompile them at > installation time. Choose one of them and follow the specific > instructions below. "--with python2" is using python-support (python-central is deprecated) > You does the byte compilation yourself in postinst/prerm, but I think it > would be better to use provided tools. +1 (or should I say +2?) BTW, I also checked the package in general and made it priority optional with exception of the -dbg package. Debian Med policy recommends this priority because it ensures that all QA tools will work on this package while priority extra might hide the package from some checking tools. I also extended the clean target to enable building the package twice in a row. Most probably you should grab your upstream hat and fix upstream Makefiles to enable easier cleaning up after building. Hope this helps Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130211190259.ga28...@an3as.eu
Re: Python package review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2013 08:02 PM, Andreas Tille wrote: > Hi, Hi Andreas and Olivier, > On Mon, Feb 11, 2013 at 03:35:59PM +0100, Olivier Sallou wrote: >> I had a quick look at package. You manually do install steps >> etc... dh helper manage python. On a pure python package, all I >> had to do is: dh $@ --with python2 > I was today traveling offline and came to the very same conclusion > to use this line (also commited and removed the postinst / prerm). > This works better because it simply implements what is written > down in Python policy. I'm putting the debhelper documentation/man on my reading list right now! >> You should not need the .install files (to copy your python >> fileds) nor the setup.py install in your rules file. >> >> Maybe that a simple: override_dh_auto_install: ... >> dh_auto_install --sourcedirectory=gtpython >> >> could be enough. > This might be even more simple than my solution that has the > install file remaining. Okay, thank you. I will definitely try that. Actually, I tried something similar before, but as I left out the `--sourcedirectory' it did not work, and I fell back to doing everything manually. >> http://wiki.debian.org/Python/Policy / Updating your packages / >> 5. If your package provides modules (either public or privates), >> you should use python-support or python-central to bytecompile >> them at installation time. Choose one of them and follow the >> specific instructions below. > "--with python2" is using python-support (python-central is > deprecated) >> You does the byte compilation yourself in postinst/prerm, but I >> think it would be better to use provided tools. > +1 (or should I say +2?) So the '--with python2' flag in the debhelper catchall target is enough to make sure the byte compilation takes place, and the compiled objects are removed at deinstallation? Wow -- I cannot stop being amazed by the magic ;) > BTW, I also checked the package in general and made it priority > optional with exception of the -dbg package. Debian Med policy > recommends this priority because it ensures that all QA tools will > work on this package while priority extra might hide the package > from some checking tools. I see. Thanks for the modification. > I also extended the clean target to enable building the package > twice in a row. Most probably you should grab your upstream hat > and fix upstream Makefiles to enable easier cleaning up after > building. Yes, I found that out too the hard way, hacking away ;) This will definitely be fixed and make its way into the next release. > Hope this helps Andreas. It definitely does! Thanks again for your time! Sascha - -- Sascha Steinbiss Center for Bioinformatics University of Hamburg Bundesstr. 43 20146 Hamburg Germany Email: steinb...@zbh.uni-hamburg.de URL:http://www.zbh.uni-hamburg.de/steinbiss Phone: +49 (40) 42838 7322 FAX:+49 (40) 42838 7312 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEZRo0ACgkQvCCdOseRus9LeQCfRjLaLm4Dmn7/YQjQaz9LUElk CWEAni5t982o969MV9eM3326KaoIa/kF =I3Ax -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5119468d.3000...@zbh.uni-hamburg.de
Re: Python package review
On Mon, Feb 11, 2013 at 08:29:17PM +0100, Sascha Steinbiss wrote: > I'm putting the debhelper documentation/man on my reading list right now! Either this - or just checking other packages. :-) > So the '--with python2' flag in the debhelper catchall target is > enough to make sure the byte compilation takes place, and the compiled > objects are removed at deinstallation? Wow -- I cannot stop being > amazed by the magic ;) :-) I admit you are ot alone in beeing amazed - I guess most of us are when we notice this kind of magic. > > Hope this helps Andreas. > > It definitely does! Thanks again for your time! Well, it was boring traveling time anyway. See you in Kiel Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130211205009.gb28...@an3as.eu
Re: [fis-gtm] builds with pbuilder
Hi Amul, On Mon, Feb 11, 2013 at 12:32:44PM -0500, Amul Shah wrote: > >the trouble with the dirty tarball and can straight import from upstream. > >But finally it is your choice to do it right now. > > [amul:5] For GIT conversion, I found the following links. I'll give them a > try once we're ready to release the V6.0-001 package/ > http://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git > http://lists.debian.org/debian-med/2009/11/msg6.html This is the link I had in mind. > [amul:5] Let's not wait for V6.0-002. I have a strong feeling that > we will need some deployment changes to the package that we won't > find in my simple tests. And by strong feeling, I mean that I've > been burned often enough by small deployment problems For sure you decide here. Just go on and let us know here if you need help. As I said before: If it turns out to be a problem I personally would not consider the full history as a very important thing to keep. > >>What remains: > >>- I need a DEP3 compliant explanation of the suppression of the gtmsechr > >>setuid and permissions. > > [amul:5] Where should I put the explanation for the suppression options? > > [amul:5] How is the following for a DEP3 compliant explanation? > > --- > > Author: Amul Shah > Description: FIS GT.M uses a setuid binary to facilitate multi-user access to > database shared memory That's fine and belongs strait at the head of the patch file. (Just have a look into patch files of other packages to see how it is used.) > FIS GT.M (hereby referred to as just GT.M) processes run with normal > UNIX user and group ids. GT.M has no database daemon that needs to > ... That's way to much for the patch description. About one paragraph is completely sufficient. Finally it is a developer oriented information - if more details might be needed there is a plenty of information out there. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130211210333.gc28...@an3as.eu
