Re: Bug#657919: ITP: r-cran-digest - Create cryptographic hash digests of R objects
On 30 January 2012 at 12:10, Carlos Borroto wrote: | On Sun, Jan 29, 2012 at 10:16 PM, Dirk Eddelbuettel wrote: | > | > On 29 January 2012 at 19:18, Carlos Borroto wrote: | > | On Sun, Jan 29, 2012 at 6:42 PM, Dirk Eddelbuettel wrote: | > | > | > | > On 30 January 2012 at 00:22, Andreas Tille wrote: | > | > | Hi Carlos, | > | > | | > | > | thanks for your ITP. | > | > | | > | > | On Sun, Jan 29, 2012 at 06:14:30PM -0500, Carlos Borroto wrote: | > | > | > Package: wnpp | > | > | > Severity: wishlist | > | > | > Owner: Carlos Borroto | > | > | > X-Debbugs-Cc: debian-med@lists.debian.org | > | > | > | > | > | > | > | > | > * Package name: r-cran-digest | > | > | > Version: 0.5.1 | > | > | > Upstream Author: Dirk Eddelbuettel | > | > | | > | > | Well, Dirk is the main packager of R software inside Debian. If he is | > | > | upstream of some software but did not packaged it for Debian, he might | > | > | have his reasons to do so. I would like Dirk to comment on this ITP | > | > I didn't answer this bit: No particular reason. I have 10+ packages on CRAN | > but only maintain two or three in Debian ... as the others install so easily | > in R itself. (digest for example has not further depends). And I already | > have 120+ packages so time is somewhat limited. | > | > But (r-cran-)digest makes some sense. | > | > | > | before uploading something. | > | > | > | > I'll do it. The package turned out to be a) relatively widely used for all | > | > the caching things that use it as a base and b) changes rarely. | > | > | > | > I'll make an initial upload in a few days. | > | > | > | > Thanks for the heads-up! | > | > | > | | > | Hi Dirk, Andreas, | > | | > | I noted the @debian.org, but I did not know Dirk is the main R maintainer. | > | | > | My interest is to package cummeRbund[1], which needs ggplot2, which in | > | turn needs digest. | > | > Oh, something from BioConductor -- nice. I just did a quick apt-cache search | > r-bioc and there to be four others so I suppose you know the suggested | > r-bioc-cummerbund pattern? | > | | Sure, I already have the git repository setup with that name: | http://git.debian.org/git/debian-med/r-bioc-cummerbund.git | | > | I'll be packaging the rest of the dependencies and I'll wait for Dirk | > | for digest. Should I remove this wnpp bug? | > | > Up to you. I can simply close it. | > | > Will be nice to have ggplot2 and reshape in as well. | > | | Well this is the complete list of packages I'm working on in order to | be able to include cummeRbund: | r-cran-digest | r-cran-ggplot2 | r-cran-plyr | r-cran-proto | r-cran-reshape | r-cran-reshape2 | r-cran-rsqlite | r-cran-stringr Nice. All will be good to have. | They all build right now. I'm missing the license text to add for | packages using MIT and Artistic-2, an easy fix I think. The only major | issue I found was with RSQLite, which includes the sqlite3 source, but | I'm guessing I need to link against Debian's sqlite3. Then you may need to patch the upstream configure. When I was doing the automatic builds of 2000+ (at the time) CRAN packages that were autogenerated as .deb package, I just left it as is. Given that R needs to run on Windoze, OS X and various Linux/Unix flavours it was defensible for for Seth to include the sources. | It is quite easy to install these packages through R, but my idea is | to use these tools in a cluster. I would like to have a better way to | deal with installation and maintenance. Right. Michael Rutter is cvarrying my torch of that older 'cran2deb' project but it is currently Ubuntu-only via launchpad, look at 'c2d4u' (akak "cran2deb4ubuntu"). Cheers, Dirk | Thanks, | Carlos -- "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read." -- Groucho Marx -- 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/20263.30974.955877.656...@max.nulle.part
Re: Initial Grinder package
Charles Plessy-12 wrote: > > Florent, since the files in /inc are also distributed as Debian packages: > are > they strictly neeeded, or could they be omitted? That would reduce the > code > duplication in our archive. > Thanks for the help with the package upload, Charles. What you ask is a good question. I think this is possible but it is sort of going against the philosophy of Module::Install To achive what you suggest requires adding libmodule-install-perl (and other modules that have files in inc) as a build-dependency of the package. Then the files under inc/ but not the inc/ directory itself need to be deleted, otherwise Module::Install will think it is being called by the author of the module instead of a user (see http://search.cpan.org/~adamk/Module-Install/lib/Module/Install/Admin.pm#Bootstrapping). Changing the first line of the Makefile.PL from 'use inc::Module::Install;' (to use the modules in inc/) to 'use inc::Module::Install;' (to use their system-wide quivalent) is not an option since it generates an error. The perl-pkg group does not seem to strip inc/ for their packages that use Module::Install. Maybe it is not worth the trouble. Florent -- View this message in context: http://old.nabble.com/Initial-Grinder-package-tp33185950p33234029.html Sent from the debian-med mailing list archive at Nabble.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/33234029.p...@talk.nabble.com
Re: [MoM] Packaging fis-get
On Mon, Jan 30, 2012 at 05:02:37PM +0100, Karsten Hilbert wrote: > > >The "problem" with bootstrapping is that Debian does not > > >allow to use "foreign" binaries (that is, binaries not > > >buildable on Debian) in order to build packages. > > > > [KSB3] So Debian doesn't use gcc? > > Of course it does and there's been an exception for it. It's not the only exceptional case; I believe haskell (ghc) build depends on itself. Have you consulted them for pointers on bootstrapping? > But that doesn't mean we should ask for an exception when it is not > truly needed. I agree with that! -Steve signature.asc Description: Digital signature
Re: Bug#657919: ITP: r-cran-digest - Create cryptographic hash digests of R objects
On Sun, Jan 29, 2012 at 10:16 PM, Dirk Eddelbuettel wrote: > > On 29 January 2012 at 19:18, Carlos Borroto wrote: > | On Sun, Jan 29, 2012 at 6:42 PM, Dirk Eddelbuettel wrote: > | > > | > On 30 January 2012 at 00:22, Andreas Tille wrote: > | > | Hi Carlos, > | > | > | > | thanks for your ITP. > | > | > | > | On Sun, Jan 29, 2012 at 06:14:30PM -0500, Carlos Borroto wrote: > | > | > Package: wnpp > | > | > Severity: wishlist > | > | > Owner: Carlos Borroto > | > | > X-Debbugs-Cc: debian-med@lists.debian.org > | > | > > | > | > > | > | > * Package name: r-cran-digest > | > | > Version: 0.5.1 > | > | > Upstream Author: Dirk Eddelbuettel > | > | > | > | Well, Dirk is the main packager of R software inside Debian. If he is > | > | upstream of some software but did not packaged it for Debian, he might > | > | have his reasons to do so. I would like Dirk to comment on this ITP > > I didn't answer this bit: No particular reason. I have 10+ packages on CRAN > but only maintain two or three in Debian ... as the others install so easily > in R itself. (digest for example has not further depends). And I already > have 120+ packages so time is somewhat limited. > > But (r-cran-)digest makes some sense. > > | > | before uploading something. > | > > | > I'll do it. The package turned out to be a) relatively widely used for all > | > the caching things that use it as a base and b) changes rarely. > | > > | > I'll make an initial upload in a few days. > | > > | > Thanks for the heads-up! > | > > | > | Hi Dirk, Andreas, > | > | I noted the @debian.org, but I did not know Dirk is the main R maintainer. > | > | My interest is to package cummeRbund[1], which needs ggplot2, which in > | turn needs digest. > > Oh, something from BioConductor -- nice. I just did a quick apt-cache search > r-bioc and there to be four others so I suppose you know the suggested > r-bioc-cummerbund pattern? > Sure, I already have the git repository setup with that name: http://git.debian.org/git/debian-med/r-bioc-cummerbund.git > | I'll be packaging the rest of the dependencies and I'll wait for Dirk > | for digest. Should I remove this wnpp bug? > > Up to you. I can simply close it. > > Will be nice to have ggplot2 and reshape in as well. > Well this is the complete list of packages I'm working on in order to be able to include cummeRbund: r-cran-digest r-cran-ggplot2 r-cran-plyr r-cran-proto r-cran-reshape r-cran-reshape2 r-cran-rsqlite r-cran-stringr They all build right now. I'm missing the license text to add for packages using MIT and Artistic-2, an easy fix I think. The only major issue I found was with RSQLite, which includes the sqlite3 source, but I'm guessing I need to link against Debian's sqlite3. It is quite easy to install these packages through R, but my idea is to use these tools in a cluster. I would like to have a better way to deal with installation and maintenance. Thanks, Carlos -- 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/CABgGhBKUyN2sAK0YbSgPUzRttQrJnzMK01VWuChw=xzujxm...@mail.gmail.com
Bug#657997: ITP: r-bioc-cummerbund -- tool for analysis of Cufflinks RNA-Seq output
Package: wnpp Severity: wishlist Owner: Carlos Borroto X-Debbugs-Cc: debian-med@lists.debian.org * Package name: r-bioc-cummerbund Version: 1.0.0 Upstream Author: Loyal A. Goff * URL: http://compbio.mit.edu/cummeRbund/ * License: GPL-2+ Programming Lang: R Description: tool for analysis of Cufflinks RNA-Seq output Allows for persistent storage, access, exploration, and manipulation of Cufflinks high-throughput sequencing data. In addition, provides numerous plotting functions for commonly used visualizations. -- 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/cabgghbkyoqsycq_eywnghsoma5oem+gsg-rguwolw-yx7a0...@mail.gmail.com
Bug#657996: ITP: r-cran-stringr -- Make it easier to work with strings
Package: wnpp Severity: wishlist Owner: Carlos Borroto X-Debbugs-Cc: debian-med@lists.debian.org * Package name: r-cran-stringr Version: 0.6 Upstream Author: Hadley Wickham * URL: * License: GPL-2 Programming Lang: R Description: Make it easier to work with strings stringr is a set of simple wrappers that make R's string functions more consistent, simpler and easier to use. It does this by ensuring that: function and argument names (and positions) are consistent, all functions deal with NA's and zero length character appropriately, and the output data structures from each function matches the input data structures of other functions. -- 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/CABgGhBK5Ti60YXH7n2CQETTPSRKqUviyHY5yFXw0o4Wc=sc...@mail.gmail.com
Bug#657995: ITP: r-cran-rsqlite -- Database Interface R driver for SQLite
Package: wnpp Severity: wishlist Owner: Carlos Borroto X-Debbugs-Cc: debian-med@lists.debian.org * Package name: r-cran-rsqlite Version: 0.11.1 Upstream Author: Seth Falcon * URL: http://cran.r-project.org/web/packages/RSQLite/ * License: LGPL-2+ Programming Lang: C, R Description: Database Interface R driver for SQLite This package embeds the SQLite database engine in R and provides an interface compliant with the DBI package. The source for the SQLite engine (version 3.7.9) is included. -- 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/cabgghblt5gay4r_lme7cawnwc5vsbth99nx3kykgaeqvaim...@mail.gmail.com
Report from Debian Med sprint
Hi, as you might have noticed the Debian Med team has organised its second sprint in Southport last weekend[1]. I would like to give a short report about this from my personal perspective. I added a short version of my agenda to the Wiki page[2]. 1) Ensembl packaging specifically working on installation in unstable without any conflicts (=trying to solve libwww issue) One main item for this meeting on my agenda was fixing the Ensembl package to finally enable a migration from experimental to unstable. One of the big showstopers is #636923. However, unfortunately the to persons who I urgently needed to discuss this topic did finally not attend and I was only able to determine, that the problem can be stripped down to the problematic package is actually liblwp-parallel-perl. I'll try to keep on working on this. 2) The Beast-mcmc[3] finishing This package is on my agenda since about one year and I was able to iron out nearly all included binary JAR files. However I get struck on the last problematic JAR mtj.jar is a mess of other included JARs based on f2j blas/arbapck JARs. I reached a state where I got a hint from upstream to the sources for the last JAR in this chain and I need to see whether I will be able to compile. I'll give this a try in the next couple of weeks if not I will push the package to non-free first and leave the final freeing to some later point in time. As usual, any help is welcome. 3) Continuing with current MoM[4]; presenting MoM to the audience to gather more potential students I kept on mentoring the student and there is further progress with the package we are focussing on. Moreover it might be that some participants from the workshop might step in for later Monthes 4) Finishing sofa-framework which needs to be updatet to new version Nothing done on this front 5) Bug squashing of Debian Med team maintained packages Two bugs fixed by new upstream version of GinkgoCADx (#657827, #648167) 6) If time permits work on some Beast related phylogeny packages Uploaded phy-spread package 7) Checking status of Debian Med tasks The attempt to check the tasks was completely spoiled when noticing that the tools are broken because of technical changes in Debian infrastructure[5]. Sorting this out and enabling regularly updated tasks pages is now on highest position in my priority list. 8) Spontaneous mentoring of people I gave a spontaneous introductional talk about Debian and Blends structure Moreover I was mentoring Quyen, Laszlo and others about gpg keys 9) Working on Blends sentinel bugs overview This was terribly blocked by non-functional fetching translations from ddtp.debian.net which is down. Caring for alternatives to at least get tasks pages updated again but no success so far. (see also item 7) above) 10) Helping others packaging and sponsoring * Sponsored chado (gmod suite) prepared by Olivier Sallou * Helped Charles getting snappy-java using Debian packaged library (see below external wishlist) * Worked with Ivo on copasi * Helped Martin with Python packaging * Dived a bit into a Ruby package together with Quyen with no certain outcome - needs further negotiation with Quyen and other upstream how to proceed * Checking the work of Piero on three Python packages * Had a look with Toni into OpenMicroscopy noticing that it is a beast containing > 800 binary JAR files inside the source and will take a talented and very patient Java expert to copy with all this stuff The good news is that upstream was quite supportive to provide a downloadable versioned archive which simplifies obtaining the source Needs (a lot) of further work which I'm unable to do myself 11) License checking I was suggesting an ePetition to free Phylip and wrote a first draft for it[6] Thanks to al participants who joined the workshop and made it a success (again). Looking foreward to next Debian Med workshop. Kind regards Andreas. [1] http://wiki.debian.org/DebianMed/Meeting/Southport2012 [2] http://wiki.debian.org/DebianMed/Meeting/Southport2012#Andreas_Tille [3] http://svn.debian.org/wsvn/debian-med/trunk/packages/beast-mcmc/trunk/ [4] http://wiki.debian.org/DebianMed/MoM [5] http://lists.debian.org/debian-qa/2012/01/msg00078.html [6] http://wiki.debian.org/DebianMed/Meeting/Southport2012/ePetition_Phylip -- 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/20120130161731.gk26...@an3as.eu
Bug#657994: ITP: r-cran-proto -- Prototype object-based programming
Package: wnpp Severity: wishlist Owner: Carlos Borroto X-Debbugs-Cc: debian-med@lists.debian.org * Package name: r-cran-proto Version: 0.3-9.2 Upstream Author: Gabor Grothendieck * URL: http://r-proto.googlecode.com/ * License: GPL-2 Programming Lang: R Description: Prototype object-based programming An object oriented system using object-based, also called prototype-based, rather than class-based object oriented ideas. -- 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/cabgghbk8nudmyytcavkrgspdo21hd29mtx4fxqnak9aswlc...@mail.gmail.com
Bug#657993: ITP: r-cran-plyr -- Tools for splitting, applying and combining data
Package: wnpp Severity: wishlist Owner: Carlos Borroto X-Debbugs-Cc: debian-med@lists.debian.org * Package name: r-cran-plyr Version: 1.7.1 Upstream Author: Hadley Wickham * URL: http://had.co.nz/plyr * License: MIT Programming Lang: Description: Tools for splitting, applying and combining data plyr is a set of tools that solves a common set of problems: you need to break a big problem down into manageable pieces, operate on each pieces and then put all the pieces back together. For example, you might want to fit a model to each spatial location or time point in your study, summarise data by panels or collapse high-dimensional arrays to simpler summary statistics. The development of plyr has been generously supported by BD (Becton Dickinson). -- 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/CABgGhB+6iBYjUggyjnQzanC=fompdjnjsgumpjwtfroamr0...@mail.gmail.com
Bug#657989: ITP: r-cran-ggplot2 -- An implementation of the Grammar of Graphics
Package: wnpp Severity: wishlist Owner: Carlos Borroto X-Debbugs-Cc: debian-med@lists.debian.org * Package name: r-cran-ggplot2 Version: 0.8.9 Upstream Author: Hadley Wickham * URL: http://had.co.nz/ggplot2 * License: MIT Programming Lang: Description: An implementation of the Grammar of Graphics An implementation of the grammar of graphics in R. It combines the advantages of both base and lattice graphics: conditioning and shared axes are handled automatically, and you can still build up a plot step by step from multiple data sources. It also implements a sophisticated multidimensional conditioning system and a consistent interface to map data to aesthetic attributes. -- 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/CABgGhB+PN7G+jRyOwg-apExT==p8qrdzwehzwrsfopj+bbv...@mail.gmail.com
Re: [MoM] Packaging fis-get
On Mon, Jan 30, 2012 at 10:32:08AM -0500, Bhaskar, K.S wrote: > >>However, I don't really understand the problem with bootstrapping. > >>It only needs to be done once and that bootstrap has already been > >>accomplished. > >No it hasn't (as far as Debian is concerned) or else there > >would be an installable Debian package for bootstrapping > >GT.M. > > > >I might be wrong. If so, please point me to the DFSG > >compatible package I can install to either bootstrap a GT.M > >or a DFSG-compliantly valid GT.M package. > > > >The "problem" with bootstrapping is that Debian does not > >allow to use "foreign" binaries (that is, binaries not > >buildable on Debian) in order to build packages. > > [KSB3] So Debian doesn't use gcc? Of course it does and there's been an exception for it. But that doesn't mean we should ask for an exception when it is not truly needed. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20120130160237.gi2...@hermes.hilbert.loc
Re: [MoM] Packaging fis-get
On 01/30/2012 10:25 AM, Karsten Hilbert wrote: On Mon, Jan 30, 2012 at 09:46:17AM -0500, Bhaskar, K.S wrote: - GT.M is written in Mumps and thusly needs to be compiled by a Mumps compiler - this presents a chicken-egg problem in that Debian does not allow packages to be included without compiling them from source [KSB2] GT.M is almost entirely written in C with a few small bits in assembler. That makes it a lot easier. Some utility programs are written in MUMPS. Are those needed to build GT.M ? [KSB3] No When building GT.M, some C source programs are generated from text files using a MUMPS program - Are those files *required* to build GT.M ? [KSB3] Yes this is where GT.M is used to build GT.M, and it is a text to text transformation. How much data are we talking about ? [KSB3] I will find out. However, I don't really understand the problem with bootstrapping. It only needs to be done once and that bootstrap has already been accomplished. No it hasn't (as far as Debian is concerned) or else there would be an installable Debian package for bootstrapping GT.M. I might be wrong. If so, please point me to the DFSG compatible package I can install to either bootstrap a GT.M or a DFSG-compliantly valid GT.M package. The "problem" with bootstrapping is that Debian does not allow to use "foreign" binaries (that is, binaries not buildable on Debian) in order to build packages. [KSB3] So Debian doesn't use gcc? Regards -- Bhaskar In my opinion, if you really want to eliminate the bootstrap, We/I don't want to eliminate it. We want to get it done because we have to if we want to have GT.M on Debian. the obvious solution is to use awk or perl for the small number of files involved. For example. That is one of the options I am trying to assess how complicated it would be. Or, for the initial bootstrap, just take the generated C files from an existing GT.M for the bootstrap. Since those *are* source code I wonder whether that might be compliant with DFSG. Anyone ? BTW: In case all this has already been solved in an existing, compliant Debian (pre-)package we would surely like to know about it ! Karsten -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _ 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/4f26b7f8.1030...@fisglobal.com
Re: [MoM] Packaging fis-get
On 01/30/2012 10:19 AM, Andreas Tille wrote: On Mon, Jan 30, 2012 at 09:46:17AM -0500, Bhaskar, K.S wrote: In my opinion, if you really want to eliminate the bootstrap, the obvious solution is to use awk or perl for the small number of files involved. Or, for the initial bootstrap, just take the generated C files from an existing GT.M for the bootstrap. Hmmm, this is actually a quite interesting hint. Could you please negotiate this issue with Luis. While we just got confirmation from ftpmaster that they are willing to accept the procedure of bootstrapping it might simplify things a lot if no binaries are involved in this process. So if you could sort this out with Luis I would really welcome this. Kind regards and greetings from Manchester Airport :-) [KSB] While this is feasible (it's all a small matter of programming, depending on your definition of "small"), the work involved is not technically challenging but would be time consuming. Since time is not free (even if it does not translate to money, there is the lost opportunity), it would be better to work with the bootstrapping exemption since (a) ftpmasters have already agreed and (b) there is a bootstrapping precedent for gcc. Safe travels. Regards -- Bhaskar Andreas. -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _ 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/4f26b697.3090...@fisglobal.com
Re: [MoM] Packaging fis-get
On Mon, Jan 30, 2012 at 04:15:55PM +0100, Andreas Tille wrote:
> > - this presents a chicken-egg problem in that Debian does
> > not allow packages to be included without compiling them
> > from source
>
> Not really. In previous discussions (to lazy to search for this) we got
> confirmation from ftpmaster to accept this. So bootstrapping is not
> impossible in Debian.
OK, sounds good. Given what Bhaskar said ("C code that's
usually created by Mumps - like GT.M - can be taken from
another GT.M") there is not even any foreign binaries
involved: Use a C compiler to build GT.M and be done :-)
> Even if there would some from my perspective the need to package two
> different Mumps implementations to circumvent bootstrapping causes mor
> trouble than needed. It involves two problems:
>
>1. Finding another Mumps implementation
>2. Checking whether this really is bale to build GT.M
>
> Compared to only one problem (negotiating with ftpmaster) I'd regard
> your suggestion as harder to realise.
That's correct given the above. It would have been the way
out if ftpmaster said NO and Mumps (as in "any") would have
been required to compile Mumps (as in "GT.M").
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
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/20120130153813.gg2...@hermes.hilbert.loc
Re: [MoM] Packaging fis-get
On Mon, Jan 30, 2012 at 09:46:17AM -0500, Bhaskar, K.S wrote: > >- GT.M is written in Mumps and thusly needs to be compiled > > by a Mumps compiler > > > >- this presents a chicken-egg problem in that Debian does > > not allow packages to be included without compiling them > > from source > > [KSB2] GT.M is almost entirely written in C with a few small bits in > assembler. That makes it a lot easier. > Some utility programs are written in MUMPS. Are those needed to build GT.M ? > When building GT.M, some C source programs are generated from text files > using a MUMPS program - Are those files *required* to build GT.M ? > this is where GT.M is used to build GT.M, and > it is a text to text transformation. How much data are we talking about ? > However, I don't really understand the problem with bootstrapping. > It only needs to be done once and that bootstrap has already been > accomplished. No it hasn't (as far as Debian is concerned) or else there would be an installable Debian package for bootstrapping GT.M. I might be wrong. If so, please point me to the DFSG compatible package I can install to either bootstrap a GT.M or a DFSG-compliantly valid GT.M package. The "problem" with bootstrapping is that Debian does not allow to use "foreign" binaries (that is, binaries not buildable on Debian) in order to build packages. > In my opinion, if you really want to eliminate the bootstrap, We/I don't want to eliminate it. We want to get it done because we have to if we want to have GT.M on Debian. > the obvious solution is to use awk or perl for the small > number of files involved. For example. That is one of the options I am trying to assess how complicated it would be. > Or, for the initial bootstrap, just take the generated C > files from an existing GT.M for the bootstrap. Since those *are* source code I wonder whether that might be compliant with DFSG. Anyone ? BTW: In case all this has already been solved in an existing, compliant Debian (pre-)package we would surely like to know about it ! Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20120130152529.ge2...@hermes.hilbert.loc
Re: [MoM] Packaging fis-get
On Mon, Jan 30, 2012 at 09:46:17AM -0500, Bhaskar, K.S wrote: > > In my opinion, if you really want to eliminate the bootstrap, the > obvious solution is to use awk or perl for the small number of files > involved. Or, for the initial bootstrap, just take the generated C > files from an existing GT.M for the bootstrap. Hmmm, this is actually a quite interesting hint. Could you please negotiate this issue with Luis. While we just got confirmation from ftpmaster that they are willing to accept the procedure of bootstrapping it might simplify things a lot if no binaries are involved in this process. So if you could sort this out with Luis I would really welcome this. Kind regards and greetings from Manchester Airport :-) 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/20120130151954.gh26...@an3as.eu
Re: [MoM] Packaging fis-get
On Mon, Jan 30, 2012 at 02:20:42PM +0100, Karsten Hilbert wrote: > - this presents a chicken-egg problem in that Debian does > not allow packages to be included without compiling them > from source Not really. In previous discussions (to lazy to search for this) we got confirmation from ftpmaster to accept this. So bootstrapping is not impossible in Debian. > - the easy way out would be if > > 1) there existed a Mumps compiler written in C/C++/Pascal/... > 2) which is compatible with the DFSG > 3) which can - however deficiently - compile GT.M > > So, is there ? Even if there would some from my perspective the need to package two different Mumps implementations to circumvent bootstrapping causes mor trouble than needed. It involves two problems: 1. Finding another Mumps implementation 2. Checking whether this really is bale to build GT.M Compared to only one problem (negotiating with ftpmaster) I'd regard your suggestion as harder to realise. 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/20120130151555.gg26...@an3as.eu
Re: [MoM] Packaging fis-get
On 01/30/2012 08:20 AM, Karsten Hilbert wrote: On Sun, Jan 29, 2012 at 06:14:29PM -0500, Bhaskar, K.S wrote: So, when I install fis-gtm 5.3-017g today and next week Debian delivers a package containing the code for 5.5-000 will there be a way for me to upgrade my database/M code ? If so, then I fail to see the problem with Debian providing the new GT.M version to me via a package ? And later providing me with a 5.6-002z package allowing me to run, say, /sbin/fis-gtm-upgrade [KSB] Yes, that's the general idea. But it's a little more complicated than that because, for example, you may want to build new shared libraries for the code, and occasionally other configuration files may need to be tweaked or extended. Absolutely. Just like with any other Debian package. Let me try to derive the most basic question again so we can perhaps find an answer: - VistA runs on Mumps. - GT.M provides a Mumps environment [KSB2] The last two statements are correct. - GT.M is written in Mumps and thusly needs to be compiled by a Mumps compiler - this presents a chicken-egg problem in that Debian does not allow packages to be included without compiling them from source [KSB2] GT.M is almost entirely written in C with a few small bits in assembler. Some utility programs are written in MUMPS. When building GT.M, some C source programs are generated from text files using a MUMPS program - this is where GT.M is used to build GT.M, and it is a text to text transformation. - the easy way out would be if 1) there existed a Mumps compiler written in C/C++/Pascal/... 2) which is compatible with the DFSG 3) which can - however deficiently - compile GT.M So, is there ? [KSB2] There are certainly other MUMPS implementations. I don't know how well those map DFSG guidelines and I don't know how well they might work to bootstrap GT.M. I can't use any of them because we have a policy of not touching any other MUMPS implementation so that all GT.M development is done in a clean room. But someone else who is interested certainly can look at them. However, I don't really understand the problem with bootstrapping. It only needs to be done once and that bootstrap has already been accomplished. So, we can now work on creating the real GT.M package. In my opinion, if you really want to eliminate the bootstrap, the obvious solution is to use awk or perl for the small number of files involved. Or, for the initial bootstrap, just take the generated C files from an existing GT.M for the bootstrap. Regards -- Bhaskar Karsten -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _ 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/4f26ad39@fisglobal.com
Re: [MoM] Packaging fis-get
On Sun, Jan 29, 2012 at 06:14:29PM -0500, Bhaskar, K.S wrote: > >So, when I install fis-gtm 5.3-017g today and next week > >Debian delivers a package containing the code for 5.5-000 > >will there be a way for me to upgrade my database/M code ? > >If so, then I fail to see the problem with Debian providing > >the new GT.M version to me via a package ? And later > >providing me with a 5.6-002z package allowing me to run, > >say, > > > > /sbin/fis-gtm-upgrade > > [KSB] Yes, that's the general idea. But it's a little more > complicated than that because, for example, you may want to build new > shared libraries for the code, and occasionally other configuration > files may need to be tweaked or extended. Absolutely. Just like with any other Debian package. Let me try to derive the most basic question again so we can perhaps find an answer: - VistA runs on Mumps. - GT.M provides a Mumps environment - GT.M is written in Mumps and thusly needs to be compiled by a Mumps compiler - this presents a chicken-egg problem in that Debian does not allow packages to be included without compiling them from source - the easy way out would be if 1) there existed a Mumps compiler written in C/C++/Pascal/... 2) which is compatible with the DFSG 3) which can - however deficiently - compile GT.M So, is there ? Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20120130132042.gb2...@hermes.hilbert.loc
