Re: Connecting those interested in getting GT.M into the Debian repositories
On Sun, Sep 05, 2010 at 03:35:27PM -0400, Alan O'Neill wrote: > The package I'm ready to submit installs the 32-bit version of GT.M > 5.4.000A. Additionally, I'll be able to build a package for the 64-bit > version. Are there different source tarballs for 32 and 64 bit? I'm just asking because usually in Debian we try to build the binary packages for different architectures (i386, amd64 and others) from *one* single source package. The build provess might differ in some options but usually there is one source package. > I could also build packages for earlier versions, if desired, I don't think we should spend to much time in the past. I guess we will have enough work to do with present and future releases. > and as new versions come out, I could put those together as well. I've > walked a bit of the directory structure under > http://svn.debian.org/viewsvn/debian-med/trunk/packages/, and it appears > that the next level is a package name followed immediately by "trunk" > and the "debian" directory (e.g., > .../trunk/packages/fastdnaml/trunk/debian). So should I store things at That's correct. > .../trunk/packages/fis-gtm-54000A-32/trunk/ > > or is it preferable to store it something like > > .../trunk/packages/fis-gtm/54000A/32/trunk/ > > or perhaps something else? I would go with .../trunk/packages/fis-gtm in any case. The version number will be available in the debian/changelog file and does not belong to the directory structure. If you answer my question above in a way that (at least for the moment) there is no chance to build from one single source binaries for different architectures, we could perhaps try something like .../trunk/packages/fis-gtm/i386/trunk .../trunk/packages/fis-gtm/amd64/trunk (but not 32 and 64, because there are other architectures in Debian which are 32 or 64 and which you probably do not have in mind). My recommendation would be to try a source layout which fits building of different architectures. > My second question is about how to issue the actual commands to submit > the package. For the purpose of this e-mail, I'll guess that I'll be > storing things under .../trunk/packages/fis-gtm/54000a/32/trunk. On my > local server, I issued the following command to create a test area. > > svnadmin create /home/alan/debian-med You do not need svnadmin. This is for the administration on the svn *server*. (BTW, if you are more comfortable with Git, you could also use Git - if not for a beginner SVN might be a bit more comfortable - the Git experts might like to correct me ...) > Then I issued this next command to import my files > > svn import > file:///home/alan/debian-med/trunk/packages/fis-gtm/54000a/32/trunk It seems that your SVN book makes things more complex than needed. The Debian Med policy document has some simple commands listed at http://debian-med.alioth.debian.org/docs/policy.html#id54060 So a simple: svn co svn+ssh://u...@alioth.debian.org/svn/debian-med/trunk/packages should have provided you with all the stuff you need. If you are scared by the lot of stuff which might simply steal your bandwidth I just created a directroy fis-gtm which provides a fresh workspace for your purpose without checking out everything: svn co svn+ssh://u...@alioth.debian.org/svn/debian-med/trunk/packages/fis-gtm > At this point it seems that svn knows about my files. And I can even > checkout the files with > > svn checkout > file:///home/alan/debian-med/trunk/packages/fis-gtm/54000a/32/trunk > > But all this stuff seems to work because the files are already on my > server. Of course, my goal is to put the files onto the server where > the actual debian-med lives. So I seem to be approaching things from > the wrong end. Can you give me a hint as to how the svn command(s) > should be structured to copy the files from my server to debian-med? Forget the book (not honestly - but to get start working quickly), put your files in the fis-gtm directory you got above and then do svn add svn commit > Thanks again! Hope this helps - if not do not hesitate to keep on asking. 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/20100906083141.gb5...@an3as.eu
Re: Connecting those interested in getting GT.M into the Debian repositories
Hi Andreas, Thanks for the tips on SVN -- very helpful! When last I wrote, I had begun to think that you and I were working with one different assumption, and from what you just wrote, it is now confirmed. The package I have built is not a source package, it is a binary package. I have compiled GT.M from source in the past, but it has an interesting twist: To build GT.M from source, you must already have the binary installed on your machine because somehow the binary is used to help with the build. (I've always gotten a kick out of that -- how was the very first version of GT.M compiled? :) To continue, I'll need to learn more about building source packages -- it's something I've never done before. If you're up for offering some more help along the way, I'm willing to continue down this road. I've never shied away from learning new things. One thing that does occur to me, though, is that since building GT.M requires the binary installation, it may be necessary to distribute a binary package as well. What are your thoughts? Thanks. 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/4c84ecbe.9040...@cavtel.net
Re: Connecting those interested in getting GT.M into the Debian repositories
On Mon, Sep 06, 2010 at 09:29:34AM -0400, Alan O'Neill wrote: > Thanks for the tips on SVN -- very helpful! :-) > When last I wrote, I had begun to think that you and I were working with > one different assumption, and from what you just wrote, it is now > confirmed. The package I have built is not a source package, it is a > binary package. I have compiled GT.M from source in the past, but it > has an interesting twist: To build GT.M from source, you must already > have the binary installed on your machine because somehow the binary is > used to help with the build. (I've always gotten a kick out of that -- > how was the very first version of GT.M compiled? :) Well, this was previousely discussed. You somehow need to have a GT.M installed on the system and then you build the first binary package. For past discussions probably this is the best link: http://lists.debian.org/debian-devel/2008/02/thrd2.html#00549 > To continue, I'll need to learn more about building source packages -- > it's something I've never done before. To make it clear: For official Debian we are *only* talking about source packages which are turned into binary packages using the Debian packaging tools which are based on dpkg-buildpackage and its wrappers like debuild, pdebuild or others. A source package consists of the original source tarball and a debian/ directory which contains the files which are needed to build the binary package. That is what we are talking about as "building a package". It is documented in several places and probably this is the best entry point: http://www.debian.org/doc/maint-guide/ > One thing that does occur to me, though, is that since building GT.M > requires the binary installation, it may be necessary to distribute a > binary package as well. See above the link to the discussion thread on debian-devel list. 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/20100906195940.ga31...@an3as.eu
Re: Connecting those interested in getting GT.M into the Debianrepositories
I am catching up on e-mail and will try to respond to all the issues thoughtfully discussed by Andreas and Alan in this single response. Preference for no root owned files in the .deb distribution files: I have a preference for not including any files owned by root in the .deb distribution files. This makes it easy for anyone who wants to analyze a package to be able to unpack it without needing root access. Since I often need to run 32-bit executables on a 64-bit Linux, I find I need to often need to take apart packages and it is an inconvenience to need root. Use of bin: GT.M itself makes no assumptions about the ownership of the files, and offers bin as the default for historical reasons and because the same install script is used for all GT.M on all UNIX/Linux flavors. GT.M itself is quite happy for the installed distribution to be owned by root. There is an installation option to restrict the execution of GT.M to members of a group. I suggest that the default for Debian is to not so restrict it, but to provide the option (for those who choose the "ask me everything when installing packages" installation option) to prompt for installing it so restricted. Note that the gtmsecshrdir directory must be owned by root with permissions to only allow access by the owner (not even group). It contains one file, gtmsecshr that is owned by root and readable and executable only by the owner, not even group and with the setuid bit on). The parent directory also has a file called gtmsecshr, which must be owned by root and be readable and executable by the owner with the setuid bit on. This outer gtmsecshr file has the same group as all other GT.M files and it's world read and execute permissions can be turned off if GT.M access is restricted to a group. Incidentally, there is no assumption that bin is uid 2 (and symbolic names are preferred over numeric ones anyway). Writabilty of files: I prefer for an installed version of GT.M to not have *any* writable files, even if root-owned and only owner-writable. The prerm script can make files writable for removal, or the remove script can use a -f flag to override. .o files: .o files are object files compiled from .m source files. There are two types of .o files - those that are considered part of GT.M itself that are written in M and those that are utility programs written in M. The former is the utility program GDE. Since it is considered part of GT.M itself and generates a binary image of a data structure that is loaded into RAM, our normal GT.M binary distributions do not include the source code (of course, the source tarball does). The source code for the utility programs is included with the binary distributions to allow users to adapt and customize. The concept of a "single user" GT.M is not meaningful. GT.M is inherently multi-user. However, individual databases can be single- or multi-user. The script "gtm" and the file gtmprofile that can be sourced - their use is optional since the entire operation of GT.M is controlled by environment variables - looks for an environment variable $gtmdir and defaults this to $HOME/.fis-gtm if it is not defined. Alan, please do not link the FIS provided gtm script with the name gtm-su. gtm is the upstream name for the script, and if you override it, you run the risk of causing problems for someone who comes after you. I realize that you have independently created your own personal "gtm" script. I am sorry if I sound hard-hearted, but it is better for you to bear a little one-of pain than to institutionalize something that will keep causing headaches in the future. Unicode version: GT.M itself requires ICU version 3.6 or higher. However, there is a defect in the way Debian packages ICU, by putting the version number in the package name (e.g., libicu36). So, there is no way to define a dependency for GT.M of version 3.6 or greater. Also, there is a very useful program icu-config that is part of libicu-dev rather than libicu. So I recommend making GT.M depend on libicu-dev with a version of 3.6 or greater. [Note that use of GT.M for languages with 8-bit characters, such as with ISO-8859 family representations does not need ICU, and therefore in theory libicu / libicu-dev can be recommended rather than required. However, anyone today starting to write a new application today, and using ISO-8859 character sets that use the high order bit is asking for trouble when internationalizing tomorrow, is asking for trouble. So, it may be better to just require ICU.] Source tarballs: the same source tarball is used to build both the 32- and 64-bit executables. Note that GT.M compiler's code generator is very different internally for the two, but we only release one source tarball from which you can build both binaries. GT.M versions: I see no reason to package anything other than the latest, V5.4-001. Once we establish (Alan establishes) a pro
Re: Connecting those interested in getting GT.M into the Debianrepositories
Dear Bhaskar, here are two short comments about unpacking binary packages and dependance on libicu. Le Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar a écrit : > > Preference for no root owned files in the .deb distribution files: I have a > preference for not including any files owned by root in the .deb distribution > files. This makes it easy for anyone who wants to analyze a package to be > able > to unpack it without needing root access. Debian binary packages are archives in GNU ‘ar’ format, that contain two compressed tar archives, control.tar.gz and data.tar.gz. Installed files are in control.tar.gz and although they are owned by root, tar will substitute the ownership for the local user, so there is no need to have a root access to inspect the contents of a Debian package. In summary, you can just type ‘ar -x packagename.deb’ and then ‘tar xfz control.tar.gz’ to unpack a package in the current directory. (In rare cases, the control and data tar archives may be compressed with a different program, like bzip2, but the principle stays the same.) > Unicode version: GT.M itself requires ICU version 3.6 or higher. However, > there is a defect in the way Debian packages ICU, by putting the version > number > in the package name (e.g., libicu36). So, there is no way to define a > dependency for GT.M of version 3.6 or greater. Also, there is a very useful > program icu-config that is part of libicu-dev rather than libicu. Currently, the lowest version of ICU in Debian is 3.8, so there is no immediate problem with the naming scheme anyway. Furthermore, the dependancy on packages like libicu36 are machine-inserted at build time. As you noted, the development package itself does not have a version number encoded in its name. Therefore, the GT.M source package can build-depend on libicu-dev ( >= w.x ), where w.x is what GT.M needs, and the binary package will automatically depend on a libicuyz package determined from the analysis of the symbols used by the GT.M binary packages, and a file contained in libicu-dev listing in which version of the library they were introduced. Have a nice day, -- 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/20100907045933.ga10...@merveille.plessy.net
Re: Connecting those interested in getting GT.M into the Debianrepositories
On Tue, Sep 07, 2010 at 01:59:33PM +0900, Charles Plessy wrote: > > Preference for no root owned files in the .deb distribution files: I have a > > preference for not including any files owned by root in the .deb > > distribution > > files. This makes it easy for anyone who wants to analyze a package to be > > able > > to unpack it without needing root access. > > Debian binary packages are archives in GNU ???ar??? format, that contain two > compressed tar archives, control.tar.gz and data.tar.gz. Installed files are > in > control.tar.gz and although they are owned by root, tar will substitute the > ownership for the local user, so there is no need to have a root access to > inspect the contents of a Debian package. In summary, you can just type ???ar > -x > packagename.deb??? and then ???tar xfz control.tar.gz??? to unpack a package > in the > current directory. Additional note: Most modern filemanagers are able to open / view *.deb files. I'm using MidnightCommander which is perfectly able to handle the content of *.deb files. 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/20100907063152.gd20...@an3as.eu
Re: FreeMedForms project
Hi Eric, On Tue, Sep 07, 2010 at 12:57:04AM +0200, Eric MAEKER wrote: > Thank you for your help on providing a package for FreeDiams 0.4.2. This > was a great enjoyement to work with you on this. I hope it was an enjoyment to work in the Debian Med team - thus I just post to the list because the following is definitely interestint (shamelessly ignoring Netiquette). > May be you remember that FreeDiams is part of a more global work called > FreeMedForms. The FreeMedForms project is a set of medical applications. > The main one is the EMR : FreeMedForms. It is actually in alpha stage. > Lots of features are already added and functionnal. > > I believe the FreeMedForms EMR could be part of Debian-Med. Sure it is. > I was wondering if you would like to help me in providing a source and > debian package. The sources are shared from FreeMedForms and FreeDiams > so all the work already done on FreeDiams is also done for FreeMedForms. > > http://www.freemedforms.org/ We definitely can proceed like in the case of FreeDiams. Just tell me if there is some preliminary packaging stuff and simply commit the debian/ directory to the SVN. Either me (or somebody else of the team) will have a look and than we proceed as before. IMHO we have a lot of time until Debian 7.0 will be released to stabilize FreeMedForms in Debian. ;-) > I can start some specific work in about two or three weeks (FreeDiams > 0.5.0 should be released at this time). Great. Guessing from past experience the packaging of new upstream versions is not that hard as the initial packaging so I do not expect any real problems here to move this quickly to Debian unstable. It might be that we should even use the experimental distribution as long as Squeeze is not yet released - but that's just a detail. Kind regards and thanks for working together with Debian Med 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/20100907061731.gc20...@an3as.eu
Re: Connecting those interested in getting GT.M into the Debianrepositories
On Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar wrote: > Writabilty of files: I prefer for an installed version of GT.M to not > have *any* writable files, even if root-owned and only owner-writable. Debian policy has a read-only mounted /usr partition in mind. While in practice this is very rarely used the principle is valid, that anything which is installed to /usr should not be touched manually. If there are configuration files these should be moved to /etc/ and symlinked from /usr. So what you are asking for is completely in the line as we are working anyway. > The prerm script can make files writable for removal, or the remove > script can use a -f flag to override. The prerm file will remove the package content anyway (and it also should care for those filese which might have been created when using the program). Data which are subject of change should go to /var/lib/ (and should be cleaned up as well if the package is *purged*). > Unicode version: GT.M itself requires ICU version 3.6 or higher. > However, there is a defect in the way Debian packages ICU, by putting > the version number in the package name (e.g., libicu36). So, there is > no way to define a dependency for GT.M of version 3.6 or greater. This was just clarified by Charles. > Source tarballs: the same source tarball is used to build both the 32- > and 64-bit executables. Note that GT.M compiler's code generator is > very different internally for the two, but we only release one source > tarball from which you can build both binaries. Thanks for the clarification. > GT.M versions: I see no reason to package anything other than the > latest, V5.4-001. Once we establish (Alan establishes) a process for > creating GT.M Debian packages from upstream releases, then future > releases will slide into place! ACK. > I think I have responded to all the issues. If I have overlooked any, > please let me know, and I will respond tomorrow (Tuesday, September 7, > US Eastern time). Thanks Alan and Andreas for all your efforts. Thanks for the clarifications 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/20100907064031.ge20...@an3as.eu
