Re: hmmer (3.0, sid)
On 08/29/2010 03:55 PM, Eric Talevich wrote: > On Fri, Aug 27, 2010 at 7:02 AM, Steffen Möller wrote: > >> On 08/27/2010 08:12 AM, Andreas Tille wrote: On Thu, 26 Aug 2010, Felipe Figueiredo wrote: > I just noted that binaries in hmmer 3.0-1 are located in /bin instead > of /usr/bin. Is this a bug? >>> Definitely. I have fixed this in SVN. Eric, I also commited your >>> upload to SVN (please do so as well in future uploads). You might >>> either upload the fixed version yourself in case you would like to do >>> other changes (there is one remaining lintian warning about a formatting >>> error in a manpage) or just ping me to do the upload. >> Ups, I should have spotted that in our initial packaging. The >> sources should have been in the svn repository for long, I possibly >> just never ran the svn commit on them. So, thanks for fixing all that. >> >> Eric, I'll address that all tonight while bringing my laptop back in sync >> with the repo. >> > > Thanks, Steffen. Sorry for my absence here. Hi Eric, there is nothing you could have done about it. Andreas has already fixed it, and I could just recompile and upload. > Another thought -- HMMer 3 depends on a library and set of binaries called > Easel the same way HMMer 2 depended on Squid/biosquid. At least one of the > binaries is generally useful, esl-reformat. Should we extract Easel into a > separate package at some point? This sounds very reasonable. However, I must admit that I do have observed any larger group of followers behind biosquid and don't expect more from Easel, unless we can persuade upstream to keep the easels from infernal and hmmer synced and compatible. Best, Steffen -- 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/4c7adf6c.8020...@gmx.de
Re: Connecting those interested in getting GT.M into the Debian repositories
Hi Andreas, To explain further about the directory permission thing, when I built the Debian package, I started by running GT.M's 'config' script, installing GT.M into the directory /usr/lib/fis-gtm/V5.4-000A_x86. I answered the installation questions as follows: File owner: bin Execution of GT.M restricted: no Unicode support: yes ICU version: 4.2 Lower case versions of MUMPS routines: no The config script sets up the the following directories with 'r-xr-xr-x' (i.e. not writable) permissions: - V5.4-000A_x86 - V5.4-000A_x86/utf8 - V5.4-000A_x86/plugin - V5.4-000A_x86/plugin/gtmcrypt - V5.4-000A_x86/plugin/gtmcrypt/utf8 Additionally, some of these directories contain symbolic links. If I build the Debian package and maintain the non-writable permissions on the directories, when someone wishes to extract the package (dpkg -x) without root privileges, they get errors because the directories do not have write permission. So what I did was change the permissions on these directories to rwxr-xr-x in the Debian package. When the actual install occurs, the 'postinst' script does a chmod to put the permissions on these directories back to r-xr-xr-x. I took this step because Bhaskar had requested that the package be extractable without root privileges. You mentioned that I should not rely on the user ID of any user. I was concerned about that too, which is why I placed the two following commands at the end of the postinst script: chown -R --from=0:2 root:$owner "$version" chown -R --from=2:2 $owner:$owner "$version" On my system, the value of '2' is assigned to user bin and the value of '0' is assigned to root. (I suspect root is always assigned the value of zero, but just in case... :) This way, I ensure that the ownership is correct, regardless of the value assigned by a particular system. Regarding 'svn://svn.debian.org/svn/debian-med/trunk/packages/gtm/trunk' and the GT.M scripts that I referenced, I wasn't trying to get into too much detail about them right now. (I wouldn't mind doing it, but I didn't want to muddy the waters.) I was just wondering whether everyone was okay with the idea of using update-alternatives to link the Fidelity supplied script of '/usr/lib/fis-gtm/V5.4-000A_x86/gtm' to the name 'gtm-su' (instead of simply 'gtm'). My thought is that since the Fidelity supplied script named 'gtm' uses a database that is in the user's home directory, it's more similar to a single-user version of GT.M (i.e., if the system is setup so different users cannot access each others home directory, then effectively GT.M becomes single user). So I thought it might be good to rename that script, so to speak, as "gtm-su" (single user) and then later publish a script called "gtm" that allows users to enter a specific GT.M environment that is accessible to multiple users. I definitely agree that it's tough with just the postinst script. I'd be happy to share more, but I need some help on that front. Specifically, I'm wondering what is the preferred method for sharing the other details. I'm thinking -- perhaps incorrectly -- that it would not be the best approach to upload the whole package to the Debian Med list. (Sorry, I have to admit that I've not used list serves much in the past.) If you could give me an idea on the best way to share the details of the package, it would be great. :) Thanks much for your thoughtful response. I look forward to hearing from you again soon. Alan -- 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/4c7ad33e.5080...@cavtel.net
Re: Connecting those interested in getting GT.M into theDebianrepositories
On Sat, Aug 28, 2010 at 06:49:51PM -0400, Alan O'Neill wrote: > I now have a draft version of a Debian installation package for the > 32-bit version of GT.M that I'd like to submit for your feedback. Once > we get any problems ironed out, I'll simply pattern the 64-bit version > after it. In the mean time, I thought I'd save myself the double work. Great that you work on this! > The package contains the result of running the GT.M 'config' script to > install GT.M in '/usr/lib/fis-gtm/V5.4-000A_x86' with a twist. To allow > someone to use 'dpkg -x' without root privileges, I changed the > permissions on the directories that initially had 555 to 755. The > 'postinst' script resets these directories to 555. Can you please elaborate on this in more detail? > Although the package contains the .o versions of the MUMPS routines, the > 'postinst' script recompiles them all. > > I don't know whether the internal number for the 'bin' user is > guaranteed to be '2' on all systems, so the 'postinst' script changes > ownership of the installed files to root:bin or bin:bin, whichever is > appropriate. You probably should not rely on a user id of any user (and so you should not in the case of bin). In how far you need to use this user id. > The 'postinst' script uses update-alternatives to setup 'gtm-su' > (single-user). My hope is that we can keep this name (or something > similar) because I've also been working on a set of scripts, one of > which is named 'gtm'. These scripts help to configure a GT.M multi-user > environment, enter it, etc. Once the GT.M package is out there, I'd be > interested in sharing these scripts. So why not just commiting all the packaging scripts to svn://svn.debian.org/svn/debian-med/trunk/packages/gtm/trunk as I suggested to use the Debian Med packaging repository. That way we are able to verify the packaging and give some hints. I admit I do not understand any part of your reasoning above. > Since I'm not certain precisely how to proceed from here, I'll include > the postinst script below and ask for the group's feedback on what to do > next. It is a bit hard to only see the postinst. > Also, I've added my public e-mail address of 'alan.one...@cavtel.net' to > the Debian Med list, so please feel free to remove my private e-mail > address that you've been using when you respond. (I keep these things > separate because of spam.) Fine. 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/20100829202813.ga3...@an3as.eu
Re: hmmer (3.0, sid)
On Fri, Aug 27, 2010 at 7:02 AM, Steffen Möller wrote: > On 08/27/2010 08:12 AM, Andreas Tille wrote: > >> On Thu, 26 Aug 2010, Felipe Figueiredo wrote: > >>> I just noted that binaries in hmmer 3.0-1 are located in /bin instead > >>> of /usr/bin. Is this a bug? > > Definitely. I have fixed this in SVN. Eric, I also commited your > > upload to SVN (please do so as well in future uploads). You might > > either upload the fixed version yourself in case you would like to do > > other changes (there is one remaining lintian warning about a formatting > > error in a manpage) or just ping me to do the upload. > Ups, I should have spotted that in our initial packaging. The > sources should have been in the svn repository for long, I possibly > just never ran the svn commit on them. So, thanks for fixing all that. > > Eric, I'll address that all tonight while bringing my laptop back in sync > with the repo. > Thanks, Steffen. Sorry for my absence here. Another thought -- HMMer 3 depends on a library and set of binaries called Easel the same way HMMer 2 depended on Squid/biosquid. At least one of the binaries is generally useful, esl-reformat. Should we extract Easel into a separate package at some point? -Eric
