Re: Connecting those interested in getting GT.M into the Debian repositories
Hi Andreas, Per your suggestion, I read the Debian Med Policy, and I've also spent several hours reading through chunks (but not all) of the "New Maintainer's Guide," the "Debian Policy," and the "Developer's Reference." What I learned is that I have a lot to learn (and a lot to read)! Although I've built numerous Debian packages before, I've never used them for anything outside of the systems that I maintain. That is, I setup my own Debian repository, and I placed my home-grown packages into it to help me administer servers. In the past, I learned how to build packages in two ways: (1) I took other packages apart to see how they work and (2) I read small parts of the Debian manuals, mainly to see how the files in the DEBIAN directory work. I'm certainly still interested in helping to get GT.M into the stream, but I'm feeling a little overwhelmed with what seem to be the requirements. I like, though, that the documentation recommends working with a mentor when you're new to packaging (which I certainly am :). I gather from what I've read in your postings, that you're adept at these things. My hope is that you or someone else in this group might be able to provide me with some assistance. I'm willing to do the leg work, and I'm always interested in learning more, but as I read these documents, I feel like I'm going from a basic math class right into Calculus II. To let you know where things are, I've tried several times to create an account at alioth.debian.org, but when I try to confirm the account, it returns the error message "Error Could Not Get User". Have you encountered this problem before? (If it's helpful, the account name I selected was "alanoneill".) Also, I've made the following changes to the package: - I used the information in the Debian Med Policy to update some of the fields in the DEBIAN/control file. - Where appropriate, I changed the owner and/or group from "bin" to "fis-gtm". - I put the permissions on the directories back to r-xr-xr-x (awaiting Bhaskar's response to your question). Looking forward to hearing from you. Thanks. Alan On 08/30/2010 06:01 AM, Andreas Tille wrote: Hi Alan, thanks for the more detailed explanation. On Sun, Aug 29, 2010 at 05:38:06PM -0400, Alan O'Neill wrote: 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 Because I was not sure about the system user bin myself I asked on debian-mentors list. I'm hereby quoting the answer[1]: HELP: No files on my system are owned by user or group bin. What good are they? Historically they were probably the owners of binaries in /bin? It is not mentioned in the FHS, Debian Policy, or the changelogs of base-passwd or base-files. LSB 1.3 lists bin as legacy, and says: "The 'bin' UID/GID is included for compatibility with legacy applications. New applications should no longer use the 'bin' UID/GID." The Debian Policy Manual also includes a statement about file permissions and owners in section 10.9: Files should be owned by root:root, and made writable only by the owner and universally readable (and executable, if appropriate), that is mode 644 or 755. Directories should be mode 755 or (for group-writability) mode 2775. The ownership of the directory should be consistent with its mode: if a directory is mode 2775, it should be owned by the group that needs write access to it. Following this advise I would recommend instead of using user bin just to create a new system user via adduser --system gtm (or some more reasonable user name) and use this one in the installation questions. 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, Do you have any practically relevant case in mind why someone without root privileges should wish to extract the content of the package manually? 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
Re: Connecting those interested in getting GT.M into the Debian repositories
Hi Andreas, Sorry -- I just solved the login issue. I am now a guest member of Alioth. Alan On 08/30/2010 06:01 AM, Andreas Tille wrote: Hi Alan, thanks for the more detailed explanation. On Sun, Aug 29, 2010 at 05:38:06PM -0400, Alan O'Neill wrote: 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 Because I was not sure about the system user bin myself I asked on debian-mentors list. I'm hereby quoting the answer[1]: HELP: No files on my system are owned by user or group bin. What good are they? Historically they were probably the owners of binaries in /bin? It is not mentioned in the FHS, Debian Policy, or the changelogs of base-passwd or base-files. LSB 1.3 lists bin as legacy, and says: "The 'bin' UID/GID is included for compatibility with legacy applications. New applications should no longer use the 'bin' UID/GID." The Debian Policy Manual also includes a statement about file permissions and owners in section 10.9: Files should be owned by root:root, and made writable only by the owner and universally readable (and executable, if appropriate), that is mode 644 or 755. Directories should be mode 755 or (for group-writability) mode 2775. The ownership of the directory should be consistent with its mode: if a directory is mode 2775, it should be owned by the group that needs write access to it. Following this advise I would recommend instead of using user bin just to create a new system user via adduser --system gtm (or some more reasonable user name) and use this one in the installation questions. 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, Do you have any practically relevant case in mind why someone without root privileges should wish to extract the content of the package manually? 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. Bhaskar, could you please elaborate more detailed on this requirement? Perhaps there is another solution for this instead of playing around with permissions in an unusual way. 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. If I'm not missleaded only the UID 0 has a special meaning and enables the user with this ID to superuser powers. *Usually* (but not necessarily) this user is called root. (IMHO, you can give this user any name, only the UID is checked - but that's an academical issue). To my knowledge no other UIDs are guaranteed to have any special meaning and as written above the use of user name bin is deprecated. 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'). I personally have no problem with gtm-su. It is just a name and if you regard it as useful it is fine for me. 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 oth
Re: Hi! I am new, I would appreciate some direction
On Sat, Sep 04, 2010 at 01:07:36AM +0300, George Marselis wrote: > > Obligation is probably the wrong word. It just makes sense to subscribe > > this mailing list. IMHO the best way to start in the Debian Med team is > > to read the Debian Med policy document[1] first. > > done. Great. > speaking of the Debian Med policy: > * http://ddtp.debian.org/ is down and the document is not updated to > reflect the change. Ahh, that is and was ddtp.debian.net. > * "Developpers Reference" <--typo > if i knew where the source for that document was, i think this would > be a 2 second change. Fixed. It is in svn://svn.debian.org/svn/debian-med/trunk/community/website/docs > > Could you please give some more information about InterPro (URL, > > short description)) and especially why it needs to be forked. Are > > you talking about[2]? > > Yes, I am talking about [2]. EBI is (literaly) across the Sanger > institute in the UK. > > Interpro Scan is what bioinformaticians calls a "pipeline". In > software engineering terms, it is called a toolkit. > > It consists of pre-compiled bioinformatics tools (mira, hmmr, thmmr, > signalp, seqret, pfscan, ncbi blast) and a framework to chain those > tools together, by running each tool in sequence and passing the > output files from one tool as the input to the next. Framework is > coded in Perl. It supports batch engines to parallelize its output: > Platform LSF, officially 4.2 even though I have it running on 7.0c, > OpenPBS and > > It is our bread and butter over there at KAUST. While it does its job > very adequately once set up, it is a major pain to setup for anything > more than a single machine. It is showing its age: Officially, it > supports only rsh for remote execution of commands, though it is > trivial to patch it to use ssh. > > It is also showing how it was not coded by someone with a software > engineering/computer science background, but I will not go into that, > because I have seen enough bioinformatics code to curse Larry Wall to > the 7th Circle of Hell :D THE GOGGLES! THEY DO NOTHING! > > ( production code: close( FILEHANDLE ) && system( chmod 777 $file ); > can you guess what happens if you run that over a slow NFS link? ) > > EBI has been working on a Java version of this framework but ETA is > well, unknown. In the meantime half the planet from California to Hong > Kong and Saudi Arabia are using interpro scan and poor sysadmins > around the world cry instead of celebrating Sysadmin Day. > > Officially, EBI has stopped maintaining this framework, but it is > going to be with us for a long long long long time. > > So, it is due for an overhaul, it needs to learn how to use the > official perl logging facility( to syslog, to file, to nagios ), it > needs to tell you on which host it encountered what error, it needs > stop having cryptic error messages, it needs to reduce the amount of > conf files it uses and it needs to be able to work with multiple > versions of the same program (just try to make it use hmmr 3.0) > > on the other hand, i have time. and cigars. and no beer. > > > > In Free Software there is no "have to use". Charles just wanted to help > > your work. If it is not helpful you probably can ignore Charles' work - > > however, Charles has proven in the past to create high quality packaging > > stuff. COnsidering that you wrote you would be a newcomer having at > > least a look onto this is strongly recommended and will give you a good > > example. However, I have not yet looked at Charles' mira packaging, > > thought. > > people are singing the praises of Mr Plessy :) I did take a look into > the debian/* contents. and i borrowed stuff :) The good thing of a team with same packaging policy is that borrowing is a nice way to save time. ;-) > > Please create an Alioth login. > > done. created the repo as well: > http://git.debian.org/git/debian-med/mira.git/ > > > The deadline for Squeeze can not be mat any more - we are in freeze > > period. It has turned out tat targeting at a certain release is not > > feasible - just do a proper packaging of the recent stable upstrean > > version and we will se in what distribution it will go. > > okie-dokie! > > > Hope that my first batch of answers was helpful > yes, sir, they were! > > Regards from Saudi Arabia, Ahh, great. It is good if Debian Med also grows in this region of the world! Welcome in the team. 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/20100904182859.ga20...@an3as.eu
Re: Connecting those interested in getting GT.M into the Debian repositories
On Sat, Sep 04, 2010 at 01:16:06PM -0400, Alan O'Neill wrote: > I'm certainly still interested in helping to get GT.M into the stream, > but I'm feeling a little overwhelmed with what seem to be the > requirements. We are here to help you overcoming the feeling of beeing overwhelmed. > I like, though, that the documentation recommends working > with a mentor when you're new to packaging (which I certainly am :). I > gather from what I've read in your postings, that you're adept at these > things. My hope is that you or someone else in this group might be able > to provide me with some assistance. This is in fact what we really want to do here. VistA is a real killer application and it would drastically enhance Debian Med so we are really interested. IMHO sharing expertise is the most straightforeward way to go here: We are lacking expertise in GT.M, but we are knowing a lot about packaging - so we try to do our best here. > To let you know where things are, I've tried several times to create an > account at alioth.debian.org, but when I try to confirm the account, it > returns the error message "Error Could Not Get User". Have you > encountered this problem before? (If it's helpful, the account name I > selected was "alanoneill".) This seems to have worked: https://alioth.debian.org/users/alanoneill-guest/ and I just have added you to the Debian Med team which grants you commit permission to SVN and Git. > Also, I've made the following changes to the package: > > - I used the information in the Debian Med Policy to update some of the > fields in the DEBIAN/control file. > - Where appropriate, I changed the owner and/or group from "bin" to > "fis-gtm". Great. > - I put the permissions on the directories back to r-xr-xr-x (awaiting > Bhaskar's response to your question). > > Looking forward to hearing from you. I would recommend to commit your current state of work to svn://svn.debian.org/svn/debian-med/trunk/packages/gtm/trunk (or any better name than gtm according to your own decision - just follow the example of all the other packages there). Do not hesitate to keep on asking if something remains unclear. 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/20100904183942.gb20...@an3as.eu
Re: Bug#592721: unblock: embassy-* and emboss.
Le Sat, Sep 04, 2010 at 06:50:03PM +0200, Julien Cristau a écrit : > On Sun, Sep 5, 2010 at 01:12:20 +0900, Charles Plessy wrote: > > > Just remove the embassy packages. This is a perfectly acceptable solution > > that > > I accepted in advance in the first email of this thread. > > > That's not going to fix emboss. Are you going to fix that one, or > should it get removed as well? I can prepare an update to add Breaks in emboss-lib, libajax6 and libnucleus6 in Squeeze, to open the way to a safe removal of the embassy pakcages. But EMBOSS 6.1 is an obsolete upstream version. The package in Sid is by all means superior, and does not need a Breaks declaration unless we would like to support the use of a mixture of Lenny and Squeeze. I understand that there is the freeze, but let's be practical and take the solution that needs the least work for both of us, and which will bring to our users an up-to-date version of EMBOSS. This version was released less than a month before the freeze, but is the current stable version, the only one to be supported upstream. If you were thinking about other release-critical issues, please open a bug so that our discussion can be more concrete. -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20100905002213.ga4...@merveille.plessy.net
