Re: Debian based live chemoinformatics CD?

[Dirk Eddelbuettel]

Egon,  

(and CCs to those who contributed to the thread already, as well as to Klaus
and Ian re the LCC aspects below)

On 17 November 2005 at 12:36, Egon Willighagen wrote:
| I've been thinking about live linux CDs to demo and easily setup a developers 
| environment for Java based chemoinformatics software. So I want to make a 
| custom CD with openbabel, CDK, JChemPaint, Jmol, pyMOL, xdrawchem, 
| kfile_chemical, etc, and as developers tools C++, eclipse, Blackdown Java (or 
| something like that).
| 
| I have no preference for Kubuntu/Knoppix or whatever, but do require KDE as 
| desktop (for kfile_chemical).
| 
| I know there are some some live CDs around, but would appreciate your ideas 
of 
| best practices for setting up such a live CD.

Quantian already has a clear focus on science / numerics / quant stuff,
contains the 1.4.2 Java JRE and is KDE-based --- so it would fit your needs.

I am hoping to have a new Quantian release (based on Knoppix 4.0.2) out in
the next little while and was thinking about Java support as I'd love to
have the JGR ide/gui/everything for R [http://stats.math.uni-augsburg.de/JGR]
on it. However, JGR requires Java 1.5 so this is a can of worms.  

Would you, or anybody else for that matter, be interested in helping with the
next Quantian release?  I am very much in favour of making things more
modular.  Morphix is one idea, the LCC is another (and Knoppix and Mepis have
joined there already).  It would be tremendous if we could have (large) core
parts like openMosix, Java, ... as pluggable modules.  Any interest?  How
could we get traction on that?

Regards, Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian based live chemoinformatics CD?

[Dirk Eddelbuettel]

On 17 November 2005 at 16:57, Michael Banck wrote:
| On Thu, Nov 17, 2005 at 09:45:23AM -0600, Dirk Eddelbuettel wrote:
|  Quantian already has a clear focus on science / numerics / quant stuff,
|  contains the 1.4.2 Java JRE and is KDE-based --- so it would fit your needs.
| When you say Java support, do you mean a free Java stack, or rather
| Sun's/Blackdown's java packages?

Both, in a way.  Historically, I followed Klaus Knopper's practice and kept
the Java 1.4 JRE he installed into Knoppix on for my Quantian derivative.

Now, what I read from time to time on planet.debian.org concerning progress
with Java in Debian seems rather encouraging, but I am not following it that
closely.  If the free stack was up for running Eclipse, I'd be all for it.
Would you be in a position to test / improve this for Quantian?

Regards, Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian based live chemoinformatics CD?

[Dirk Eddelbuettel]

On 18 November 2005 at 08:06, elijah wright wrote:
| 
|  Now, what I read from time to time on planet.debian.org concerning 
|  progress with Java in Debian seems rather encouraging, but I am not 
|  following it that closely.  If the free stack was up for running 
|  Eclipse, I'd be all for it. Would you be in a position to test / improve 
|  this for Quantian?
| 
| the current eclipse-in-main is built with GCJ, isn't it?

Indeed --- looks like we can tick that one off.  But recall that the thread
started with Egon wondering about JChemPaint and Jmol [ and Egon said in
private mail that these need Swing :-/ ], and that I had said that I'd like
to add JGR [ which needs Sun's 1.5 :-/ ].

Moreover, folks have long suggested [1] that Quantian ought to add 
ImageJ (http://rsb.info.nih.gov/ij)
and more recently
Weka  (http://www.cs.waikato.ac.nz/ml/weka)
GridWeka  (http://smi.ucd.ie/~rinat/weka/)

Does anybody know if these could run under free Java stacks?  I suspect they
don't so Quantian will probably have to continue to ship with non-free Java.

Dirk

[1] The todo list is at http://dirk.eddelbuettel.com/quantian/todo.wml 

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: good multivariate regression packages?

[Dirk Eddelbuettel]

On 25 November 2005 at 13:43, Maciej Kalisiak wrote:
| Hello,
| 
| Can anyone recommend any good packages for doing multivariate
| regression?  I'm trying to model a function over a 5D domain (i.e., f:
| R^5 - R).  If it has any bearing on the question, a cross-section of
| the function is shown in
|   http://www.dgp.toronto.edu/~mac/tmp/levelplot_disc=200_rad=0.3_k=5.png
| Other cross-sections look very similar, except that the shape is
| usually rotated.  The only other interesting thing about the data is
| that the samples never under-estimate the function (i.e., samples = fn
| + error, error = 0 always).

You didn't say anything about the functional form of your model. 

If the model is linear in its terms [ and it would still be linear if it was
just a sum of nonlinear functions, polynomials, ... ] then Octave will do
fine. Or Python with NumPy / SciPy.

That said, you probably should look at R as it provides a real environment
for statistical computing, modeling, visualization, estimation, inference,
simulation, ...  I think there's also a full blown R / CRAN mirror at U of T
but I've forgotten where it is hosted.

| Ideally I'm looking for a package that would have Python bindings, but
| this is not necessary.  The main criterion is that it give decent
| results with relatively medium effort, for someone relatively
| unfamiliar with regression methods (i.e., no hardcore manual tweaking,
| etc.).

Sure, R can be driven from Python via RPy. And

$ apt-get install python-rpy r-base

gets them both for you.

Greetings back to Ontario, and good luck,  Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Genetics Program

[Dirk Eddelbuettel]

On 7 December 2005 at 17:07, Christopher David Desjardins wrote:
| Hi-
| I am MSc student at the University of Alberta studying ecology.
| Recently I've decide to dive into population genetics and I am curious
| if there are any good genetics programs available for linux and debian
| in particular?

There's a ton in Debian in general:
[EMAIL PROTECTED]:~ apt-cache search bio | wc -l
186
[EMAIL PROTECTED]:~ apt-cache search genetic | wc -l
32

More generally, one place that has a few overview review article is the
Genome Canada / Canadian BioInformatics Help Desk Newsletter hosted at your
very own U of Alberta.  Bela Tiware has on overview of live distros here:
 http://gchelpdesk.ualberta.ca/news/03mar05/cbhd_news_03mar05.php#GearingUp
and Bela and I have an article about my Quantian distro here:
 http://gchelpdesk.ualberta.ca/news/30jun05/cbhd_news_30jun05.php#Quantian

The next Quantian release will have once again a large selection of tools
incl a complete set of BioConductor packages (that part is not in Debian) but
dozens of packages from Debian from the BioPython, BioPerl, BioAnything
area such as bioperl python-biopython blast2 clustalw clustalx seaview hmmer
and more.

Hope this helps,  Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Genetics Program

[Dirk Eddelbuettel]

On 8 December 2005 at 16:55, Andreas Tille wrote:
| On Thu, 8 Dec 2005, Dirk Eddelbuettel wrote:
| 
|  That ITP is officially dead. Action, if any, can be had around the pkg-bioc
|  project on alioth where we have some rough code to spew out hundreds of .deb
|  packages based on sources from both CRAN and BioC.
| 
| I just notice that I was actually talking about the Emboss suite
| (http://www.emboss.org/) and not bioconductor - but the situation seems
| to be similar (if not worse than bioconductor).

What is the story with emboss?  Couldn't find it for the currently ongoing
preparations of the next Quantian update. Are there binaries somewhere?
 
|  [ It is also unclear, at least to me, whether adding some 120 (for
|  BioC) packages (or 600-some in the case of CRAN) to Debian en bloc is wise. 
]
|  But I want the apt-get'ability of CRAN and BioC, maybe from outside 
archives.
| 
| If you and probably other people as well who are interested in biological
| research I see no reason to keep these packages outside the official Debian

That is exactly the rub: I am not a BioC user, and I can't be the default
maintainer for another few dozen (or dozen squared) packages.

| archive.  I know that Debian-Med has at least one effect: We are winning
| users in the field of biology and medicine and we are winning them because
| we are at least promising to care for them - even if we proceed slowly.

Yes, and hopefully one day we'll be able to lean on someone with the need and
the know to coordinate that.

|  Now, to make this a tad more actionable: Would someone want to make revival
|  of this an item for the suggested Estremedura workshops and get some people
|  in the same room for two or three days to push this further?  Anybody care 
to
|  run with that idea and organise it?
| 
| Extremadura workshop about R?  I guess this is a great idea!  Even if I
| will not take part in one of the first announced meetings I hope to be
| there in at least one at the end of the year.

Yes, it would be excellent to get a few interested people together to work on
this. 

Cheers, Dirk


-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Genetics Program

[Dirk Eddelbuettel]

On 8 December 2005 at 18:09, Steffen Moeller wrote:
|  What is the story with emboss?  Couldn't find it for the currently ongoing
|  preparations of the next Quantian update. Are there binaries somewhere?
| EMBOSS would be lovely to have, indeed. 

Go and package it, I'm sure Andreas will sponsor it for you :)

|  That is exactly the rub: I am not a BioC user, and I can't be the default
|  maintainer for another few dozen (or dozen squared) packages.
| Could we arrange a BioC repository for Alioth?

Well we *do* have one in pkg-bioc [ which has refocussed on pkg-CRAN and
BioC but not been renamed ].

|  Yes, and hopefully one day we'll be able to lean on someone with the need
|  and the know to coordinate that.
| 
| It would help in my understanding if not every maintainer of a package would 
| be required to become a full DD for the submission of updates. The acceptance 
| as a DD is quite a hurdle. 

Just as you can't be partially pregnant, you can't have packages partially
inside Debian.  If you are serious about contributing, join so that you can
upload your packages so that they become fully-fledged packages, get
autobuilt, ported, get BTS coverage etc pp

Sponsoring, IMHO, doesn't scale to more than a few packages. I'd be happy to
be proven wrong, but as our recent email exchange showed, I may have
different expectations about QA for Debian packages than you :)  Seriously,
the tediousness of becoming a DD is known but please just stick it out. We
could use your help.

| I have never thought of it, but for BioC it should be possible to have such 
| events sponsored by some pharma directly, be it as Extremadura or elsewhe(re|
| n). Maybe this would be a question for the BioC mailing list, I'll crosscheck 
| with the people I know.

I'd be more interested if the focus was on both CRAN and BioC. Pharma money
may come with strings attached. That said, let us know what you find out. The
more the merrier.

But we *do* have a standing offer to host Debian workshops in Spain. Why
don't we go for it?

Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Packaging and Maintaining

[Dirk Eddelbuettel]

Chris,

On 8 December 2005 at 10:40, Christopher David Desjardins wrote:
| Hi-
| I am just starting to learn how to create and maintain debian packages.
| I would like to help in package up some of these programs that we've
| been discussing that might need some one to package them.  I would be
| especially interesting in package genetics software, QGIS, or R.  Any
| suggestions for packages that need to be maintained in particular would
| be a great starting spot for me and would give me something to practice
| on.  

The pkg-bioc project on Alioth would be a starting point. Packaging CRAN and
BioC is easy and standardised, hence our aim of fully automating it. If you
know Perl, you could dive right in, but it may help to download some R / CRAN
packages first to see the structure, try debianising a local package or two
and then play with the script.  You need to get yourself an alioth id so that
I can add you to the project.

Andreas' URL to the Debian Med project also had a lot of bio/generics
pointers.

Hope this helps, Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [pkg-bioc] Re: Genetics Program

[Dirk Eddelbuettel]

On 8 December 2005 at 18:03, Andreas Tille wrote:
| Are you looking for biological software in and outside Debian in general?
| I hope you noticed
| 
|  http://www.debian.org/devel/debian-med/microbio

Nice page(s that I was in fact unaware of. I only need to know your med-*
meta packages :)

Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [pkg-bioc] Re: Genetics Program

[Dirk Eddelbuettel]

Replying to both Steffen and Rafael here:

On 9 December 2005 at 10:41, Steffen Moeller wrote:
|  | Could we arrange a BioC repository for Alioth?
| 
|  Well we *do* have one in pkg-bioc [ which has refocussed on pkg-CRAN and
|  BioC but not been renamed ].
| Hm. We store the script there, but it was not yet decided if it was ok to 
| upload the .debs, so my understanding.

I am hesitant because I would not want packages of dubious quality to give a
bad first impression.  

Undoubtedly many of the CRAN/BioC packages would build and work just fine.
But the problem is that a fair number require hand-holding to, say, properly
translate CRAN dependencies into Debian dependencies, make sure those are all
present and installable, do some extra work to prevent building (for the
Windows only packages), do follow-up work (CIGwithR wants interaction with
webserver, gnomeGui ships as a package but is only a glade file that gets
installed somewhere else, RScaLAPACK needs a mess of library arrangements
(or, rather, an upstream autoconf patch) etc pp.  It should *really* work,
not *just work*.

So I'd rather test that at a lower key site for a bit and prove that we are
able to cope with it before unleashing it more broadly.

| From my perception the main work towards Debian quality is on the upstream 
| packages to document themselves better. My personal /etc/apt/sources.list

I could not disagree more. Debian is about doing the best we can with the
given packages: doing the best possible integration, the smoothest and most
coherence total package. I like blaming upstream just like everyone else :)
but seriously, it is about how we can value to the mix.  


On 10 December 2005 at 14:31, Rafael Laboissiere wrote:
|  Could we arrange a BioC repository for Alioth?
| 
| This is a no-brainer and any member of the pkg-bioc group should be able
| to upload files into the directory 
| /org/alioth.debian.org/chroot/home/groups/pkg-bioc/htdocs/something at
| the alioth.debian.org server.  The repository URL would then be
| http://pkg-bioc.alioth.debian.org/something.

Yes, but as I tried to say above, it is about a lot more that just throwing
the files out. You are keeping pretty buys with a two dozen (albeit more
complicated individually) Octave package, and we are talking 600 plus
packages for CRAN and BioC.

I would not like 600 packages to rot there.

| I see that the /org partition at alioth.debian.org has still 34 Gb free.
| I would though ask the Alioth admin people before setting up the
| repository.  We could also automate the creation of the repository
| through a cron job, although I guess that there will be limitations on
| using alioth.d.o's CPU time.
| 
| I can help you in setting this up, if you wish.  Drop me a note.

We would certainly like your help on infrastructure. I really like how the
Octave project at Alioth is set up. 

But I think we need to work a few more details out before we charge ahead. I
may be in the minority here and don't mean to block or veto this, but who
exactly would do the work?  You have your hands-full with Octave, Steffen
seems busy with his dozen plus packages, I have Quantian plus a few dozen
packages --- so who is going to run this? It will take one or two hours of
daily hand-holding.

Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ubuntu-science

[Dirk Eddelbuettel]

On 7 January 2006 at 18:16, Daniel Leidert wrote:
| Am Freitag, den 06.01.2006, 23:22 -0800 schrieb Jordan Mantha:
|  I am 
|  encouraging the MOTUScience team members to at least email this list 
|  when a new science package has been added to Ubuntu so that we don't get 
|  a lot of duplication of work.
| 
| You see the duplicate of work? Debian user or maintainers of science
| package have to remember to send mails to the Ubuntu lists and the
| Ubuntu guys have to do the same and send mails to the Debian lists.

I am with you. I am still confused about this whole thing:

-- On the one hand Ubuntu/Kubuntu is a well put together distro and I run
   Kubuntu on a few machines and like it. I happily recommend it, and its
   polish and coherence make it really quite pleasant. I only use it on 'use
   only' non-development machines.

-- On the other hand as a maintainer (of currently 72 packages), I am
   _appalled_ and _shocked_ by the lack of feedback from Ubuntu to Debian --
   at least as far as I can see. There was a thread on debian-planet a while
   that mentioned Ubuntu bug archive. Sure enough, there were patches to
   (though in my case only a few) packages of mine. Nobody ever bothered
   to let me know, yet at the same time Ubuntu is happy to take advantage of
   the work I've been doing here for now over a decade of diligently
   maintaining my set of packages. 

-- Lastly as the one behind Quantian, the to my knowledge single largest
   collection of scientific / numerical / quantitative apps in one
   ready-to-run place, I'd love to pull the two resources in and get, say,
   the more polished desktop experience and menu organisation of (K)Ubuntu
   back into Debian / Knoppix / Quantian, and would also love to pull some of
   the additional packages in.  But I am
 * still puzzled about the binary interchangeability, or lack thereof,
   between Ubuntu and Debian
 * confused as to why one would want to insert a package into Ubuntu
   but not Debian (other than the needing a DD sponsor reason).

I really don't want to be confrontational, or start another useless flame
war. But given Debian and debian-science, how can we achieve the best
outcomes with the least amount of duplication and waste?

Thoughts or comments?

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

New Quantian release 0.7.9.2

[Dirk Eddelbuettel]

[ Fellow debian-science folks,

  I hope this is not considered off-topic for the list: 

  A new Quantian release was just announced, and it contains even more 
  packages than before.  This release should contain everything good and
  worthy from the math and science sections, but as I cannot keep up all the
  good work,  I would welcome feedback, suggestions or 'guest editors' 
  contributions to ensure different areas are well covered.
  
  Feedback welcome, but preferably on the quantian-general lists (which
  requires subscriptions to keep the spammers out).

  The original announcement is below. I also welcome careful forwarding
  to other audiences or communities I may not reach.

  --  Thanks,  Dirk ]


(Please see note [1] below regarding recipients for this posting. Thanks!)


Executive Summary: 

Quantian 0.7.9.2 is the second Quantian release based on Knoppix 4.0.2.
Quantian adds hundreds of scientific / numeric packages, as well as the
an openMosix enabled 2.4.27 kernel, to the cdrom version of Knoppix. 
Version 0.7.9.2 ships as one compressed iso file of 2.7gb that is

Relative to the previous release 0.7.9.1, several small bugs have been 
fixed, Sun's Java 1.5.0 SDK has been added along with several Java-based
applications (ImageJ, Weka, JGR, Mondrian), several other applications
have been added, yet more R packages from CRAN and BioC are included and
a few other packages have been updated.

Quantian now contains over 2550 Debian packages, over 870 packages
for R and a few extra applications.

Quantian comes as one bootable dvd iso of 2.85 gb (compressed) with
over 7.6 gb (uncompressed) of software of interest to quantitative 
analysists, scientists, researchers or students.


Announcing Quantian release 0.7.9.2
===


I   What is it?

Quantian is a remastering of Knoppix, the self-configuring and directly
bootable cdrom/dvd that turns any pc or laptop into a full-featured Linux
workstation, and (parts of) clusterKnoppix, which adds support for
openMosix-based  cluster computing. However, Quantian differs from
Knoppix by having a particular focus on quantitative, numerical or 
scientific applications, and hence adds a very large set of programs of
interest to applied or theoretical workers in quantitative or data-driven
fields to the solid base provided by Knoppix..  

See http://dirk.eddelbuettel.com/quantian.html for more details.


II What Quantian highlights should I care about ?

o Second release based on Knoppix 4.0.2: Derived from the cdrom version of
  Knoppix, Quantian utilises the unionfs setup of Knoppix to combine two
  compressed loop images for a total of 2.85 gb (from two files of 1.66 gb
  and 1.19 gb) corresponding to over 7.6 gb of software.

o KDE 3.4/3.5, Kernel 2.6.12; added backport of kernel 2.4.27 with
  openMosix patch for continued openMosix support including unionfs
  support (that was missing in 0.7.9.1)

o Some highlights in 0.7.9.2 are

  - Java support via the 'Java 1.5.0' SDK from Sun, installed via
the packages from www.debian-unofficial.org; this allowed us to
add ImageJ, Weka, Mondrian and JGR.
  
  - some other packages that were added: celestia, cervisia, gcj,
gnuhtml2latex, inkscape, octplot, oprofile, prospect, praat, rserve,
wxmaxima, xalan, (x)orsa as well as many library additions/upgrades

  - even more complete R support with 877 packages (25 from 'core R',
another 76 from Debian packages, and 779 directly installed from CRAN
and BioConductor, covering over 99% of all packages at CRAN and
BioConductor [ not counting a handful of windows-only CRAN packages]
for complete coverage as of 25 Feb 2006), ESS editing in Emacs /
XEmacs, GGobi visualization, Rpad webinterface, the award winning JGR
'Java GUI for R', RSPerl, Rserve, an early release of the RKward GUI
and more.

  - continued strong bioinformatics/biology support:
BioConductor, arb, biofox, bioperl, biopython, blast2, boxshade,
bugsx, clustalw, fastdnaml, fastlink, garlic, gromacs, hmmer, loki,
mipe, molphy, muscle, ncbi, phylip, rasmol, readseq, seaview,
t-coffee, textopo, ImageJ, and more;

  - continued strong mathematics / computational algrebra support: axiom,
blacs, calc, euler, gap, giac, mathomatic, maxima, pari, scalapack,
scilab, texmacs, yacas, yorick;

  - continued strong visualization / graphics support: dx, garlic, gdpc,
gnuplot, grace, grass, gri, illuminator, kst, labplot, mayavi,
matplot, proj, plplot, plotmtv, rasmol, starplot, vtk, xd3d, xgraph,
ygraph;  
 
  - large number of programming and scripting languages, editors, 
debuggers and libraries;

  - excellent latex support with auctex, lyx, kile, 

Re: alternatives to gnuplot ?

[Dirk Eddelbuettel]

On 6 April 2006 at 01:01, Gregor Gorjanc wrote:
| Bill Allombert wrote:
|  I am looking for a GNU GPL-compatibly licensed alternative to gnuplot,
|  preferably packaged in Debian.
[...]
|
| http://www.r-project.org

Seconded, though it may not be for the faint of heart. R is much, much_ more
general and powerful than GNUplot.  Programming with Data is the operative
term here.  But just for graphs of all varieties, you could do worse.

A very nice site with numerous examples, incl their R code, is at

http://addictedtor.free.fr/graphiques/index.php

Amicalement, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: alternatives to gnuplot ?

[Dirk Eddelbuettel]

On 6 April 2006 at 15:24, [EMAIL PROTECTED] wrote:
| What we are missing is a libified gnuplot.

The Gnome guys once had a project call guppy (or something like it ...)  but
it died many years ago. GNU had plotutils, but that's not quite there either.

It has becomes a lot easier to embed R with recent versions (as the API is
now more cleanly defined) so this _may_ be a route for someone with some
spare time -- R has a variety of existing devices (all the usual png, jpeg,
pdf, pdf, ...) as well as everything else R itself has, plus the 600+ add-on
packages at CRAN (http://cran.r-project.org) and its mirrors.  

GTk2 is now available from R via the RGtk2 (see http://www.ggobi.org/RGtk2
and my blog for one early .deb; I have a current one and intend to upload it
soon) so there may be synergies.

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

FTBFS due to gfortran

[Dirk Eddelbuettel]

deb-science'rs,

Anybody here who could help me with a Fortran problem? 

I cannot compil one (old) routine in the source package fmultivar with
gfortran:

[EMAIL PROTECTED]:~/src/debian/CRAN/fMultivar-221.10065/src$ gfortran -c 
46C-OutlierDetection.f 
[...]
 In file 46C-OutlierDetection.f:79

18GOTO (21,22,23,24,25), KSKIP  
  2
Error: Label at (1) is not in the same block as the GOTO statement at (2)
 In file 46C-OutlierDetection.f:113

25  SUMK=SUMK+FBL   
 1
 In file 46C-OutlierDetection.f:79
[...]

I fudged the original bug (#369003) in debian/rules by compiling this file
only with f2c, but as two other packages depend on fmultivar (binary:
r-cran-fmultivar) I now seem to have hit a FTBFS (#369508) on amd64 for one
of the users of r-cran-fmultivar even though it all works out in pbuilder on
my i386.  Upstream, while notified, has been silent so far ...

Help would be appreciated. 

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: FTBFS due to gfortran

[Dirk Eddelbuettel]

Hi Kevin,

On 2 June 2006 at 11:41, Kevin B. McCarty wrote:
| Hi Dirk,
| 
| On 5/31/06, Dirk Eddelbuettel [EMAIL PROTECTED] wrote:
| 
|  deb-science'rs,
| 
|  Anybody here who could help me with a Fortran problem?
| 
|  I cannot compil one (old) routine in the source package fmultivar with
|  gfortran:
| 
|  [EMAIL PROTECTED]:~/src/debian/CRAN/fMultivar-221.10065/src$ gfortran -c 
46C-OutlierDetection.f
|  [...]
|   In file 46C-OutlierDetection.f:79
| 
|  18GOTO (21,22,23,24,25), KSKIP
|2
|  Error: Label at (1) is not in the same block as the GOTO statement at (2)
|   In file 46C-OutlierDetection.f:113
| 
|  25  SUMK=SUMK+FBL
|   1
|   In file 46C-OutlierDetection.f:79
|  [...]

[ I now learned that this file, as well as the R routine calling it, had been
removed from the upstream sources right after I took the 'ready for release'
tarballs.  I have now made a new upload of fMultivar with the updated
tarball; this seems to have auto-built fine everywhere (modulo systems that
hadn't yet built the new R also uploaded yesterday).  In particular, amd64
built it. Good. ]

[ I also learned that gfortran-4.1 compiles the file. Also good. ]

|  I fudged the original bug (#369003) in debian/rules by compiling this file
|  only with f2c, but as two other packages depend on fmultivar (binary:
|  r-cran-fmultivar) I now seem to have hit a FTBFS (#369508) on amd64 for one
|  of the users of r-cran-fmultivar even though it all works out in pbuilder on
|  my i386.  Upstream, while notified, has been silent so far ...
| 
|  Help would be appreciated.
| 
| It's possible that the FTBFS is due to the different ABIs of code
| created with f2c + gcc (as well as g77) versus gfortran.  As I
| understand it, in particular functions that return single-precision

Yes, I generally try to move away from f2c.  I used to use it for Octave and
R, mostly on m68k and arm.  R builds everywhere with g77, and now with
gfortran. 
| REAL and COMPLEX values are affected.  See the info files for g77 and
| gfortran (regarding the -fno-f2c and -ff2c options).  From my
| experience, at least the ABI change for REAL-returning functions does
| not really cause problems for most architectures, but amd64 is
| particularly sensitive to it for some reason - see
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15397
| 
| Is there a reason it's necessary for you to use gfortran instead of
| g77?  IMO it would be best for the project to switch from g77 to

As I understand it, gcc-4.0 is the default compiler, and gcc-4.1 will be the
default compiler soon. Unless I'm mistaken, neither one provides g77.  Sp
gfortran it is by default.  Or do I have that wrong?

| gfortran in a single coordinated transition, as with the g++ ABI
| changes, in order to minimize ABI incompatibilities between
| FORTRAN-based libraries.  I commented on this at one point,
| http://lists.debian.org/debian-science/2005/09/msg00071.html
| but my email received relatively little attention.

Sort-of shows that few DDer care about Fortran ...

Thanks for the follow-up,  Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: GUI for R

[Dirk Eddelbuettel]

[ resending with 8-bit clean mail header, and one fix below --edd ]

On 7 October 2006 at 15:44, Janno Tuulik wrote:
| Hei Cristiano,
| 
| Take a look at RKWard (http://rkward.sourceforge.net) 

I would not (yet ?) recommend RKWard as it is in very stages and has fairly
incomplete coverage of R.

| (http://rosuda.org/JGR/). Unfortunately, I have never tried to install those 
| on sarge. 

The excellent JGR is a very good choice.  As Janno said, it may be tricky on
stable.  It just became a lot easier to install on unstable (and I still have
to post a short writeup) using R 2.4.0 and its new 'R CMD javareconf' which
can update R's knowledge of where your Java installation is. 

Unfortunately, JGR is still somewhat outside Debian as it wants Sun's Java
JDK so I don't think I'll ever package it directly.  Now, if someone wanted
to outside of Debian ...  In fact, the CRAN maintainers mention that
idea. Maybe one day.

| On Saturday 07 October 2006 14:11, Cristiano Nattèro wrote:
|  Hello everybody,
| 
| I'm trying to use GNU R on a debian stable but I didn't manage to
|  make any GUI work. Then I saw that:
| 
| 
|  $ apt-cache show r-gnome
|  snip
|  As of R 2.1.0, this interface is no longer provided with the upstream
|  sources. As such, this package is now an empty stub that will be removed
|  in a subsequent revision of the Debian package.
|  ...
| 
| 
| Can you help me, please? I'm not keen on Gnome, any working GUI would
|  be fine.

As I tried to say here, the Gnome gui for R is no longer included upstream
and hence no longer packages for Debian.

The code does exist, though, on CRAN, so you could just fire up R and say

install.packages(gnomeGUI)

but note that you will have to take care of all the Build-Depends.
Alternatively, download the tarball yourself outside of R from

   http://cran.r-project.org/src/contrib/gnomeGUI_2.3.0-3.tar.gz

and say

   $ sudo R CMD INSTALL gnomeGUI_2.3.0-3.tar.gz

All that said, this (old) Gnome GUI is not all that powerful. JGR is current,
maintained, and offers a number of things standard R hasn't.

|  (BTW, is this the right place? If not where can I ask?)

It really isn't all that on-topic here.  We are running a small Debian
mailing list called r-sig-debian off the R mail server as well. That is
probably the most topical list and I'll CC it now.

Hope this helps,  Dirk (wearing his R maintainer hat)

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison

Re: [R-sig-Debian] GUI for R

[Dirk Eddelbuettel]

On 9 October 2006 at 14:11, Gregor Gorjanc wrote:
| Tyler Smith wrote:
|  If you are spending any significant time working in R I would highly
|  recommend emacs with ESS. Both are apt-gettable for stable, testing and
[...]
| I also agree with Tyler. If you do not know Emacs it might be a bit of
| overkill from the beginning, however it does pay-off in long term.
| Wherever I go I really miss emacs and lately also ESS.

Yes and yes but not that this is 

a) now fairly clearly off-topic on debian-science, and 

b) covered in the R FAQ as my favourite Q and A:

   6.2 Should I run R from within Emacs?
   =

   Yes, _definitely_. []

   where all three questions in section 6 are about R and Emacs.

Cheers, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: GUI for R

[Dirk Eddelbuettel]

Hi Egon,

On 7 October 2006 at 18:56, Egon Willighagen wrote:
| On Saturday 07 October 2006 17:07, Dirk Eddelbuettel wrote:
|  The excellent JGR is a very good choice.  As Janno said, it may be tricky
|  on stable.  It just became a lot easier to install on unstable (and I still
|  have to post a short writeup) using R 2.4.0 and its new 'R CMD javareconf'
|  which can update R's knowledge of where your Java installation is.
| 
|  Unfortunately, JGR is still somewhat outside Debian as it wants Sun's Java
|  JDK so I don't think I'll ever package it directly.  Now, if someone wanted
|  to outside of Debian ...  In fact, the CRAN maintainers mention that
|  idea. Maybe one day.
| 
| Did you try it with JamVM/Classpath? I will have a go at that in running JGR, 
| and report problems with the Classpath team.

I do not use Java myself, so I wouldn't be the one to try this.  It would be
nice if someone like you with R and Java clues coud try it.  I honestly do
not know what is involved but I have the suspicion that it is no cake walk.  

That said, Simon and Markus, the upstream authors, would certainly help. As
they develop mainly on OS X, their priorities and toolchain may not be
exactly like ours, but I do nudge them every now and then to try and debug on
Debian (as we did just before R 2.4.0 leading to the JGR_1.4-11 revision).

Dirk


-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: math package maintainer for Debian

[Dirk Eddelbuettel]

On 14 October 2006 at 14:30, David Joyner wrote:
|  On 14 October 2006 at 13:00, David Joyner wrote:
|  | I am part of a development team for a
|  | GPL'd math software package called SAGE. We could like
|  | to ask a question of a contact person from the Debian team who
|  | deals with math packages. If such a person is reading this list
|  | (or if someone on this list knows of such a person), please
[...]
| A key component of Singular is now GPL'd, which means
| that Singular could now be included in Debian.  Serious license
[...]
| We are also hopeful that Debian will consider distributing not
| just Singular but SAGE as a Debian package. At this point though, we
| are just requesting that the Debian team reconsider Singular.

Very encouraging news, but note that as Debian is fairly decentralised, it
would take one or more individuals to actually express an interest in
singular and to go ahead and package and maintainit.  The 'formal' way to
suggest that is to file a so-called 'wnpp' (for 'work needed and prospective
packages') bug report requesting a package.  And going by the 'requested'
list at

http://www.debian.org/devel/wnpp/requested

it appears that has in fact happened two months ago: see   

http://bugs.debian.org/383515

But as I do not see singular in 

http://www.debian.org/devel/wnpp/being_packaged

so it would appear that your call for volunteers here is justified.  Package
adoption is unpredictable -- it may, or may not happen, during any given time
span.  So sorry -- we simply do not have the bandwidth to promise you a
singular package for any given timeline.  Maybe one of computer-algebra
maintainers will jump at it ...

As for SAGE as a whole, it may be best to directly talk to the package
maintainers that cover whatever pieces you also use in SGAE.  I for one would
be happy to help you where I can with my GNU GSL package if you'd need any
changes (and provided those changes do not have side-effects for other users,
of course).

Thanks, Dirk


-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Revisiting batch/queue systems: slurm and munge

[Dirk Eddelbuettel]

Hi all,

Last August, I started a short discussion here regarding batch management /
queue / scheduler / resource managment software for cluster computing. I
already mentioned slumrm [1] and munge [2].  The conclusion then was
unsatisfying -- we don't have anything in Debian.  At the time, I was unaware
of Gennaro Oliva's mail to debian-mentors [3] and his package snapshots.

To cut a long story short, I built two crude packages today I would like to
offer for co-maintenance. Given my existing 80-some Debian packages, I really
shouldn't take any more on.  The crude packages will do for work, so if
nobody has time or energy to pick them up ... I won't push the issue either.
Because the packages deal with resources, authentication, ... they are not
exactly trivial and would need some tender love and care to be done real
well.  They mostly autoconf fine, esp munge. Slurm needs a replacement
scripts for /etc/init.d, a few contributed manual pages but nothing major.

That said, I think it would be worth it.  I am quite impressed with slurm.
For a quick overview, see the website [1] and e.g. the recent presentation
from 2006 [4] .  Slurm is under active development and just released 1.2.1,
it now even has a nice little gtk-based gui. [ Munge is used by slurm and is
a smaller/simpler package. It already detects Debian in its init.d script and
does The Right Thing. ]

Gennaro: Are you still interested in working on this?  I could possibly act
as mentor and 'final compiler / uploader'.

Anybody else working on clusters who needs a DFSG-free resource manager /
scheduler?

Dirk

[1] http://www.llnl.gov/linux/slurm/
[2] http://home.gna.org/munge/ -- but really also from llnl.gov
[3] http://lists.debian.org/debian-mentors/2006/05/msg00020.html
[4] http://www.llnl.gov/linux/slurm/slurm_design.pdf

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Revisiting batch/queue systems: slurm and munge

[Dirk Eddelbuettel]

Hi Gennaro,

On 7 March 2007 at 11:34, [EMAIL PROTECTED] wrote:
| Hi Dirk,
| sorry for quoting all your mail, I do it for Josselin convenience. If
| you check the slurm-llnl ITP Bug report logs (351688) [Bug] you
| will see that Joss has offered himself for sponsorship.

Ahh, I missed that. I saw Thijs response to your initial RFS, but not the
ITP.  Cool.

| Anyway I'm still waiting for some feedback and help about my last
| package version (especially about the /dev/random problem) and I don't
| know if Joss is still interested in working on this.

Let's take it off-line then. I used /dev/urandom in postinst for munge but
then realized that you don't really need or want this as the crypto key is
generated only once and then copied across the cluster.
| 
| In general any comment about my package are welcome. At the moment I
| have uploaded on my repository the version I'm using, but I can provide
| an update version of the package soon.

I'll have a look and maybe update my installation to your versions.

| I'm happily working with munge and slurm on my debian cluster and
| I would like to see it uploaded to the main distribution and to
| contribute to this. Thanks for your interest

Same here. Thanks for your work on this -- we'll have slurm and munge in
Debian before long.

Dirk

| 
| Gennaro
| 
| [Bug] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351688
| 
| On Tue, Mar 06, 2007 at 08:40:10PM -0600, Dirk Eddelbuettel wrote:
|  
|  Hi all,
|  
|  Last August, I started a short discussion here regarding batch management /
|  queue / scheduler / resource managment software for cluster computing. I
|  already mentioned slumrm [1] and munge [2].  The conclusion then was
|  unsatisfying -- we don't have anything in Debian.  At the time, I was 
unaware
|  of Gennaro Oliva's mail to debian-mentors [3] and his package snapshots.
|  
|  To cut a long story short, I built two crude packages today I would like to
|  offer for co-maintenance. Given my existing 80-some Debian packages, I 
really
|  shouldn't take any more on.  The crude packages will do for work, so if
|  nobody has time or energy to pick them up ... I won't push the issue either.
|  Because the packages deal with resources, authentication, ... they are not
|  exactly trivial and would need some tender love and care to be done real
|  well.  They mostly autoconf fine, esp munge. Slurm needs a replacement
|  scripts for /etc/init.d, a few contributed manual pages but nothing major.
|  
|  That said, I think it would be worth it.  I am quite impressed with slurm.
|  For a quick overview, see the website [1] and e.g. the recent presentation
|  from 2006 [4] .  Slurm is under active development and just released 1.2.1,
|  it now even has a nice little gtk-based gui. [ Munge is used by slurm and is
|  a smaller/simpler package. It already detects Debian in its init.d script 
and
|  does The Right Thing. ]
|  
|  Gennaro: Are you still interested in working on this?  I could possibly act
|  as mentor and 'final compiler / uploader'.
|  
|  Anybody else working on clusters who needs a DFSG-free resource manager /
|  scheduler?
|  
|  Dirk
|  
|  [1] http://www.llnl.gov/linux/slurm/
|  [2] http://home.gna.org/munge/ -- but really also from llnl.gov
|  [3] http://lists.debian.org/debian-mentors/2006/05/msg00020.html
|  [4] http://www.llnl.gov/linux/slurm/slurm_design.pdf
|  
|  -- 
|  Hell, there are no rules here - we're trying to accomplish something. 
|-- Thomas A. Edison

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Batch systems: Torque, SLURM, other?

[Dirk Eddelbuettel]

Hi Manuel,

On 15 May 2007 at 13:11, Manuel Prinz wrote:
| Hi everyone,
| 
| I've to administrate a small cluster and I'm intersted in your opinion
| or experience with the resource managers/batch systems you use.
| 
| ATM, there's Torque installed, and I'm not too happy with it, especially
| with the documentation. I've found a thread on debian-science about
| packaging SLURM [1] and had a look at it, and at a first glance it seems
| that more people care about it then Torque. But that may be wrong.
| 
| The cluster is new, so there would be no problem with switching to a
| different resource manager. Our requirements are quite low, a default
| FIFO scheduler will do. (The only thing really needed is support of
| Prologue/Epiloque scripting, addressing single cores and two batch
| queues.)
| 
| I've the impression that SLURM will be maintained more actively and
| during a longer time in the future. The better documentation probably
| will ease up things when I run into trouble or the requirements change.
| Torque's documentation is more like a tutorial without much explanation
| of what's happening and I don't feel very comfortable with this.
| 
| So, I'd be thankful if you would share you opinion with me! Thanks in
| advance!

Following on a similar thread or two we had here, I have been sponsoring
Gennaro Oliva who has been working on munge [ == authentication service used
by slurm ] packages which we _almost_ got into Debian unstable.  The
ftpmaster noticed that another copyright line was missing for two files
internal to munge. 

Gennaro has also packaged slurm as slurm-llnl [ Debian already has a slurm
package ] but despite my prodding, has not released anything based on slurm
1.2.* as he is working on a configuration script -- and that's hard.

I am trying to come to terms with slurm and lam myself at work, so I am doing
some testing there too.

Big summary: Yes, these should be forthcoming.

Cheers, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: checkinstall lacking on stable

[Dirk Eddelbuettel]

On 23 June 2007 at 09:31, Ross Boylan wrote:
| On Fri, 2007-06-22 at 00:32 -0700, Francesco Pietra wrote:
|  I am now at such cases for amd64 (dual core opterons)
|  with OpenMPI (a parallelization support) and Amber (a
|  molecular dynamics package), which I wish to compile
|  with my installed intel fortran and c. 
| I can't help with your problem, but your mail raises a couple of
| questions.  I heard a couple years ago that Intel had made some changes
| to their compilers that made them not work (or maybe not work well) with
| chips from other vendors.  Is that information inaccurate?
| 
| Also, some of us are working on getting R and OpenMPI working together.
| If anyone has done that, or would like to help, just speak up.

Yes, I made a first stab and have something really rudimentary.

But it has been moved 'back down the queue' as I (as part of the pkg-openmpi
team on Alioth) am trying to get an all new, all shiny OpenMPI into
Debian. Maybe this weekend.  If and when it happens, I *will* post in
debian-science (and possibly debian-devel) to reach other MPI maintainers and
users.

And yes, once we have a properly maintained and non-buggy OpenMPI package, it
will be worthwhile coordinating with other the MPI implementation packages,
and updating the packages using MPI (and particularly lam) such as Rmpi.  

Help would be welcome on any and all of these projects. For the R/MPI
intersection, I am currently the only worker bee so this is bound to be
slow. 

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: libgsl stuck, can anybody help?

[Dirk Eddelbuettel]

Hi Rudi,

This is probably a question for debian-release or debian-devel and not
debian-science ...

I'll try to answer this from my vantage point, and I think that vorlon may
correct any crass inaccurracies I state here.

On 5 September 2007 at 06:07, Rudi Cilibrasi wrote:
| Hi everybody,
| 
| I have been trying to do a new release of libcomplearn, a package I
| have had in Debian but recently has fallen out of date because it is
| stuck behind the dependent libgsl package.  Unfortunately, the libgsl
| package has been stuck for 55 days now [1]:

1. gsl builds everywhere and has been built everywhere (see the buildd page
   hanging off the QA link you give in [1])

2. There are no 'excuses' (http://qa.debian.org/excuses.php?package=gsl)

3. And the winning answer is as usual provided by 'why is package X not in
   testing yet': http://bjorn.haxx.se/debian/testing.pl?package=gsl

   Checking gsl

   trying to update gsl from 1.9-3 to 1.9-5 (candidate is 55 days old) 

   Updating gsl makes 39 depending packages uninstallable on i386: adun.app,
   asymptote, bogofilter, bogofilter-bdb, bogofilter-qdbm, bogofilter-sqlite,
   dieharder, gmsh, gpiv, gpivtools, kst, kst-plugins, libgpiv2, libgpiv2-dev,
   libgsl-ruby, libgsl-ruby-doc, libgsl-ruby1.8, libmeep-dev, libmeep-mpi-dev,
   libmeep-mpi1, libmeep1, libocamlgsl-ocaml, libocamlgsl-ocaml-dev,
   liborsa0-dev, liborsa0c2a, meep, meep-mpi, orpie, pd-pdp, pdl, pspp, qtiplot,
   slang-gsl, snd, snd-gtk, xorsa, yacas, yacas-proteus, yorick-yeti-gsl 

   Updating gsl makes 2 non-depending packages uninstallable on i386:
   libgimp-perl, med-bio

This is what we call a library transition, and it doesn't work piecemeal. So
if you feel energetic, try to figure out what the issue is with those 39 + 2
packages listed above, and offer help on those.  
 
Delays happen.  We have many libaries, and many interdependencies.

Sorry, 

Dirk
(gsl maintainer)

| I have tried emailing a few people, but have not had any luck figuring
| out how to help get libgsl unstuck.  I have also not found any
| (certain) evidence that progress is being made.  apt-cache rdepends
| indicates that there are dozens of packages dependent on libgsl0 or
| libgsl0ldbl and so I am beginning to be concerned that we are building
| up a lot of delay.
| 
| Can anybody reading this shed light on what the next logical step
| would be here to unblock libgsl?  I am a new maintainer and so have
| not dealt with this issue before.  It is essentially blocking most of
| my Debian efforts, however, because almost all of my packages depend
| on libcomplearn.  Any help is much appreciated,
| 
| Rudi
| 
| [1]: http://packages.qa.debian.org/g/gsl.html
| 
| 
| -- 
| We can try to do it by breaking free of the mental prison of
| separation and exclusion and see the world in its interconnectedness
| and non-separability, allowing new alternatives to emerge.
| 
| 
| -- 
| To UNSUBSCRIBE, email to [EMAIL PROTECTED]
| with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
| 

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

PyGPU

[Dirk Eddelbuettel]

GPU programming from Python:
http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/

Looks promising, but I still don't really speak Python.  Anybody with more
skills and some free time interested in packaging this?  

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Science group on alioth

[Dirk Eddelbuettel]

On 24 January 2008 at 22:02, Christophe Prud'homme wrote:
| The policy is not to include the sources, just the diff. Would that be ok ?
| We use svn-buildpackage but that is not mandatory

Same for us at pkg-openmpi. I wasn't the one setting this up, but as the
default 'sponsor and uploader' I quite like working with svn-buildpackage.

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: open source image matching software

[Dirk Eddelbuettel]

On 6 February 2008 at 19:11, Paul E Condon wrote:
| I have a large number of scanned images of photographs. They are
| scanned from prints, and for some images there are several prints. I
| would like to find a program that would group similar images (similar
| in some sense that approximates human perception of similarity) and
| flags the slight differences within a group. I've looked on Google and
| found a few programs for criminal investigation but they want $ and
| seem only to exist for Windows, which I don't have here. 
| 
| I imagine that similarities could be found by image subtraction with
| minimization of some measure of image difference. But I also imagine
| that there are a host of complications. 
| 
| Suggestions?

The R statistical environment can also read images. IIRC it builds eg
matrices of RGB values from pixeled images. You can then use various
statistical measures to analyse those images.  Usual caveat: that's not what
I use R for, so your mileage may vary. 

A quick grep among the by now well over 1000 CRAN packages:

[EMAIL PROTECTED]:~ links -dump 
http://cran.r-project.org/src/contrib/PACKAGES.html | grep -i image
   adimpro   Adaptive Smoothing of Digital Images
   biOps Image processing and analysis
   biOpsGUI  GUI for Basic image operations
   epsi  Edge Preserving Smoothing for Images
   kza   Kolmogorov-Zurbenko Adaptive Filter for Image
   PET   Simulation and Reconstruction of PET Images
   pixmapBitmap Images (Pixel Maps)
   rimageImage Processing Module for R
[EMAIL PROTECTED]:~ 

There may well be more.  None of these packages are in Debian (even though we
have some 60 or so) but are typically just a matter of 

$ R CMD INSTALL someCRANSourcePkg.tar.gz

which you may want to run as root, or give a -l location argument to where
you can write.  

Cheers, Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-corba-devel] OpenCASCADE and Salomé

[Dirk Eddelbuettel]

On 6 March 2008 at 09:28, Adam C Powell IV wrote:
| On Wed, 2008-03-05 at 23:29 +0100, Thomas Girard wrote:
|  Hello Adam,
|  
|  Le mercredi 05 mars 2008 à 07:34 -0500, Adam C Powell IV a écrit :
|   I'm not getting this error...  I don't know why you would have seen that
|   MPI error, I'd patched openmpi before but upgrading to 1.2.5-2 undid my
|   patch and it works for me.  I reapplied my patch to hdf5 1.6.5-5.2
|   (minus the changelog bit) and retried, and didn't see your error; 
|  
|  Okay, got it: /usr/lib/libmpi++.so is an aternative registered with
|  liblam++.so (which was needed for hdf5 compilation). Maybe salome should
|  build-conflict with lam4-dev?
|  
|  Hmmm... removing lam-dev makes /usr/lib/libmpi++.so an alternative
|  symlink to libpmpich++.so.1.0, and not to libmpi_cxx.so.0.0.0. It seems
|  only libmpi_cxx.so works: I have forced the symlink and the link error
|  disappeared.
| 
| Ah right.  update-alternatives --config mpi should let you select
| OpenMPI for all of those links.  But to be on the safe side, I've added
| Build-Conflicts against lam4-dev and all of the mpich-dev variants.

The Open MPI package recently fixed an oversight with respect to the C++
library.  Could you try the most recent one, ie 1.2.5-2, and see if that
works out of the box ?  It should, we think we now have most things
ironed out with respect to the stand C library.

Thanks, Dirk

-- 
Three out of two people have difficulties with fractions.

Re: About free-form database

[Dirk Eddelbuettel]

This is a debian-user question.  Learn to use 'apt-cache search' --
there must be at least a hundred packages in Debian for what you
describe, from note taking to mind mappming to personal wikis.

Don't abuse debian-science because you think of yourself as a scientist.

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: future of blas/lapack/atlas packages?

[Dirk Eddelbuettel]

(Doku and Camm re-added to CC --Dirk)

On 8 July 2008 at 16:02, Ondrej Certik wrote:
| Hi,
| 
| thanks Matthias for raising this issue. 

Seconded!  

This has always been a point of great pride for Debian, and I have provided
Atlas to users of R and Octave (when I still maintained the latter) for
almost eight years. 

Camm did great and pioneering work here.  We should build on this.
 
| I am interested in helping with this. 

I may be out of my depth with the compiler / porting issues and am thinly
stretched with  100 packages (including ess which 'we' [as in a new small
group] took from Camm recently).

| We need to maintain the packages in a svn/git repository 

Sounds good. I will try to help, at least with testing.  Anybody else?

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: tasks overview wishlist: Canonical citing reference

[Dirk Eddelbuettel]

On 11 October 2008 at 15:40, Chris Walker wrote:
| I do like the approach of having a simple plain text file - while not
| machine readable does make it clear the appropriate citation - (and in

FWIW that is was R does. For the subset of CRAN package I maintain, here is
the subset having such a file:

[EMAIL PROTECTED]:~ find src/debian/CRAN/ -name CITATION
src/debian/CRAN/sn-0.4-6/inst/CITATION
src/debian/CRAN/tseries-0.10-16/inst/CITATION
src/debian/CRAN/urca-1.1-7/inst/CITATION
src/debian/CRAN/date-1.2.26/inst/CITATION
src/debian/CRAN/strucchange-1.3-4/inst/CITATION
src/debian/CRAN/chron-2.3-24/inst/CITATION
src/debian/CRAN/sm-2.2-3/inst/CITATION
src/debian/CRAN/VR-7.2.44/class/inst/CITATION
src/debian/CRAN/VR-7.2.44/nnet/inst/CITATION
src/debian/CRAN/VR-7.2.44/spatial/inst/CITATION
src/debian/CRAN/VR-7.2.44/MASS/inst/CITATION
src/debian/CRAN/zoo-1.5-4/inst/CITATION
src/debian/CRAN/sandwich-2.1-0/inst/CITATION
src/debian/CRAN/nlme-3.1.89/inst/CITATION
src/debian/CRAN/multcomp-1.0-2/inst/CITATION
src/debian/CRAN/boot-1.2.34/inst/CITATION
src/debian/CRAN/cluster-1.11.11/inst/CITATION
src/debian/CRAN/lmtest-0.9.21/inst/CITATION
src/debian/CRAN/mgcv-1.4-1/inst/CITATION

Content of the inst/ directory will always appear in the top-level directory
of the installed package.  The per-package summary then points out that a
citation file exists, and the citation() function can use.  E.g. for the sn
package that happens to be first in the list above (and two lines indented by 
me)

-
[EMAIL PROTECTED]:~ r -lsn -e'print(citation(sn))'
Package 'sn', 0.4-4 (2007-10-08). Type 'help(SN)' for summary information

To cite the sn package in publications use:

  Azzalini, A. (2007). R package 'sn': The skew-normal and skew-t
  distributions (version 0.4-4). URL http://azzalini.stat.unipd.it/SN 

A BibTeX entry for LaTeX users is

  @manual{,
title = {{R} package \texttt{sn}:The skew-normal and skew-$t$
 distributions (version 0.4-4)}, 
author = {A. Azzalini},
address = {Universit\`a di Padova, Italia},
year = {2007},
url = {URL http://azzalini.stat.unipd.it/SN},
  }
[EMAIL PROTECTED]:~ 
-


R itself provides its citation via the default (ie empty) argument:

-
[EMAIL PROTECTED]:~ r -e'print(citation(); 

To cite R in publications use:

  R Development Core Team (2008). R: A language and environment for
  statistical computing. R Foundation for Statistical Computing, Vienna, 
  Austria. ISBN 3-900051-07-0, URL http://www.R-project.org.

A BibTeX entry for LaTeX users is

  @Manual{,
title = {R: A Language and Environment for Statistical Computing},
author = {{R Development Core Team}},
organization = {R Foundation for Statistical Computing},
address = {Vienna, Austria},
year = {2008},
note = {{ISBN} 3-900051-07-0},
url = {http://www.R-project.org},
  }

We have invested a lot of time and effort in creating R, please cite it when
using it for data analysis. See also  citation(pkgname)  for citing R 
packages.
-


Obviously, this is easier for R as it provides one coherent system. But we
could start with an additional file in debian/ and go from there.

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: building package with different libs

[Dirk Eddelbuettel]

On 14 November 2008 at 23:12, Steve M. Robbins wrote:
| Howdy,
| 
| 
| On Thu, Oct 30, 2008 at 07:48:19PM -0400, Adam C Powell IV wrote:
|  [Copying -beowulf as there's likely some interest there as well.]
|  
|  On Thu, 2008-10-30 at 15:21 +0100, Manuel Prinz wrote:
| 
|   When building against OpenMPI, there are a few choices:
|   
|1. Do not build packages using OpenMPI on the unsupported arches.
|2. Build against OpenMPI on the supported ones, fall back to LAM on the
|   unsupported ones.
| 
| [ ... ]
| 
|  As for -lam where there's no openmpi, I only know of petsc and babel.

[ For r-cran-rmpi, I also fall back to using LAM where Open MPI is
missing. Perusing NEW today, I saw that Adam falls back to MPICH for the new
Arpack. May be a better fall-back, but I personally have used LAM and no
MPICH before Open MPI. I guess at some point we need to consolidate out MPI
efforts. ]
 
| I have subsequently adopted this approach for minc, which uses MPI via
| hdf5.  I will likely adopt it for boost, too, unless someone has a
| better idea.
| 
| While reading this thread, however, I had an idle thought.  Could we
| prepare an mpi-default-dev or sensible-mpi-dev package for us to
| build-depend on?  This would be something like the gcc-defaults
| package and simply depend on the appropriate -dev pacakges (OpenMPI on
| some architectures, LAM on the rest).
| 
| The idea is to put the messy details about which architectures support
| OpenMPI and which use LAM in one place.

Sounds good to me, and I am cc'ing the pkg-openmpi list. I won't have spare
cycles to work on it, but it strikes as a fundamentally sound suggestion.

And while we're at it, it may also make sense to try to come to a consensus
of our MPI 'preferences' within Debian. I.e. which one should be the default
and own the 'highest' alternatives level.  Also, I think we had to give up on
some alternatives usage because Open MPI had files the others didn't. I am a
little fuzzy on the details but if there is interest, Manuel can probably
fill in any details.

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-openmpi-maintainers] building package with different libs

[Dirk Eddelbuettel]

On 18 November 2008 at 23:03, Adam C Powell IV wrote:
| All things considered, OpenMPI has my vote as the most advanced
| implementation right now...

Thanks for that. Given that we need to order these (presented alphabetically)

LAM ? MPICH ? Open MPI

I suggest the following:

i)   LAM is last as upstream stopped and suggested moving to Open MPI; it is
however widely available and stable so we want to keep (if someone maintains it)

ii)  MPICH is second per Adam's vote (== MPICH maintainer)

iii) Open MPI becomes the default as it is very actively maintained upstream,
modular, fairly advanced, etc ppp

so we get
   
Open MPI  MPICH  LAM

in reverse alphabetical order. How cute :)  

Manuel, what were your thoughts against Open MPI as the default?  Lack of
availability on all arches?  Newness ?

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#522017: ITP: jblas -- jblas is a fast linear algebra library for Java

[Dirk Eddelbuettel]

On 3 April 2009 at 07:51, Sylvestre Ledru wrote:
| Le vendredi 03 avril 2009   01:24 +0200, Matthias Klose a  crit :
|  Chris Walker schrieb:
|   Soeren Sonnenburg so...@debian.org writes:
|   
|   Package: wnpp
|   Severity: wishlist
|   Owner: Soeren Sonnenburg so...@debian.org
|  
|   * Package name: jblas
|   
|   This package seems likely to be of interest to debian-science, so I'm
|   sending this mail there too. 
|  
|  if jblas seems to be of interest to debian-science, please would you take 
care
|  of atlas and an upgrade to atlas 3.8 as well? else I would suggest to Chris 
to
|  just go ahead and maybe CC debian-java.
| I am currently working on atlas (see the work in the svn of pkg-scicomp)
| but it is a big work (especially solving the problem of the specific
| optimisation for each arch within the packaging system).

Allow to just budge in to say a heartfelt Thank You!  Debian always rocked
because of all the work Camm had done for Atlas, and it would be terrific if
we continued to have nicely working Atlas package.  So your work is really
appreciated!  

[ Personally speaking, I'd say feel free to simplify. IMHO it is better to
have a decent and current atlas-base (with a hook to optimise locally) than
a multitude of packages that invariably get old as cpu (sub-)architectures
change. ]

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: MPICH2 packaging

[Dirk Eddelbuettel]

On 16 June 2009 at 10:06, Lucas Nussbaum wrote:
| On 15/06/09 at 18:32 -0400, Adam C Powell IV wrote:
|  Hello Pavan,
|  
|  Thank you for the inquiry.  I've somewhat left MPICH for now (focusing
|  on OpenMPI, which I don't maintain but use), and assigned its
|  maintenance to the Debian Scientific Computing team.  But I think there
|  are others very interested in MPICH2, and am copying the debian-science
|  list to gauge interest.
| 
| (Adding Camm Maguire, the LAM maintainer as Cc)

That address has been out of commission for a while; Camm used to work there
but AFAIK no longer does.  I don't have the replacement address handy though.

| This raises an interesting question: if we package mpich2, couldn't we
| drop mpich(1) and LAM from Debian? Are there cases where it's more
| interesting to use mpich v1 or LAM than mpich2 or OpenMPI?

As a former Open MPI co-maintainer:  yes, LAM is to be deprecated one day as
Open MPI is actively developed whereas LAM is dead. On the other hand, Open
MPI is available on only a subset of architectures. It's tricky.

That said, getting good MPICH2 in would be super too!

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: How about packaging a Java GUI for R?

[Dirk Eddelbuettel]

On 1 July 2009 at 20:14, Charles Plessy wrote:
| I have found today a nice R GUI written in Java, JGR (speak 'Jaguar').
| http://jgr.markushelbig.org/JGR.html

Yes -- I had of course been aware of it for years and had versions on my
box. JGR had won a software price in the R world when Simon (a co-author on
this, now at ATT Research) was still a student.

I never packaged it because I had trouble reliably building Java / R apps --
for lack of free Java rich enough to build it, or for a while for a lack of
the right approach from the R side of things.  That changed a few years
ago---and I was able to put the required bridge package 'r-cran-rjava' (upon
all the other build) into Debian.

That said, this is still fragile and things break from time to time, eg in
our cran2deb conversions. [ As I may have mentioned, I will be giving a talk
about 'cran2deb' at UseR 2009 next week.  We now build over 1760 packages
from CRAN fully automatically.  JGR had issue that I didn't fully understand
-- from the cronjob it broke the build, building by hand worked. Now,
cran2deb is not meant to replace the Debian packaging effort.  It simply
takes away the silly manual labour for easy packages.  Whether Debian
packages from it will appear somewhere for broader use is still not quite
clear. ]

| Using CDBS, it was very easy to make draft Debian source packages for it and
| its dependancies (r-cran-javagd, r-cran-iplots). The GUI seems to run fine,
| althoug a bit slowly, but I suspect it is partially because I am using a
| PowerPC machine.
| 
| I could of course go forward and make official Debian package, but I am really
| affraid that packaging a GUI attracts a lot of user feedback, and I am not 
sure
| that I would be able to cope with it without impairing my Debian Med
| activities, which are my priorities. Moreover, I am a complete Java ignorant.

It is always best to package things one actually uses and cares about :) 

So by all means, if folks use it, they should package it. 

| You can then guess the question: who would be interested in co-maintaining the
| packages? Would you prefer a Git or a Subversion repository?
| 
| (I have CCed Dirk because I do not remember if he is subscribed to that list).

He is. But thanks either way :)

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

[ANNOUNCEMENT] cran2deb: 1700+ new Debian / R packages

[Dirk Eddelbuettel]

Announcing cran2deb: 1700+ Debian packages from almost all of CRAN
--

Last Friday's presentation at UseR! 2009 was the first really public mention
of 'cran2deb'. It provides Debian packages of all of CRAN. It started as
Charles' project from last year's Google Summer of Code, was further extended
by us over the last year.

We currently build for the testing distribution and the i386 and amd64
architectures. This is now publically useable and we welcome wider testing
by Debian users. We hope to extend this to Ubuntu during the summer or fall.

I include what I blogged earlier (which you may have seen via Planet Debian
and/or Planet R).  This also contains the /etc/apt/sources.list entries:


   cran2deb: Would you like 1700+ new Debian / R packages ?

   As I mentioned in my [8]quick write-up of UseR 2009, one of my talks
   was about cran2deb: a system to turn (essentially) all [1]CRAN packages
   into directly apt-get-able binary packages.

   This is essentially a '2.0' version of earlier work with Steffen
   Moeller and David Vernazobres which we had presented in 2007. Then, the
   approach was top-down and monolithic which started to show its limits.
   This time, the idea was to borrow the successful bottom-up approach of
   my [2]CRANberries feed.

   The bulk of the work was done by Charles Blundell as part of his Google
   Summer of Code 2008 project which I had suggested and mentored. After
   that project had concluded, we both felt we should continue with it and
   bring it to 'production'. The CRAN hosts provided us with a (virtual
   Xen) machine to build on, and we are now ready to more publically
   announce the availability of the repositories for i386 and amd64:

  deb http://debian.cran.r-project.org/cran2deb/debian-i386 testing/

   and
  
  deb http://debian.cran.r-project.org/cran2deb/debian-amd64 testing/

   A few more details are provided in [3]our presentation slides. We look
   forward to hearing from folks using; the r-sig-debian list may be a
   good venue for this.


   References
   1. http://cran.r-project.org/
   2. http://dirk.eddelbuettel.com/cranberries
   3. http://dirk.eddelbuettel.com/papers/useR2009cran2deb.pdf


Please direct questions to r-sig-debian (which has subscriber-only posts) or
debian-science. 

Regards,  Dirk and Charles
 
-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [ANNOUNCEMENT] cran2deb: 1700+ new Debian / R packages

[Dirk Eddelbuettel]

Hi Don,

That was a quick follow-up :)

On 13 July 2009 at 14:02, Don Armstrong wrote:
| On Mon, 13 Jul 2009, Dirk Eddelbuettel wrote:
|  We currently build for the testing distribution and the i386 and
|  amd64 architectures. This is now publically useable and we welcome
|  wider testing by Debian users. We hope to extend this to Ubuntu
|  during the summer or fall.
| 
| Couple quick questions:
| 
| 1) Is there an effort to build against unstable in addition to testing?

I think we used unstable at one point (to be closer to Debian practices) but
where then suffering from some temporary breakage.  I have added Charles back
to the CC, maybe he remembers.

Charles and I are currently the only ones running this. If this proves useful
for enough users, maybe we can in the medium-term find better hardware and/or
more manpower to attempt more build arches, distros, ...   But in the short
term:  no, unlikely, as we do not have the bandwidth.

The other unspoken point: no, I do not intend to submit 1700 packages to
Debian's NEW queue. It would take a lot more effort to properly manually
maintain these at full-strength distro quality, starting with the 1700+
debian/copyright files.
 
| 2) Do you have more detailed information on how someone can set up
| cran2deb with the cronjobs that you are running? [Specifically, I'd
| like to build the set on powerpc, unstable, as I use a mixture of
| amd64, i386 and powerpc.]

Absolutely. cran2deb itself is hosted on r-forge.r-project.org where you can
fetch the sources as a tar.gz, and/or use svn.  That said, the initial stage
is a little manual.  We may want to take this off-list.

Another aspect would be to make the db that controls it all more globally
visible. Right now it is in sqlite and local to the build host so your
efforts and ours would be disjoint which is suboptimal.

| Thanks for the effort, though! I've been sort of hoping and waiting
| for something similar to come along.

Our pleasure.  Give it a spin and see how it goes.

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [R-sig-Debian] [ANNOUNCEMENT] cran2deb: 1700+ new Debian / R packages

[Dirk Eddelbuettel]

Hi Michael,

On 14 July 2009 at 18:44, charles blundell wrote:
| 2009/7/13 Michael Rutter ma...@psu.edu
|  1.  Are there any negatives going from an install.packages(foo)
|  approach using R then switching to an apt-get install r-cran-foo
|  method of installing packages?  If I install a deb package on top of
|  an R installed package, will there be issues?
| 
| This should be the same as installing the package twice via R CMD
| INSTALL; I don't expect any issues but I cannot guarantee that I have
| not forgotten something.

Right. R_LIBS aka what you see via .libPaths() in R simply makes it possible
for those in /usr/local/lib/R/site-library [installed via install.packages()]  
to shadow those in /usr/lib/R/site-library. I can't remember if R is now
smart enough to pick the highest version; it may.  At some point in the past
the 'first one found' seemed to win.  So in sum:  no harm, other than maybe
missing the newest.  We insured that different locations are used which the
man years of co-existence with r-cran-* packages in Debian possible. We
simply extend this now.

Longer term, some real work may need to go to make install.packages() aware
of the OS's package management system. That better work well though...

|  2.  What will it take to do this for Ubuntu?  Are we going to need a
|  (virtual) machine for each release or can this be done under chroot
|  jails on one server?
| 
| I think, though have never got very far, that differences in package
| naming will be the main technical problem with supporting Ubuntu in a
| similar fashion, assuming re-use of the excellent Debian tools
| (pbuilder, mini-dinstall, etc) with a different set of base packages.
| 
| Each release (i.e., debian i386 testing) requires a chroot
| environment: it could all be done on one machine. We simply use
| pbuilder. Maybe you would not want to do this for too many releases
| (bandwidth, disk space, cpu time).

More details to follow but I may have access to some institutional support
for this. No details yet though.

Cheers, Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: simple batch queue system?

[Dirk Eddelbuettel]

On 22 July 2009 at 16:32, Lucas Nussbaum wrote:
| On 22/07/09 at 12:30 +0200, Teemu Ikonen wrote:
|  Hi Debian scientists,
|  
|  I'm in the market for a simple job scheduler for a set of work nodes
|  in the 'cloud' (i.e. EC2). A queue for submitted non-parallel jobs,
|  commands to insert and delete jobs, and simple first-come, first
|  served scheduling is what I'm looking for. Starting and stopping node
|  instances by demand would be a nice bonus, but not absolutely needed
|  right now.
|  
|  I'm sure gridengine or slurm could do what I need, but it also looks
|  like they need significant effort to set up. Are there any other
|  open-source options? If not, does anyone have tips for running, say
|  slurm with EC2 compute nodes?
| 
| OAR http://oar.imag.fr. Not packaged in Debian, but there are
| unofficial Debian packages. Requires Perl + MySQL.

I was about to suggest that having met one of Lucas' colleagues at the GSoC
mentor summit last year :-)

Another entry from France was presented in one of the UseR! 2009 sessions:
http://www.agrocampus-ouest.fr/math/useR-2009/slides/Etienne+Corvazier+Legros.pdf

Their code is at http://code.google.com/p/coalition/ --- it uses Python and
Twisted (which we have) and two simple scripts and is not be tied to R per
se.  Nice simple web frontend.

Dirk


| - Lucas
| 
| 
| -- 
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
| 

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [ANNOUNCEMENT] cran2deb: 1700+ new Debian / R packages

[Dirk Eddelbuettel]

On 24 July 2009 at 12:53, Andreas Tille wrote:
| On Mon, Jul 13, 2009 at 04:19:25PM -0500, Dirk Eddelbuettel wrote:
|  The other unspoken point: no, I do not intend to submit 1700 packages to
|  Debian's NEW queue. It would take a lot more effort to properly manually
|  maintain these at full-strength distro quality, starting with the 1700+
|  debian/copyright files.
| 
| [Late reply because I was offline for a while] 
| 
| I wonder whether your effort might result in some kind of preparation
| for manual builded official Debian package.  It turned out that Debian

Hm, to me Debian and cran2deb are complementary. We just provide another
apt-get'able repo with builds for one flavour and two arches.  Debian is more
general.

| has a certain set of CRAN packages and there is obviosely some need
| for this because people will define dependencies of non-CRAN packages
| from these. 

Will they?  For 'in-Debian' packages it would be a severe bug to depends on
'out-of-Debian' packages.

| IMHO it sounds like a good idea to use a cran2deb builded
| source package and add the needed files like copyright and most probably
| watch file (it seems clear to me that cran2deb has no use for watch
| files if it is building the latest version anyway).

cran2deb allows for per-package patches. We needed that to fix a handful of
corner cases. So one could create another similar mechanism to pull in
pre-existing changelog entries. I am unsure, however, how urgent that need
is.  In the hypothetical case from a world with unlimited resources: sure,
why not?  On this planet, I tend to think I may have other more urgent
matters to deal with.

| So I wonder if there is a chance to submit patches to cran2deb with
| these files to keep the code stored in one place, which means that you
| might integrate manually created copyright / watch files into cran2deb
| build system and DDs who want to build an official package just draw
| all the code from this unique source.
| 
| Does this sound reasonable?

I don't know. For one thing, cran2deb creates packages with 1.2-1.cran.$x
versioning which is different (to allow for clear sorting).  So this system
never creates 'Debian replacement packages'.  I think time will tell how
cran2deb and Debian itself can morph together.

In the medium to long run, I think it is much more important to work on
things like install.packages() inside R to make the R-internal package
management aware of the Debian (or Ubuntu) package management layer.  As
r-help and other venues demonstrate, way too many people still fail on
install.packages() or R CMD INSTALL source.tar.gz (for lack of -dev packages,
say) when they could have gotten the same package via apt-get.  

Hth, Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Rebuilding all 100+ r-cran-* packages for R 2.10.0

[Dirk Eddelbuettel]

R 2.10.0, due out October 26, will switch to an internal html converter from
the latex-alike Rd format coupled with an internal webserver.  See below for
the section on 'Significant user-visible changes' in the NEWS file from
2.10.0 -- taken from the Oct 13 beta currently in unstable.

This means we should rebuild all packages or else they will upon load
trigger a nagging message 'package foo was built under R version x.y.z and
may not function properly' as well as possible malfunctions of the help
system.  As we're only talking 100+ packages, this should work.

I would appreciate some pointers as to how I can milk out fancypants new mega
databases to extracts all packages (matching r-cran-*; there are only one or
two exceptions to that rules) and their maintainers ... and ideally even
monitor most recent re-builds.  Anybody feel like sharing some hints with me
off-line? 

Also, and the security minded folks may want to consider the second bullet
point:  do we need to worry about this or not as it is just the loopback
interface?  Seems fine to me but I figured I'd better ask :)

Please CC me on replies. 

Cheers, Dirk





**
**
*  2.10 SERIES NEWS  *
**
**


CHANGES IN R VERSION 2.10.0


SIGNIFICANT USER-VISIBLE CHANGES

o   Package help is now converted from Rd by the R-based converters
that were first introduced in 2.9.0.  This means

- Packages that were installed by R-devel after 2009-08-09
  should not be used with earlier versions of R, and most
  aspects of package help (including the runnable examples)
  will be missing if they are so used.

- Text, HTML and latex help and examples for packages
  installed under the new system are converted on-demand from
  stored parsed Rd files.  (Conversions stored in packages
  installed under R  2.10.0 are used if no parsed Rd files
  are found.  It is recommended that such packages be
  re-installed.)


o   HTML help is now generated dynamically using an HTTP server
running in the R process and listening on the loopback
interface.

- Those worried about security implications of such a server
  can disable it by setting the environment variable
  R_DISABLE_HTTPD to a non-empty value.  This disables
  help.start() and HTML help (so text help is shown instead).

- The Java/Javascript search engine has been replaced by an
  HTML interface to help.search().  help.start() no longer has
  an argument 'searchEngine' as it is no longer needed.

- The HTML help can now locate cross-references of the form
  \link[pkg]{foo} and \link[pkg:foo]{bar} where 'foo' is an
  alias in the package, rather than the documented (basename
  of a) filename (since the documentation has been much
  ignored).




-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Rebuilding all 100+ r-cran-* packages for R 2.10.0

[Dirk Eddelbuettel]

On 17 October 2009 at 01:29, Cyril Brulebois wrote:
| Dirk Eddelbuettel e...@debian.org (16/10/2009):
|  This means we should rebuild all packages or else they will upon
|  load trigger a nagging message 'package foo was built under R
|  version x.y.z and may not function properly' as well as possible
|  malfunctions of the help system.  As we're only talking 100+
|  packages, this should work.
| 
| You want to contact -release@ as well (possibly early). And something
| like 100+ packages is something they might want to know about.

I guess so. It's borderline as it doesn't malfunction, yet upstream
recommends rebuilds. Will contact release.
 
|  Also, and the security minded folks may want to consider the second
|  bullet point: do we need to worry about this or not as it is just
|  the loopback interface?  Seems fine to me but I figured I'd better
|  ask :)
| 
| You want to ask -security@ (or the security team directly, you choose)
| too, I guess.

Ack. Will send to them as well.

|  Please CC me on replies.

Appreciate it.

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: tasks overview wishlist: Canonical citing reference

[Dirk Eddelbuettel]

Hi Morten,

On 4 November 2009 at 16:18, Morten Kjeldgaard wrote:
| Charles Plessy wrote:
| 
|  In the discussion that followed, we talked about where to store this
|  information, and in which format, since adding more content to the
|  debian/control file is not an easy thing (it ‘costs’ a lot because it goes 
to
|  pivotal files like the Packages.gz files on our mirrors). A four line 
summary
|  is available here: http://wiki.debian.org/DebianScience/References
| 
| I can't remember seeing this discussion, but in some of my packages, I've
| put a file debian/citation.bib, which is installed in the
| /usr/share/doc/package/ directory.

Nice idea.
 
| This enables the user to easily import the citation into a bibliographic
| database, and the .bib format is a de-facto standard. Of course the various
| Debian tools can parse the file too.
| 
| This approach is of course not the only one, but it has the merit of being
| simple.

As one possibility for going one step further, consider what R supports (but
not requires).  If any of the add-on package CRAN has a CITIATION file, then
the citation() function can be used to pretty-print the content, incl a
Bibtex snippet, by giving the R package name as argument:

e...@ron:~/src/debian/CRAN r -e'print(citation(package=zoo))'

To cite zoo in publications use:

  Achim Zeileis and Gabor Grothendieck (2005). zoo: S3 Infrastructure for 
Regular and Irregular Time Series. Journal of Statistical Software,
  14(6), 1-27. URL http://www.jstatsoft.org/v14/i06/

A BibTeX entry for LaTeX users is

  @Article{,
title = {zoo: S3 Infrastructure for Regular and Irregular Time Series},
author = {Achim Zeileis and Gabor Grothendieck},
journal = {Journal of Statistical Software},
year = {2005},
volume = {14},
number = {6},
pages = {1--27},
url = {http://www.jstatsoft.org/v14/i06/},
  }

e...@ron:~/src/debian/CRAN 


We could easily cook-up something similar with a structure input file and a
simple display wrapper that could go into a debian-science utils package.

Cheers, Dirk


-- 
Three out of two people have difficulties with fractions.


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Torque in Debian?

[Dirk Eddelbuettel]

I seem to recall that someone once mentioned packaging of Morten's Torque
packages from Ubuntu. I also seem to recall Steffen saying that he was in
contact with Morten.  Based on quick search of my mail folder  I can't find
traces of either. Could someone kindly refresh my memory?

[ Google sees traces of informal packaging of Torque on non-Debian repos and
  prior debian-legal discussion -- did that ever progress beyond the earlier
  Nope ? ]

Dirk

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#560347: RFP: ncl -- Nexus Class Library

[Dirk Eddelbuettel]

Package: wnpp
Severity: wishlist

* Package name: ncl (Nexus Class Library)
  Version : 2.1.08 (dated 2009-11-30)
  Upstream Author : Paul O. Lewis
* URL or Web page : http://hydrodictyon.eeb.uconn.edu/ncl/
* License : GPL-2
  Description : Nexus Class Library
   The NEXUS Class Library (NCL) is an integrated collection of C++ classes
   designed to allow the user to quickly write a program that reads
   NEXUS-formatted data files. It also allows easy extension of the NEXUS format
   to include new blocks of your own design.
   .
   The NEXUS data file format was specified in the publication cited
   below. Please read this paper for further information about the format
   specification itself; the documentation for the NCL does not attempt to
   explain the structure of a NEXUS data file.
   Maddison, D. R., D. L. Swofford, and Wayne P. Maddison. 1997. NEXUS: an
   extensible file format for systematic information. Systematic Biology 46(4):
   590-621.
   .
   The basic goal of the NCL is to provide a relatively easy way to endow a
   C++ program with the ability to read NEXUS data files. The steps necessary
   to use the NCL to create a bare-bones program that can read a NEXUS data
   file are simple and few, and it is hoped that the availability of this
   class library will encourage the use of the NEXUS format. This will in
   turn encourage consistency in how programs read NEXUS files and how
   programs respond to errors in data files.
   .
   There are a large number of special data file formats in use. This places
   an extra burden on the end user, who must deal with an increasing number
   of file formats all differing in a number of ways. To convert one's data
   file to another file format often involves manual manipulation of the
   data, an activity that is inherently dangerous and probably has resulted
   in the corruption of many data files. At the very least, the large number
   of formats in existance has led to a proliferation of data file
   variants. With many copies of a given data file on a hard disk, each
   formatted differently for various analysis programs, it becomes very easy
   to change one (say, correct a datum found to be in error) and then fail to
   correct the other versions. The NEXUS file format provides a means for
   keeping one master copy of the data and using it with several programs
   without modification. The NCL provides a means for encouraging programmers
   to use the NEXUS file format in future programs they write.


I could use that for some R packaging (of 'phylobase'), but as I don't use
this directly I don't really want to be / should be the maintainer.

Any biologists in the readership who would like to work on this?

Dirk

-- 
Three out of two people have difficulties with fractions.



-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: RFS: r-cran-scatterplot3d

[Dirk Eddelbuettel]

On 24 January 2010 at 18:24, Philip Rinn wrote:
| Dear debian-science subscribers,
| 
| I am looking for a sponsor for my package scatterplot3d.
| 
| * Package name: scatterplot3d
|   Version : 0.3-30-1
|   Upstream Author : Uwe Ligges
| * URL : http://cran.r-project.org/web/packages/scatterplot3d/
| * License : GPL-2
|   Section : gnu-r
| 
| Scatterplot3d is an GNU R package for the visualization of multivariate data 
in
| a three dimensional space. Basically scatterplot3d generates a scatter plot in
| the 3D space using a parallel projection. Higher dimensions (fourth, fifth, 
etc.)
| of the data can be visualized to some extent using, e.g. different colors,
| symbol types or symbol sizes.
| 
| 
| It builds the binary packages r-cran-scatterplot3d. I renamed it to fit the
| pattern of CRAN packages for R in Debian.
| 
| The package appears to be lintian clean and it would fix bug #565682.
| It can be found on mentors.debian.net:
| http://mentors.debian.net/debian/pool/main/s/scatterplot3d

Building CRAN packages is trivial, it usually takes me about five minutes max
per package.  

Yet I am not convinced that is what we want to sponsor more as some folks who
have sponsored / packaged / uploaded are not keeping up with the new versions
at CRAN (I think that holds for matchit, pscl, sp, vgam, zelig per [1] and
other pages). I try to keep up with mine, and it really is not a large
effort.  Yet someone has to make it for the sponsored / team-managed packages
too. 
| 
| I'd be glad if someone could upload this package for me, as it would 
supplement
| the collection of CRAN packages in Debian especially for 3D plotting.

Are you aware of http://debian.cran.r-project.org which gets you 2000+ CRAN
packages as deb files for testing on i386 and amd64 ?  That is an automated
process not suitable for injection into Debian proper, but one that could be
extended to other arches etc given suitable hardware donations.

Dirk

[1] 
http://qa.debian.org/developer.php?login=debian-science-maintain...@lists.alioth.debian.org
| 
| Kind regards
|  Philip Rinn
| 
| PS: would you please CC me, as I'm not on the list.
| 
| 
| -- 
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
| 

-- 
Three out of two people have difficulties with fractions.


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [R-sig-hpc] License of GotoBLAS was changed to BSD

[Dirk Eddelbuettel]

Hi science folks,

Ei-ji, who follows this closely and who also wrote a the very nice
gotoblas2-helper package which turns the (until now non-free) gotoblas2 into
a rocking .deb package, just posted this to the R list for HPC:

On 27 November 2010 at 01:32, Ei-ji Nakama wrote:
| Hi,
| 
| Please look at the following.
| http://www.tacc.utexas.edu/tacc-projects/gotoblas2/
| 
| comparatively new CPU should force it with `make TARGET=NEHALEM'

Wouldn't we want GotoBLAS2 in Debian now that it is BSD-licensed?  I checked
the link and there is in fact a new download link -- no more registration at
TACC and all that.

Sylvestre, any interest and equally importantly, spare cycles on your part?

Cheers,  Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19695.58869.787359.241...@max.nulle.part

Re: [R-sig-hpc] License of GotoBLAS was changed to BSD

[Dirk Eddelbuettel]

Salut Sylvestre!

Thanks for the superspeedy follow-up!

On 26 November 2010 at 18:00, Sylvestre Ledru wrote:
| Le vendredi 26 novembre 2010 à 10:53 -0600, Dirk Eddelbuettel a écrit :
|  Hi science folks,
|  
|  Ei-ji, who follows this closely and who also wrote a the very nice
|  gotoblas2-helper package which turns the (until now non-free) gotoblas2 into
|  a rocking .deb package, just posted this to the R list for HPC:
|  
|  On 27 November 2010 at 01:32, Ei-ji Nakama wrote:
|  | Hi,
|  | 
|  | Please look at the following.
|  | http://www.tacc.utexas.edu/tacc-projects/gotoblas2/
|  | 
|  | comparatively new CPU should force it with `make TARGET=NEHALEM'
|  
|  Wouldn't we want GotoBLAS2 in Debian now that it is BSD-licensed?  I checked
|  the link and there is in fact a new download link -- no more registration at
|  TACC and all that.
|  
|  Sylvestre, any interest and equally importantly, spare cycles on your part?
| That is excellent news !! Especially since, thanks to your document, I
| am aware of the great performances of GotoBLAS2.
| Especially since we have now in Debian a quick and easy way to switch
| between BLAS implementations.
| 
| I am ready to upload this in Debian if it is OK with you.

That would be wonderful. I'd be happy test source packages etc pp
 
| Sylvestre
| PS: Can you confirm that all the performances optimisation are done at
| runtime (like the MKL) and not build time (like ATLAS) ?

Not sure I fully understand the question. A lot of _tuning_ happens at
_build time_ just like Atlas.  That is where the tuning comes from.

What Goto BLAS shares with MKL (and does better than Atlas) is the ability to
_select the number of cores at run-time_.  Is that what you meant?

All 'hard' questions I suggest you direct in a friendly email to Ei-ji who
knows so much more about all this than I do...

Cheers, Dirk 

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19695.60017.105032.21...@max.nulle.part

Re: [R-sig-hpc] License of GotoBLAS was changed to BSD

[Dirk Eddelbuettel]

On 26 November 2010 at 23:10, Thomas Weber wrote:
| On Fri, Nov 26, 2010 at 10:53:09AM -0600, Dirk Eddelbuettel wrote:
|  Wouldn't we want GotoBLAS2 in Debian now that it is BSD-licensed?  
| 
| Uh, are you guys aware of 
| http://www.tacc.utexas.edu/tacc-projects/gotoblas2/faq/ ?
| 
| GotoBLAS is no longer under active development.

We do. 

The whole BSD release is presumably of consequence of Mr Goto no longer being
at U of Texas and working on it. 

But by getting it into Debian we also give it more exposure and who knows
maybe some other folks will pick it up. In the meantime its performance is
still better than Atlas in most cases (as e.g. shown in my benchmarking paper
/ blog posts -- see http://dirk.eddelbuettel.com/blog/code/gcbd/

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19696.14393.875957.970...@max.nulle.part

Re: How to properly integrate cran2deb into Debian?

[Dirk Eddelbuettel]

On 18 February 2011 at 13:10, Manuel Prinz wrote:
| On Fri, Feb 18, 2011 at 11:08:20AM +0100, Andreas Tille wrote:
|  probably not the right list, debian-science list comes rather to mind
|  because Dirk Eddelbuettel (in CC) is also reading there.  So please move
|  to this list in case you want to continue discussing this issue.
| 
| Done. Totally forgot to CC Dirk, thanks for noticing!

I just wanted to state that I have never in the past nor in the present
suggested to use cran2deb to insert a large number of packages---currently
2800 at CRAN and growing at a 40% yearly growth rate---into Debian.

If memory serves, the NEW Queue maintainer just complained about 300 packages
waiting and too few people helping.  I think there is a __a lot__ of work
involved in getting the archive, builder, bug system, ... going.  Adding
2800+ packages which are, for a very large part, pretty fringe, is not going
to be a smart idea.

Additional cran2deb resources would be good. It has been leaning on Charles
alone for too.  I think I speak for Charles when I say that our vision always
was to get cran2deb up and running as a test repository and gather
experience running it.  One could then analyses popular packages (or clusters
thereof) and insert those, provided some maintainer (or groups) stand behind
them.  Talking to ftp maintainer as Manuel suggested is definitely a good
idea too, or even imperative.

I won't have much to add to the discussion so please feel free to drop the CCs.

Good luck,  Dirk


-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19806.29494.66161.844...@max.nulle.part

Re: Bug#589685: KDE 3's libs removal ping

[Dirk Eddelbuettel]

On 15 April 2011 at 13:27, Jameson Graef Rollins wrote:
| Hi, folks.  So what exactly is the current status of kst?  I see that it
| has been removed entirely from testing, which is very unfortunate.  Is
| someone taking over packaging?
| 
| kst2 is also now available, and it even looks like it's packaged for
| Ubuntu:
| 
| https://launchpad.net/~stevebenton/+archive/kst2
| 
| Can we get this into Debian as well? 

Yes please!

| Can kst2 just take over the kst
| name, seeing as there's not currently a kst package?

Maybe but http://kst-plot.kde.org/ makes it clear that 'kst1' and 'kst2' are
not feature-by-feature substitutes.  

Not sure if it worth dealing with /etc/alternatives/ though.

Dirk
 
-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19880.48742.628059.540...@max.nulle.part

Re: OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)

[Dirk Eddelbuettel]

On 29 June 2011 at 15:01, Andreas Tille wrote:
| Hi,
| 
|  Your package is uninstallable on some archs:
| 
| mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
| mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
| mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
| 
| I admit I'm not so comfortable with these architectures.  Is there any
| drop-in replacement for openmpi on these and if yes, what do I need to
| specify in debian/{control,rules}? 

There is. We are simply slow in implementing this for all packages.

[ Long and boring story:  MPICH was never in Debian, LAM deprecated, OpenMPI
 undermaintained. I adopted it a few years ago; Manuel then took over. Open
 MPI _upstream_ never had support for certain arches (for performance / ASM
 use reasons) so we always had these 'holess'. ]

The situation is mostly fixed and automatic now.  Instead of depending on
openmpi, just depend in mpi-default-dev and everything should just work (TM).

| Could any other package with the same problem serve as an example?

Here is what my pgapack package does:

   Build-Depends: debhelper (= 7.0), mpi-default-dev

and here is my Rmpi package (which also needs R):

   Build-Depends: debhelper (= 7.0.0), cdbs, r-base-dev (= 2.12.0), 
mpi-default-dev

Hope this helps,  Dirk

| Kind regards
| 
|Andreas.
| 
| -- 
| http://fam-tille.de
| 
| 
| -- 
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
| Archive: http://lists.debian.org/20110629130159.ga13...@an3as.eu
| 

-- 
Gauss once played himself in a zero-sum game and won $50.
  -- #11 at http://www.gaussfacts.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19979.10474.628037.729...@max.nulle.part

Re: OpenMPI-bin missing on some arches (Was: mrbayes-mpi: uninstallable on mipsen and s390)

[Dirk Eddelbuettel]

On 29 June 2011 at 08:30, Dirk Eddelbuettel wrote:
| 
| On 29 June 2011 at 15:01, Andreas Tille wrote:
| | Hi,
| | 
| |  Your package is uninstallable on some archs:
| | 
| | mrbayes-mpi/mips unsatisfiable Depends: openmpi-bin
| | mrbayes-mpi/mipsel unsatisfiable Depends: openmpi-bin
| | mrbayes-mpi/s390 unsatisfiable Depends: openmpi-bin
| | 
| | I admit I'm not so comfortable with these architectures.  Is there any
| | drop-in replacement for openmpi on these and if yes, what do I need to
| | specify in debian/{control,rules}? 
| 
| There is. We are simply slow in implementing this for all packages.
| 
| [ Long and boring story:  MPICH was never in Debian, LAM deprecated, OpenMPI
|  undermaintained. I adopted it a few years ago; Manuel then took over. Open
|  MPI _upstream_ never had support for certain arches (for performance / ASM
|  use reasons) so we always had these 'holess'. ]

[ Forgot add here that now that we have proper MPICH2 everywhere, it serves
as a fallback where Open MPI --- which AFAIK is still the default where
available --- cannot be used. ]

Dirk 

| The situation is mostly fixed and automatic now.  Instead of depending on
| openmpi, just depend in mpi-default-dev and everything should just work (TM).
| 
| | Could any other package with the same problem serve as an example?
| 
| Here is what my pgapack package does:
| 
|Build-Depends: debhelper (= 7.0), mpi-default-dev
| 
| and here is my Rmpi package (which also needs R):
| 
|Build-Depends: debhelper (= 7.0.0), cdbs, r-base-dev (= 2.12.0), 
mpi-default-dev
| 
| Hope this helps,  Dirk
| 
| | Kind regards
| | 
| |Andreas.
| | 
| | -- 
| | http://fam-tille.de
| | 
| | 
| | -- 
| | To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| | with a subject of unsubscribe. Trouble? Contact 
listmas...@lists.debian.org
| | Archive: http://lists.debian.org/20110629130159.ga13...@an3as.eu
| | 
| 
| -- 
| Gauss once played himself in a zero-sum game and won $50.
|   -- #11 at http://www.gaussfacts.com
| 
| 
| -- 
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
| Archive: http://lists.debian.org/19979.10474.628037.729...@max.nulle.part
| 

-- 
Gauss once played himself in a zero-sum game and won $50.
  -- #11 at http://www.gaussfacts.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19979.12416.328142.51...@max.nulle.part

Julia language in Debian ?

[Dirk Eddelbuettel]

Doug Bates pointed me to this the other day: 

 http://julialang.org/

which will redirect to github at https://github.com/JuliaLang/julia

Looks promising, is open source (mostly MIT license) and pretty fast. Anybody
have spare time / bandwidth to think about packaging it?

Dirk

-- 
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-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20249.34552.742984.858...@max.nulle.part

Re: Bug#690544: ITP: xts -- GNU R package for time series analysis

[Dirk Eddelbuettel]

On 15 October 2012 at 14:37, Julien Cristau wrote:
| On Mon, Oct 15, 2012 at 20:13:33 +0800, Lifeng Sun wrote:
| 
|  Package: wnpp
|  Severity: wishlist
|  Owner: Lifeng Sun lifong...@gmail.com
|  X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org
|  
|  * Package name: xts

All (newer) R CRAN package use the r-cran-$foo naming style. Please follow
suit here too.

Dirk

|Version : 0.8-6
|Upstream Author : Jeffrey A. Ryan jeff.a.r...@gmail.com
|  Josh M. Ulrich
|  * URL : http://r-forge.r-project.org/projects/xts/
|  * License : GPL-2
|Description : GNU R package for time series analysis -- xts
|  
|  This package provide uniform handling of R's different time-based data
|  classes by extending r-cran-zoo, maximizing native format information
|  preservation and allowing for user level customization and extension,
|  while simplifying cross-class interoperability.
|  
| Any chance you could choose a better package name?  Something that hints
| at this being related to R.  xts to me is the X Test Suite, which has
| nothing to do with this.
| 
| Thanks,
| Julien
| application/pgp-signature [Press RETURN to save to a file]

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com  


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20604.2408.493280.118...@max.nulle.part

Re: Stupid fumble with bug numbers

[Dirk Eddelbuettel]

On 17 March 2013 at 08:55, Julien Puydt wrote:
| Hi,
| 
| I was horrified this morning to discover that fplll 4.0.1-2, which was 
| supposed to close bug #702898 (on fplll) was really closing bug #702056 
| (on polybori) : I put the wrong bug number in the changelog entry! :-(
| 
| What can I do to reopen the bug which was erroneously closed and close 
| the bug that really was, to correct the situation?

Try to read the docs on the Debian BTS which should rather immediately send
you to the mail interface; you can easily reopen the closed one and close the
one erroneously left open.
 
| I'm really sorry for the inconvenience,

We've all done it, no worries. Or else we didn't yet work on enough bugs :)

Dirk

| 
| Snark on #debian-science
| 
| 
| -- 
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
| Archive: http://lists.debian.org/514576fe.50...@laposte.net
| 

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com  


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20805.50685.689568.742...@max.nulle.part

Re: packaging stan

[Dirk Eddelbuettel]

On 3 August 2013 at 14:58, Ross Boylan wrote:
| Is stan building a shared or static library?
| 
| Yes.  Not sure which.

Almost surely shared because ...
 
|  If not, that may be the
| missing link between the two.  Requiring the stan source be present when
| building rstan (as a seperate source package) will not work or only work
| with lots of trouble I do not think is worth it.  So if there is no
| library being built or other support, combining both into one source
| package might be an option.
| 
| One indication this is alright would be that both stan and rstan are
| released in lockstep.
| 
| My understanding, which may be wrong, is that the stan system includes a
| compiler (stanc) that converts a stan program to C++ and then builds an
| executable from it.  The executable, and maybe stanc, need the stan library to
| run.
| 
| I think the rstan R package invokes stanc  behind the scenes and builds a
| library dynamically loadable in R.  Or possibly it just runs the compiled stan
| code. 

... because of the dynamically-linked modules.  The Stan folks use my Rcpp
package in the mix, and wrote an alternative implementation of inline to
store/cache compiled modules for their use.

That said, I know next to nothing about (R)Stan internals and builds. I am
not an (R)Stan user myself.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20989.33515.602809.541...@max.nulle.part

Re: Bug#737533: ITP: r-cran-rnetcdf -- GNU R package that provides an R Interface to NetCDF Datasets

[Dirk Eddelbuettel]

On 5 February 2014 at 14:20, Andreas Tille wrote:
| Hi Sebastian,
| 
| please consider maintaining the package in Debian Science team.
| 
| Moreover please enhance the long description since not every reader
| knows about netcdf and it just helps people who don't if they realise
| tht this package is not for them without doing additional research.

Also, there are three packages on CRAN interfacing the NetCDF library:

  RNetCDF
  ncdf4
  ncdf

I never know which one is maintained and good as I don't use NetCDF-store
data.  Maybe you do and RNetCDF is the clear winner -- if not take a quick
look at the other two please.

Cheers, Dirk
 
| Kind regards and thanks for your ITP
| 
|  Andreas.
| 
| On Mon, Feb 03, 2014 at 03:59:08PM +0100, Sebastian Gibb wrote:
|  Package: wnpp
|  Severity: wishlist
|  Owner: Sebastian Gibb sgibb.deb...@gmail.com
|  
|  * Package name: r-cran-rnetcdf
|Version : 1.6.1-2
|Upstream Author : Pavel Michna mic...@giub.unibe.ch
|  * URL : 
http://cran.r-project.org/web/packages/RNetCDF/index.html
|  * License : GPL=2
|Programming Lang: R
|Description : GNU R package that provides an R Interface to NetCDF 
Datasets
|  
|  This package provides an interface to Unidata's NetCDF library functions
|  (version 3) and furthermore access to Unidata's UDUNITS calendar 
conversions.
| 
| -- 
| http://fam-tille.de
| 
| 
| -- 
| To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
| with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
| Archive: http://lists.debian.org/20140205132020.ge26...@an3as.eu
| 

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21234.15996.977374.444...@max.nulle.part

Re: Bug#737533: ITP: r-cran-rnetcdf -- GNU R package that provides an R Interface to NetCDF Datasets

[Dirk Eddelbuettel]

On 5 February 2014 at 19:19, Sebastian Gibb wrote:
| On Wednesday 05 February 2014 14:37:00 Dirk Eddelbuettel wrote:
|  Also, there are three packages on CRAN interfacing the NetCDF library:
|  
|RNetCDF
|ncdf4
|ncdf
|  
|  I never know which one is maintained and good as I don't use NetCDF-store
|  data.  Maybe you do and RNetCDF is the clear winner -- if not take a quick
|  look at the other two please.
|
| ncdf is obsolete and superseded by ncdf4. Both ncdf4 and RNetCDF provide a 
good 
| interface to NetCDF.

Ack.

| I prefer RNetCDF because CRAN ships windows binaries of it, too. For reasons 
| unknown to me RNetCDF is built for windows but ncdf4 is not.

Generally the author(s)/maintainer have to extra effort. For two more
complicated CRAN packages of mine, we give CRAN static libs [for 32 and 64
bit windows] of the required external library.  [ In one case, RQuantLib, we
have done so for many years. For another, RProtoBuf, we only did so very
recently and a friend / co-author actually cross-built the windows libraries
on Ubuntu (and had to try three different g++-mingw versions; apparently only
4.7 worked) ]

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21234.33657.889153.601...@max.nulle.part

Re: Bug#761364: ITP: abc -- A System for Sequential Synthesis and Verification

[Dirk Eddelbuettel]

On 15 September 2014 at 17:33, Andreas Tille wrote:
| On Sat, Sep 13, 2014 at 11:38:48AM +0200, ruben.undh...@gmail.com wrote:
|  Please provide feedback on the naming of the package!
|  Perhaps the name abc is a bad name to use in debian although
|  it's the correct upstream name.
| 
| I admit I immediately stumbled upon this name but I fail to give a
| better alternative. 

Tricky.  

Wikipedia for 'abc' has seven entries in science and medicine alone, and
three more in math (with the last one a new-ish estimation technique).

Might be worthwile to prefix abc with something if anybody can come up with a
good value for somehting...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21527.3358.279069.703...@max.nulle.part

Re: copyright issues on debian

[Dirk Eddelbuettel]

On 12 October 2015 at 17:29, Drew Parsons wrote:
[...]
| argument, the question is whether GPL licenced software is allowed to
| link against GPL-licenced software.

Well put.

| When you read it that way, it might make it easier to understand why
| people aren't so worried about the violation. The violation is in the
| technicalities of the GPL versions.  That does matter in a legal sense.
| But for the non-legal majority it's a bit of a "whatEver".  The
| difference in attitud.  

There are packages by very senior R developers with _exactly_ the same
situation as r-cran-afex (and I will now refer to it under its CRAN name
'afex'): licensed as GPL3 only.  The majority of GPL-using packages, though,
use GPL (>=2).  And that is the spirit Drew so clearly refers.

I would just recommend that you get on with real work, or maybe take it up
with the CRAN maintainers.  Here at Debian you are splitting hairs, and most
of us just ignore endeavours such as this. We have real work to do.

Now, I happen to be a board member of the R Foundation, and we care about the
copyright of R itself.  CRAN, however, is a bit specialised in that it really
is a project by the 'team of CRAN maintainers' and is _not_ a formal part of
the R Project (mostly for historical reasons). So as such nobody but CRAN
speaks for CRAN and if you want to take the issue to them please feel free to
do so.  Just do not expect a guaranteed response from them either -- and Drew
layed out well why not.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: r-cran-rinside good to go

[Dirk Eddelbuettel]

On 2 September 2015 at 17:26, Andreas Tille wrote:
| Hi Jonathon,
| 
| On Wed, Sep 02, 2015 at 03:09:59PM +0200, Jonathon Love wrote:
| > > 
| > > I would have loved if the patch would have been discussed - IMHO it is
| > > sensible.
| > 
| > oh ok. still figuring out how much autonomy i'm supposed to exhibit. i
| > do like to lead with a concrete implementation - and was expecting it to
| > spur some discussion.
| 
| I admit I would love to see a simple solution for hardening in R
| packages.

I think the flags should just pass through.  Which bubbles up several levels
to R itself which has them from its configure:

edd@max:~$ grep stack /etc/R/Makeconf 
# configure  '--prefix=/usr' '--with-cairo' '--with-jpeglib' '--with-readline' 
'--with-tcltk' '--with-system-bzlib' '--with-system-pcre' '--with-system-zlib' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' 
'--datadir=/usr/share/R/share' '--includedir=/usr/share/R/include' 
'--with-blas' '--with-lapack' '--enable-R-profiling' '--enable-R-shlib' 
'--enable-memory-profiling' '--without-recommended-packages' '--build' 
'x86_64-linux-gnu' 'build_alias=x86_64-linux-gnu' 'R_PRINTCMD=/usr/bin/lpr' 
'R_PAPERSIZE=letter' 'R_BROWSER=xdg-open' 'LIBnn=lib' 
'JAVA_HOME=/usr/lib/jvm/default-java' 'CC=gcc -std=gnu99' 'CFLAGS=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-g' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=' 'F77=gfortran' 
'FFLAGS=-g -O2 -fstack-protector-strong' 'CXX=g++' 'CXXFLAGS=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-g' 'FC=gfortran' 'FCFLAGS=-g -O2 -fstack-protector-strong'
CFLAGS = -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -g $(LTO)
CXXFLAGS = -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -g $(LTO)
CXX1XFLAGS = -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -g
FCFLAGS = -g -O2 -fstack-protector-strong $(LTO)
FFLAGS = -g -O2 -fstack-protector-strong $(LTO)
SAFE_FFLAGS = -g -O2 -fstack-protector-strong -ffloat-store
edd@max:~$

So if these flags are left alone by the src/Makevars of an R package -- which
is the default -- then they should just pass through.

>From a random (but most recent) package log:

edd@max:~$ grep stack src/debian/build-logs/r-cran-quantreg_5.19-1.log 
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c akj.f -o akj.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c boot.f -o boot.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c brute.f -o brute.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG  -fpic  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-g  -c chlfct.c -o chlfct.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c cholesky.f -o cholesky.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c combos.f -o combos.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c crq.f -o crq.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c crqfnb.f -o crqfnb.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c dsel05.f -o dsel05.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c etime.f -o etime.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c extract.f -o extract.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c idmin.f -o idmin.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c iswap.f -o iswap.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c kuantile.f -o kuantile.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG  -fpic  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-g  -c mcmb.c -o mcmb.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c penalty.f -o penalty.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c powell.f -o powell.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rls.f -o rls.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rq0.f -o rq0.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rq1.f -o rq1.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rqbr.f -o rqbr.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rqfn.f -o rqfn.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rqfnb.f -o rqfnb.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rqfnc.f -o rqfnc.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c rqs.f -o rqs.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c sparskit2.f -o sparskit2.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG  -fpic  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-g  -c srqfn.c -o srqfn.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG  -fpic  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-g  -c srqfnc.c -o srqfnc.o
gfortran   -fpic  -g -O2 -fstack-protector-strong  -c srtpai.f -o srtpai.o
edd@max:~$

Given that the link step is missing it, this would point to 

Re: r-cran-rinside good to go

[Dirk Eddelbuettel]

On 2 September 2015 at 15:09, Jonathon Love wrote:
| fixed now. a lot of these R packages don't do you any favours coming up
| with a < 80 char description.

Simply a different (if related in spirit and scope) spec -- R itself has
rather stringent checks in 'R CMD check ...' which, not unlike lintian,
change and tighten over time. [ And unfortunately for sub-aspects of
Description to say the opposite with respect to full sentences. ]  I am one
of the folks behind a new R list 'r-package-devel' to discuss and help on the
CRAN side of these things.

For cran2deb (in its day) and Don's excellent successor at
http://debian-r.debian.net that is not an issue as those 7000+ thousand
package stay off the main Debian repo.  For packages you now upload to
Debian, fixes have of course to be made.  And lintian helps you.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: packaging an alternative R

[Dirk Eddelbuettel]

On 28 September 2015 at 13:15, Jonathon Love wrote:
| essentially, JASP depends on package A. package A gets updated in a way
| that breaks compatibility with us (this has happened to us with three
| different R packages making breaking changes between releases in the
| last couple of years, without warning).

That's plainly a Debian bug. "HEAD" of CRAN always works, and gets tested.

I have expressed my concerns about how 'laggy' updates to debian-science and
debian-med often enough in the past to not repeat this here again.  
 
| a nice solution is to provide a separate location where R packages (or
| even an alternative R itself) can be installed. JASP checks at start up

You don't need a new location, just use /usr/local/lib/R/site-packages. Which
is what I do at work and home (and via scripts in littler also rather easily).

However, that is entirely outside the packaging system so it does not make
sense to depend on it from "JASP the Debian package".

Rock, meet hard place.  You could just shelve the "JASP in Debian" idea, make
local packages for your users and provide these via a repo.  Others do that
too, see eg Jeroen and his (excellent) OpenCPU project:
http://www.opencpu.org and https://www.opencpu.org/download.html Or you could
ensure (by bug reports and package updates) that Debian packages are
installable for JASP.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: packaging an alternative R

[Dirk Eddelbuettel]

Also:  http://debian-r.debian.net  tends to have current packages.

You could (programmatically !!) compare the state of required CRAN packages
within Debian (my very small RcppAPT package on CRAN interfaces apt), compare
to what available.packages() in R says and maybe warn on discrepancy.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Bug#617296: RFP: rstudio -- IDE for GNU R

[Dirk Eddelbuettel]

FWIW I am very good and close friends with the RStudio founders and several
of their engineers.  But most (power R) users I know (myself included)
happily use their dailies from http://www.rstudio.org/download/daily/

It would be a lot of work to get (and keep) this packaged as RStudio found
over the years to often require newer-than-packaged tools like Qt, Boost,
and more. While it would be nice to see it packaged, maybe we have other more
urgent tasks.  Not sure.

Good luck anyway!

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: packaging an alternate R engine

[Dirk Eddelbuettel]

[ Suggestion: s/parallel/alternate/ as "parallel" has some other connotation
  in the context of computing / programming with data. ]

On 25 September 2015 at 14:35, Jonathon Love wrote:
| hi,
| 
| i'm wanting to create a deb package for a parallel R installation.
| 
| the software i'm working toward packaging, JASP, has some issues with
| the versions of R from CRAN, and i'd like to provide a parallel version

You know, you could talk to the package maintainer.  Just a thought.

| of R (based on the older ubuntu versions) that JASP can use, and make it

There is no 'based on older ubuntu version'.  You seem to just use older
packages for access to the then-current debian/ directory.

| available from my PPA.
| 
| this is also nice, because it means i can provide consistent R versions
| across, say, ubuntu versions, without forcing users to use a particular
| version.
| 
| i suspect this is at odds with the debian packaging philosophy, but how
| else does one handle these compatibility issues?

Just like with all other packages offering similar programs across different
packages.  The easiest is to simply NOT conflict on file names and
locations.  Because that would be serious packaging bug.

I *did* have an alternate package when the Jit patch for R was still
maintained by Stephen Milborrow [ it later clashed with changes in R's
internals which also made the need for the patch less compelling ].  Look for
r-base-core-ra.  If you can't find I do of course have sources at home too.

That would be the cleanest path.  We could (will ?) do the same with Radford
Neal's pqR (if there is interest), and once Google releases their CXXR-based
version (planned for the same time as R 3.3.0 next April).

I am fearful of modding the default R (from R Core) for fear of introducing
needless bugs in the transition.  There will for the foreseeable future be a
"main R" and we will keep that packaged as is. (Speaking with my maintainer
hat and my R Foundation board member hat. YMMV.)

| anyhow, i'm having difficulty modifying the existing source package to
| install to a different location.
| 
| i figure all i would need to do is add to r-base-core.dirs the lines:
| 
| usr/lib/JASP
| usr/lib/JASP/R
| 
| and to r-base-core.install the lines:
| 
| usr/lib/R/* usr/lib/JASP/R
| usr/share/* usr/lib/JASP/
| 
| and the files would be installed to the appropriate location (perhaps as
| well as to the old location).
| 
| but when i `dpkg -c` the resulting file, none of its contents are at the
| new location.
| 
| any tips on what i'm doing wrong?

See above. Just install to a different location, and provide a different
binary (well, script) than /usr/bin/R.  Think through carefully what you want
to do with packages as the default from the mainline R package may or may not
work for you if you use an older code base.

Dirk
 
| with thanks
| 
| jonathon
| 
| -- 
| 
| JASP - A Fresh Way to Do Statistics
| http://jasp-stats.org/
| 
| --
| 
| How happy is he born and taught,
| That serveth not another's will;
| Whose armour is his honest thought,
| And simple truth his utmost skill
| 
| This man is freed from servile bands
| Of hope to rise, or fear to fall:
| Lord of himself, though not of lands,
| And, having nothing, yet hath all.
| 
|   -- Sir Henry Wotton
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R

[Dirk Eddelbuettel]

On 29 March 2016 at 08:28, Andreas Tille wrote:
| Hi Chris,
| 
| On Mon, Mar 28, 2016 at 08:45:41PM -0400, Chris Lawrence wrote:
| > On Mon, Mar 28, 2016 at 9:21 AM, Andreas Tille  wrote:
| > > Thanks for this ITP since it is also on my list of needed packages for
| > > r-cran-treescape which needs several dependencies.  I have noticed
| > > that its even in NEW.  I wonder how you was able to build it without
| > > r-cran-bh since I also tried to package r-cran-dplyr[1] but I had the
| > > impression that r-cran-bh (#819389) would be required.
| > 
| > The short answer is... I cheated.
| 
| Ahhh. :-)
| 
| > I edited out the BH reference in LinkingTo in DESCRIPTION and made the
| > source package depend on libboost-all-dev (>= 1.58). Since all BH does
| > is package a subset of libboost-all-dev, it works even though it's a
| > minor hack of the upstream source. In principle, we should be able to
| > do the same with anything that uses LinkingTo that isn't (yet)
| > packaged with an r-cran-* shell package but we have Debian packages
| > for.
| > 
| > Dirk and I did talk about putting together an r-cran-bh that didn't
| > needlessly duplicate the libboost-*-dev packages it brings in, but I
| > don't know where that stands.
| 
| I talked about this with Dirk[1] and may be I should have done this for
| the moment as well.  Meanwhile Dirk has ITPed r-cran-bh (#819389) and
| has uploaded it to new - so this should be dealt with hopefully soon.

It is messy and I can see it two ways. It is good not to double up installed
size. It is bad to have a package behave differently -- eg users of a 'fake'
r-cran-bh in Debian would see a complete Boost and be tempted to include
headers users of the other one do not see.  Plus, small deltas. BH is at
1.60.0; Debian still uses 1.58.0.

Dirk

| It would be nice to have a look into your packaging anyway in the mean
| time.  So finding it in some VCS (see below) would be helpful.
|  
| > > It would be great if you would move your packaging to some VCS (for
| > > instance Debian Science).  I would volunteer to commit autopkg stuff
| > > which I've just prepared[1].
| > >
| > > Kind regards
| > >
| > >   Andreas.
| > >
| > > [1] 
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-dplyr/trunk/
| > 
| > One of these decades I'll have to learn how to use VCSes for
| > packaging. 
| 
| I'd recommend using Git in this case since there seem to be a tendency
| inside Debian into this direction.  While you can see from the URL above
| I started in SVN.  The rationale is that R packaging is in most cases
| simple enough that we keep only the debian/ dir which is in line with
| the usual workflow in SVN while the typical workflow in Git is to store
| upstream source and packaging in one repository.
| 
| Since I think r-cran-dplyr would be sensible inside the Debian Science
| team you can read how to do it in the Debian Science policy document[2].
| I would volunteer to inject your packaging into Debian Science Git if
| this would help you in the beginning.  If you want me to do this simply
| put somewhere online to enable me downloading it (while it resides in
| new).
| 
| Kind regards
| 
|  Andreas.
| 
| [2] 
https://debian-science.alioth.debian.org/debian-science-policy.html#idp45010192
| 
| -- 
| http://fam-tille.de
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R

[Dirk Eddelbuettel]

On 30 March 2016 at 13:34, Andreas Tille wrote:
| On Wed, Mar 30, 2016 at 06:21:55AM -0500, Dirk Eddelbuettel wrote:
| > 
| > | I talked about this with Dirk[1] and may be I should have done this for
| > | the moment as well.  Meanwhile Dirk has ITPed r-cran-bh (#819389) and
| > | has uploaded it to new - so this should be dealt with hopefully soon.
| > 
| > It is messy and I can see it two ways. It is good not to double up installed
| > size.
| 
| Could you please explain what size exactly is doubled?  As far as I
| understood r-cran-b would be just a wrapper for the Debian packaged
| libboost.

Nope. As I explained to you before and in this thread, there is downside in
differing from what is on CRAN.  So r-cran-bh, as packaged and so far only on
my box, does what every r-cran-* package does: include the CRAN package:

edd@max:~/src/debian/CRAN$ ls -lh /var/cache/pbuilder/result/*bh*
-rw-r--r-- 1 root root 5.6M Mar 27 17:25 
/var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1_all.deb
-rw-rw-r-- 1 edd  edd  2.4K Mar 27 17:25 
/var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1_amd64.changes
-rw-rw-r-- 1 edd  edd   379 Mar 27 16:58 
/var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1_amd64.local.upload
-rw-r--r-- 1 root root 4.1K Mar 27 17:24 
/var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1.diff.gz
-rw-rw-r-- 1 edd  edd  1.7K Mar 27 17:25 
/var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1.dsc
-rw-rw-r-- 1 edd  edd  9.2M Dec 28 08:13 
/var/cache/pbuilder/result/r-cran-bh_1.60.0-1.orig.tar.gz
edd@max:~/src/debian/CRAN$ 

But what is another 14mb between friends.
 
| > It is bad to have a package behave differently -- eg users of a 'fake'
| > r-cran-bh in Debian would see a complete Boost and be tempted to include
| > headers users of the other one do not see.  Plus, small deltas.
| 
| I totally fail to understand what you mean.

i)  BH is not a complete Boost. Never was, never will be. Headers only. And a
selected subset. So some non-Debian R users of BH would potentially see a
build including 'boost-foo' fail whereas we do.

ii) Small delta: 1.58 != 1.60.
 
| > BH is at
| > 1.60.0; Debian still uses 1.58.0.
| 
| That should be a temporary thing since 1.60.0 is in new[1].

We had BH 1.60 for several months now.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: R package CI test failures

[Dirk Eddelbuettel]

On 3 May 2016 at 22:53, Andreas Tille wrote:
| If we do not receive any hint from upstream removing this test seems to
[...]
| Hoping for upstream to respond to my first mail.  I might ping at
[...]
| I might ping upstream.
[...]

They won't know what you are talking about, and for a reason.  The R community
is pretty strict about testing and it (nowadays) _always_ involves

   R CMD check [possible switches]  somePackage_1.2-3.tar.gz

for which R correctly sets up input/output directories, permissions, finds
required files etc pp via a temporary installation during the test step.

If you now come to them and claim it 'fails to us' then that may well be due
to us doing things differently (ie /usr/share/R and /usr/lib/R; normally R
only has one which is why system.file("foo", package="bar") always finds foo
within bar's tree.

So what they release matches stringent and frequently repeated tests at their
end -- one of the reasons CRAN and BioConductor "just work".

The issue is pretty at your end by deploying the tests scripts in a different
way. Hence, I would go as far as suggesting not to contact upstream on this. 

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Need help with upgrading R package which verifies that the dir it builds in matches its name (r-bioc-tracklayer)

[Dirk Eddelbuettel]

On 9 May 2016 at 20:37, Andreas Tille wrote:
| Hi again,
| 
| I solved this by simply removing the whole configure script in a quilt patch.

That sounds crazy so I took a look.  BioConductor just had a 3.3 release
(matching the R release cycle) and they seemingly simplified it a lot.
Compare these two:

https://github.com/Bioconductor-mirror/rtracklayer/blob/release-3.2/configure.ac

https://github.com/Bioconductor-mirror/rtracklayer/blob/release-3.3/configure.ac

I did not look too closely at the older one but the newer does check for
OpenSSL present or not __and then uses this in src/Makevars.in__ so if it
were me I consider switching to this.  Or rather, I take the 'self-directory'
test out in 3.2.

Dirk 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Need help with upgrading R package which verifies that the dir it builds in matches its name (r-bioc-tracklayer)

[Dirk Eddelbuettel]

On 9 May 2016 at 21:10, Andreas Tille wrote:
| > Or rather, I take the 'self-directory'
| > test out in 3.2.
| 
| You probably mean 3.3, right?  Version 3.2 has no such test as far as I
| can see.

Sorry, meant whichever version (of rtracklayer) gave you that issue.  I would
rather not remove configure wholesale.

I am reasonably fluent at writing these so I may be able to help you just
modify the existing one by taking the offending test out, but I'm at work now
so ...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Debhelper for R packages

[Dirk Eddelbuettel]

On 9 September 2016 at 15:14, Gordon Ball wrote:
| On 09/09/16 14:17, Dirk Eddelbuettel wrote:
| > | The plan was to avoid seeing eg, lintian hardening-no-bindnow warnings
| > | on packages with compiled extensions. I tried injecting dpkg-buildflags
| > | LDFLAGS output into the MAKEFLAGS environment for R CMD INSTALL but it
| > | doesn't appear to work. It is possible this is also not particularly
| > | important (and/or might interfere with R's own build config) - I don't
| > | really see security as a major R issue.
| > 
| > It's an R issue. R "remembers" CC, CFLAGS, CXX, CXXFLAGS, etc pp from its
| > configure run and reuses them. When R runs 'R CMD INSTALL' you can add to
| > this on a per-package basis via the PKG_* variants from inside the package.
| > But we can't override from the outside.  Minor annoyance (ie would be nice 
to
| > strip '-g' sometimes, toggle -O2 for -O3, ...).  Needs an upstream change.
| 
| I understood (from how the CDBS makefile worked) that you could set an
| env var MAKEFLAGS encapsulating other build flags and it would be used.
| I was trying to use the same mechanism, ie
| 
| MAKEFLAGS=LDFLAGS=-z,now R CMD INSTALL ...
| 
| Is this mechanism no longer useable (or have I misunderstood what it
| should be able to do)?

Maybe. Let me revise to a "possibly". I think at a minimum you'd want "+=" to
not clobber LDFLAGS from R's Makeconf (on Debian in /etc/R/Makeconf -- do a
grep for LDFLAGS there, it is pretty fine frained...)
 
| Yes, I've read #752609 and I think I understood your meaning - that
| anything coming directly from CRAN/bioconductor should have fairly
| strong guarantees of correctness, and re-checking that at build time is
| extra unnecessary work for us.

Right. I don't want to say "don't do it" -- do whatever floats your boat --
but the marginal benefit may well be a lot lower than for other package
families.  That said, 'more tests' never make anything worse (apart maybe
from (ab)using a lot of human and system resources).

| (Although I suspect there must be some edge cases we might nevertheless
| catch at build-time, I can't admittedly come up with a concrete one
| right now).

We agree. It is possible, though maybe less likely.  In that sense,
additional work may be better spent on, say, this debhelperization. Or
figuring out how to help with repro or ...

| > | I am wondering if this should be interpreted as a tight dependency on
| > | the LinkingTo: package, eg
| > | 
| > | Built-Using: r-cran-rcpp (=version)or
| > | Depends: r-cran-rcpp (=version)
| > 
| > No.
| >  
| > | or if we need to trigger a transition when a package which can be the
| > | subject of LinkingTo: changes.
| > 
| > No.
| >  
| > | I'm speculating a bit here - I don't know how often this is a
| > | problem/how stable in practice package ABIs are. This might just be
| > | adding more work for a rare problem.
| > 
| > Yes.
| 
| That's a nice easy answer to those questions, thanks. No special
| treatment of this header needed, then.

I think a true C++ expert once explained a corner case to me where this does
matter and we'd need transitions etc pp -- I forget the details -- but I am
fairly positive we do _NOT_ need transitions etc in general for this.
Compile-time header use is more like static library use and orthogonalizes
things a little.  It is a real advantage.

Later,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Debhelper for R packages

[Dirk Eddelbuettel]

(chopping down a little to shorten)

On 9 September 2016 at 10:50, Gordon Ball wrote:
| On 08/09/16 23:25, Dirk Eddelbuettel wrote:
| > Our Depends also need to cover R's "Imports:" which we will not see via 
ldd. I
| > presume you have that covered, I just thought I'd mention it.
| 
| Yes, R:Depends includes both Imports and Depends.
| 
| Package resolution is just by looking if `r-{cran,bioc}-lc(packagename)`
| exists, and it doesn't generate an error if dependencies cannot be
| found, just prints a warning in the build log.
| 
| (It also will complain it can't find packages for internal namespaces,
| eg `stats`, but that should be fairly easy to add a check for).

Perfect. That's all that the various cran2deb implementations did.  [ BTW if
you care I actually have an interface from R to our APT backend in package
RcppAPT on GitHub/CRAN. Doesn't help with Perl, of course :) ]
 
| The plan was to avoid seeing eg, lintian hardening-no-bindnow warnings
| on packages with compiled extensions. I tried injecting dpkg-buildflags
| LDFLAGS output into the MAKEFLAGS environment for R CMD INSTALL but it
| doesn't appear to work. It is possible this is also not particularly
| important (and/or might interfere with R's own build config) - I don't
| really see security as a major R issue.

It's an R issue. R "remembers" CC, CFLAGS, CXX, CXXFLAGS, etc pp from its
configure run and reuses them. When R runs 'R CMD INSTALL' you can add to
this on a per-package basis via the PKG_* variants from inside the package.
But we can't override from the outside.  Minor annoyance (ie would be nice to
strip '-g' sometimes, toggle -O2 for -O3, ...).  Needs an upstream change.

| > I had once tried to bring some perspective from the R ecosystem to that, but
| > as I recall I pretty much failed to get my point across.  R already does /a
| > lot/ here via R CMD check, and it may be worthwhile to milk that angle 
rather
| > than to shoehorn R (which builds packages somewhat idiosyncratically) into
| > Debian's framework. Anyway, minor 'day 2' detail.
| 
| I suspect our testing is most interesting where non-R dependencies are
| concerned, particularly where we remove bundled copies and force the use
| of system ones.
| 
| As with vignette building below, it requires the set of build-deps to be
| much bigger (and particularly for bioconductor, tends to require big
| dataset packages available).

CRAN and BioConductor don't seem to know/care about chroot and minimal
environments. They tend to build on "fat" systems with everything installed.

But they also do it across three or more OSs which we don't so we can take
advantage of Linux tricks where they can't.

Some of the test philosophy is the same and hence redundant.  R cares a lot
about build "stability" and "possibility" (ie no API changes), we care a lot
about changes in the toolchain (and so do they). Eg Brian Ripley in Oxford
tends to also check again as-of-yet unreleased (!!) gcc versions to catch
things early (but those checks are extra -- at the core where tests are
automated they are more sensible).

| My workflow is to run autopkgtest (in an schroot) as a postbuild step,
| which tests the built deb (so no workaround for testing a not-yet
| installed package is required, and ensuring the binary dependencies are

I fully agree that chroot tests are good, but our build does thosse ...

| correct), and autodep8 ensures that there is at least a `library(RLIB)`
| test defined for every package.

... because as I tried to explain last time, _each_ R CMD INSTALL involved
in _each_ of our builds includes a load of the just built library. From what
I understood then and understand now you are duplicating that.  But I may
miss sufficient coffee...  Anyway
 
| (stdout from R CMD INSTALL includes "checking if the package can be
| loaded" or something like that, but I'm not sure what that is actually
| testing in practice)

The very 'library(foo)' for a the package r-cran-foo you are building.

Which checks dynamic linker as well as R aspects (as the R code needs to
syntactially parseable etc pp).  It is a good test.  I just fell over it
yesterday on one or two small packages I am building right now.
 
| > | > It might also be interesting to explore:
| > | > 
| > | >  * handling binary dependencies between R compiled extensions
| > | 
| > | What exactly do you mean here?  I admit I'd welcome if this dh module
| > | would be available in sid soon to enable switching packages to it to get
| > | it fully tested soon.  This kind of features might wait for later
| > | versions.
| 
| See, eg, r-cran-rprotobuf (LinkingTo: Rcpp) or r-bioc-biostrings
| (LinkingTo: IRanges).

Being the author of Rcpp which is used by 750+ CRAN packages via LinkingTo
(whereas we recommended Depends in the day), I am aware of its limitation. It
is (pretty much) R's version of Build-Depends for the C++ cas

Re: Debhelper for R packages

[Dirk Eddelbuettel]

Gordon, Andreas,

On 8 September 2016 at 22:37, Andreas Tille wrote:
| R is not team maintained and Dirk is not reading all threads on Debian
| Science - make sure you CC him (as I did) if you want to be sure he
| notices your mail.

Well ... procmail still sticks it into the same folder and I don't always
find time for this one.  But I saw the mail earlier. I am also CCing Don who
is (when he has servers) building thousands of r-*.deb packages automagically.

I second the upbeat mood.  This is good.  I would have preferred discussions
about design before standards get established -- but he who does the work get
to set the rules. That's you so far.

| > adding some possibly useful extras:
| > 
| >  * automatic substvars for known dependencies
| 
| That's very appreciated and helps definitely to prevent errors since
| sponsees as well as I myself forgot to sync Build-Depends with Depends
| (versioned and unversioned).  I verified that the package works as
| expected at least with the random example r-bioc-affy.

Our Depends also need to cover R's "Imports:" which we will not see via ldd. I
presume you have that covered, I just thought I'd mention it.

| >  * automatic generation of debian/ from an R package tarball
| 
| This could save even more time to create R packages and should prevent
| cut-n-pastos.
|  
| > I also intend to support, but haven't yet got working:
| > 
| >  * automatic handling of dpkg buildflags
| 
| To make sure I understand fully what you want to describe:  Are you
| talking about hardening flags etc?
| 
| >  * generation of autopkgtests without copy-paste errors
| 
| Cool!  What about running the tests also as Build time tests (see
| #752609).

I had once tried to bring some perspective from the R ecosystem to that, but
as I recall I pretty much failed to get my point across.  R already does /a
lot/ here via R CMD check, and it may be worthwhile to milk that angle rather
than to shoehorn R (which builds packages somewhat idiosyncratically) into
Debian's framework. Anyway, minor 'day 2' detail.

| > It might also be interesting to explore:
| > 
| >  * handling binary dependencies between R compiled extensions
| 
| What exactly do you mean here?  I admit I'd welcome if this dh module
| would be available in sid soon to enable switching packages to it to get
| it fully tested soon.  This kind of features might wait for later
| versions.
| 
| >  * (optionally) building vignettes
| 
| Might be nice for additional testing but also not really needed in
| a first usable version.

R user expect them, and get them when they install directly from CRAN.
|  
| > I have tested it with a reasonably large collection of d-science and
| > d-med R packages, from both bioconductor and CRAN, and it appears to
| > work.
| 
| I'd be happy if you would commit this work once dh-r is available to
| spare me some duplicated work.

To me github is as good / preferable. Other DDs have no issue developing via
GH. I'd maybe make alioth another remote or mirror.

| > However, this is pretty much my first stab at perl so it would
| > certainly benefit from oversight from someone with perl experience.
| > 
| > I would be interested to hear from R package maintainers 1) whether it
| > works and 2) any features not listed above which you would be useful.
| 
| I think I answered this above.

I am happy to help / advise as well. I am a somewhat active package author on
CRAN.  Happy to get this right, happy to also talk about re-starting Don's
effort to get ALL of CRAN into .deb (possibly via secondary repos).  There is
no reason we can't.

Gabor Csardi also builds every thing on r-hub (http://builder.r-hub.io)
[which still isn't fully released / deployed but "close" ]

| Thanks a lot for your very welcome work

>From me too.  Pushes the cart down the road in the right directly, and by a
good amount.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Debhelper for R packages

[Dirk Eddelbuettel]

On 8 September 2016 at 16:49, Don Armstrong wrote:
| On Thu, 08 Sep 2016, Dirk Eddelbuettel wrote:
| > On 8 September 2016 at 22:37, Andreas Tille wrote:
| > To me github is as good / preferable. Other DDs have no issue developing via
| > GH. I'd maybe make alioth another remote or mirror.
| 
| Yeah, I'd love to see this happen too; I actually started looking at
| supporting it, so you could just do:
| 
| %:
| dh --with r $@
| 
| and get on with writing the rest of the bits.

Exactly! (And you and I still need a weekend hackathon on it now that we
share a home state :)
 
| > | > However, this is pretty much my first stab at perl so it would
| > | > certainly benefit from oversight from someone with perl experience.
| > | > 
| > | > I would be interested to hear from R package maintainers 1) whether it
| > | > works and 2) any features not listed above which you would be useful.
| > | 
| > | I think I answered this above.
| > 
| > I am happy to help / advise as well. I am a somewhat active package author 
on
| > CRAN.  Happy to get this right, happy to also talk about re-starting Don's
| > effort to get ALL of CRAN into .deb (possibly via secondary repos).  There 
is
| > no reason we can't.
| 
| I'm also down to help out. It would be great if this would eventually
| make its way into r-base-dev (or similar) so that newer packages can
| just use it.

Ah yes, meant to mention that in my mail and forgot.  Happy to include files
in r-base-dev so that everybody has them automagically, also happy to just
add a Depends to pull this in via sub package.  We will figure something out.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Debhelper for R packages

[Dirk Eddelbuettel]

On 7 October 2016 at 15:09, Andreas Tille wrote:
| I'm fine with these changes.  If you want to let this propagate to all
| R+BioConductor packages probably a lintian warning makes sense.  May be

Really?  We don't have an officially sanctioned policy that _mandates_ this.

We are about giving people options.

| I'd prefer the repository on git.debian.org.

Sure, and some people prefer GitHub or Gitlab or their own git server.
Different strokes for different folks.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Debhelper for R packages

[Dirk Eddelbuettel]

On 8 October 2016 at 17:45, Joost van Baal-Ilić wrote:
| Otoh: currently R stuff is mainly maintained within debian-science and 
debian-med.  

Well: the R package itself, addons like ess, rpy2, rkward, ... , and several
dozen r-cran-packages maintained are not.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Debhelper for R packages

[Dirk Eddelbuettel]

On 7 October 2016 at 22:24, Dylan wrote:
| 2016-10-07 16:25 GMT+02:00 Gordon Ball <gor...@chronitis.net>:
| > On 07/10/16 15:33, Dirk Eddelbuettel wrote:
| >>
| >> On 7 October 2016 at 15:09, Andreas Tille wrote:
| >> | I'm fine with these changes.  If you want to let this propagate to all
| >> | R+BioConductor packages probably a lintian warning makes sense.  May be
| >>
| >> Really?  We don't have an officially sanctioned policy that _mandates_ 
this.
[...]
| There is the same thing on the Bioconductor page: "Canonical url for
| use in publications, etc., will always redirect to current release
| version (or devel if package is not in release yet)."

I wasn't clear here. I obviously have no issue with checks for the canonical
URL which CRAN now mandates and checks for in uploads to CRAN; I fixed many
of my (R upstream) packages already. So sure, that check is helpful.

I was gently objecting to making dh-r a mandate.  It's a new tool, so let's
give people a chance to try and use / improve it. Or not to if they prefer.
It's better if this evolves naturally than per fiat.

We may well all use it.  Time will tell.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Debhelper for R packages

[Dirk Eddelbuettel]

On 8 October 2016 at 20:01, Joost van Baal-Ilić wrote:
| I couldn't agree more.  I'm a cdbs fan, and some of my packages I maintain 
with
| neither cdbs nor dh.  So I was _very_ happy to find out cdbs was the tool used
| by many r-cran packages, when I started packaging r-cran stuff.  Don't get me
| wrong: I am happy we now can use dh to build r-cran packages: more choice is
| always welcome.  So: thanks a lot Gordon and Dylan for your work.  I however
| won't immediately start converting my r-cran packages from cdbs to dh-r.

Spot on, and agreed. Andreas et al did well with the updates to r-cran.mk,
and the cdbs approach is serving us well -- but needs an update. dh-r may fit
that bill.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

statistics: who maintains R packages in Debian (was: Re: Debhelper for R packages)

[Dirk Eddelbuettel]

On 8 October 2016 at 20:32, Joost van Baal-Ilić wrote:
| On Sat, Oct 08, 2016 at 12:08:50PM -0500, Dirk Eddelbuettel wrote:
| > On 8 October 2016 at 17:45, Joost van Baal-Ilić wrote:
| > | Otoh: currently R stuff is mainly maintained within debian-science and
| > | debian-med.  
| > 
| > Well: the R package itself, addons like ess, rpy2, rkward, ... , and several
| > dozen r-cran-packages maintained are not.
| 
| You're right, and I knew that.  The word "mainly" might have been not the 
right
| one; sorry about that.  
| 
| I got curious about who exactly maintains how many r-cran packages currently 
in
| testing/stretch, came up with this quick and (very!) crude hack:
| 
| joostvb@banach:~% for p in $( apt-cache search --names-only r-cran | \
|  cut -d' ' -f1 ); do echo -n "$p "; apt-cache show $p | grep Maintainer; done 
| \
|  cut -d' ' -f3- | cut -d\< -f2 | sed 's/^/
|   1 <i...@maintz.de>
|   1 <lifong...@gmail.com>
|   1 <ond...@debian.org>
|   2 <j...@debian.org>
|   7 <debichem-de...@lists.alioth.debian.org>
|  19 <lawre...@debian.org>
| 105 <debian-science-maintain...@lists.alioth.debian.org>
| 130 <e...@debian.org>
| 137 <debian-med-packag...@lists.alioth.debian.org>

That's a very good start; you may also want to look at 'apt-cache rdepends
r-base-core' (and maybe r-base) to get the r-bioc-* and r-other-* packages.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: What's the difference between CRAN Cairo and cairoDevice

[Dirk Eddelbuettel]

Hi Andreas,

[ Lucky I found this -- procmail sticks this into the debian-science folder
which I do not visit as often as my normal inbox ... ]

On 18 August 2016 at 08:52, Andreas Tille wrote:
| Hi Dirk,
| 
| I've got a request to install Cairo[1] which from the description sounds
| pretty similar to your package r-cran-cairodevice from[2].  Both R
| packages seem to be maintained.  Could you explain the difference and
| do you think its sensible to package Cairo in addition?

Yes, see 

  https://cloud.r-project.org/package=Cairo
  https://cloud.r-project.org/package=cairoDevice

These are simply two similar and somewhat overlapping packages.

CRAN is not unlike Debian in that such feature overlap is not policed against
(and that is a good thing).  As I recall, Cairo is newer.

I once needed cairoDevice so I packaged it -- if you now have a rev.dep on
Cairo you will have to package that.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: statistics: who maintains R packages in Debian (was: Re: Debhelper for R packages)

[Dirk Eddelbuettel]

On 18 October 2016 at 18:28, Andreas Tille wrote:
| On Tue, Oct 18, 2016 at 06:27:13PM +0300, Michael Crusoe wrote:
| > > > r-other-hms-dbmi-spp
| > > >
| > > > It is _a lot_ easier for all of us if we only have top-level
| > > >
| > > > r-cran-*
| > > > r-bioc-*
| > > > r-other-*
| > 
| > Sounds like a great plan. Where shall we document it?
| 
| Its some undocumented convention (as far as I know).  R packaging is not

https://lists.debian.org/debian-devel/2003/12/msg02332.html

| well documented (one of the tasks a potential R packaging team could be
| to write an R packaging policy or at least a sensible Wiki page,

You don't have to have a team to write a Policy document.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: statistics: who maintains R packages in Debian (was: Re: Debhelper for R packages)

[Dirk Eddelbuettel]

Shouldn't the new package

r-hms-dbmi-spp

been renamed

r-other-$author-$package

ie

r-other-hms-dbmi-spp

It is _a lot_ easier for all of us if we only have top-level

r-cran-*
r-bioc-*
r-other-*

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: statistics: who maintains R packages in Debian (was: Re: Debhelper for R packages)

[Dirk Eddelbuettel]

On 18 October 2016 at 15:26, Andreas Tille wrote:
| I agree and put the right address in To: field...

I replied on the mailing list *I* am subscribed on and would have preferred
it if you followed common email etiquette of not dropping it.  This is now in
the wrong thread and the wrong folder.  That is almost as bad your top-reply ;-)

Dirk

| On Tue, Oct 18, 2016 at 06:58:15AM -0500, Dirk Eddelbuettel wrote:
| > 
| > Shouldn't the new package
| > 
| > r-hms-dbmi-spp
| > 
| > been renamed
| > 
| > r-other-$author-$package
| > 
| > ie
| > 
| > r-other-hms-dbmi-spp
| > 
| > It is _a lot_ easier for all of us if we only have top-level
| > 
| > r-cran-*
| > r-bioc-*
| > r-other-*
| > 
| > Dirk
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > 
| 
| -- 
| http://fam-tille.de

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: ITP: r-cran-bh -- GNU R package with Boost headers

[Dirk Eddelbuettel]

On 3 December 2016 at 08:51, Andreas Tille wrote:
| Hi Dirk,
| 
| I just realised that this ITP seems not to be closes.  I somehow forgot
| this since the former requirement I had for this package seems to have
| vanished.  However, my attempt to upgrade r-cran-rsqlite to its latest
| upstream version due to the missing r-cran-bh.

Done! 

Let's hope it passes NEW.  I am a little worried I may have to extract
copyright information from thousands of header files ...  Worst case we could
still do what we discussed once and have r-cran-bh be a Debian-specific
'wrapper' depending on our Boost header packages.  But I don't like that as
the R builds would then [potentially] behave differently.

| Do you intend to upload this soon to enable me upgrading r-cran-rsqlite?

The other option is to just edit it out of DESCRIPTION.  There will never be
any R code coming from BH; it is (really !!) just a way (for R) to set the -I
flag for the compiler -- and we have that covered differently.

But on balance I still prefer to package CRAN 'as is'.  That is the better
way (even if marginally 'less Debian')

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Status of dh-r and problems building r-cran-yaml

[Dirk Eddelbuettel]

On 5 December 2016 at 17:57, Gordon Ball wrote:
| On 01/12/16 09:46, Andreas Tille wrote:
| > However, yesterday I stumbled upon r-cran-yaml[1] which causes a problem
| > I was not able to solve quickly.  Upstream has injected an additional
| > declaration to the code copy of libyaml which I injected via quilt patch
| > right into the C code which now enables building the code.  Strangely
| > enough the resulting library does not end up in the target directory
| > location - or at least R can't find it there and the issue is hard to
| > debug since at the point when the build process gets control again and I
| > get a shell the files in questions are just removed by the Makefile:
| > 
| > ** libs
| > make[1]: Entering directory '/build/r-cran-yaml-2.1.14+dfsg/src'
| > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic  -g 
-O2 -fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -
| > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic  -g 
-O2 -fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -
| > gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o yaml.so implicit.o 
r-ext.o -lyaml -L/usr/lib/R/lib -lR
| > make[1]: Leaving directory '/build/r-cran-yaml-2.1.14+dfsg/src'
| > make[1]: Entering directory '/build/r-cran-yaml-2.1.14+dfsg/src'
| > make[1]: Leaving directory '/build/r-cran-yaml-2.1.14+dfsg/src'
| > installing to 
/build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml/libs
| > ** R
| > ** inst
| > ** preparing package for lazy loading
| > ** help
| > *** installing help indices
| > ** building package indices
| > ** testing if installed package can be loaded
| > Error in dyn.load(file, DLLpath = DLLpath, ...) :.
| >   unable to load shared object 
'/build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml/libs/yaml.so':
| >   
/build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml/libs/yaml.so:
 undefined symbol: yaml_emitter_set_indent_mapping_sequence
| > Error: loading failed
| > Execution halted
| > ERROR: loading failed
| > * removing 
'/build/r-cran-yaml-2.1.14+dfsg/debian/r-cran-yaml/usr/lib/R/site-library/yaml'
| > 
| > 
| > I admit my poor wisdom ends here.  Any clue?
| 
| Nothing from a quick look. I'll have a longer look tonight or tomorrow
| and see if I can spot anything.

Using (the command-line shorthand tool from my littler package)

  $ install.r yaml

on a shell works fine in Ubuntu 16.04 (at work) as well as in a quickly
fired-up Docker container (using the official r-base image I co-maintaim)
based on Debian testing (see below).

So it looks like it is not the yaml CRAN package. No smoking gun here :-/

Dirk


$ docker run --rm -ti r-base /bin/bash
root@44037b347f37:/# apt-get update
Get:1 http://security.debian.org testing/updates InRelease [68.2 kB]
Get:3 http://deb.debian.org/debian testing InRelease [175 kB]
Get:2 http://debian.gtisc.gatech.edu/debian sid InRelease [223 kB]
Get:4 http://deb.debian.org/debian testing-updates InRelease [88.5 kB]
Get:5 http://deb.debian.org/debian testing/main amd64 Packages [9,327 kB]
Get:6 http://debian.gtisc.gatech.edu/debian sid/main amd64 Packages [9,877
kB]
Fetched 19.8 MB in 4s (4,847 kB/s)
Reading package lists... Done
root@44037b347f37:/# install.r yaml
trying URL 'https://cran.rstudio.com/src/contrib/yaml_2.1.14.tar.gz'
Content type 'application/x-gzip' length 81095 bytes (79 KB)
==
downloaded 79 KB

* installing *source* package ‘yaml’ ...
** package ‘yaml’ successfully unpacked and MD5 sums checked
** libs
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic  -g -O2
*-fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong -Wformat
*-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c api.c -o
*api.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic  -g -O2
*-fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong -Wformat
*-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c dumper.c -o
*dumper.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic  -g -O2
*-fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong -Wformat
*-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c emitter.c -o
*emitter.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic  -g -O2
*-fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong -Wformat
*-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c implicit.c -o
*implicit.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -DNDEBUG -fpic  -g -O2
*-fdebug-prefix-map=/build/r-base-3.3.2=. -fstack-protector-strong -Wformat
*-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c loader.c -o
*loader.o
gcc -std=gnu99 

Re: Bug#862039: r-bioc-gviz: accesses the internet during build

[Dirk Eddelbuettel]

On 9 May 2017 at 14:57, Andreas Tille wrote:
| Hi Chris,
| 
| On Sun, May 07, 2017 at 06:06:10PM +0100, Chris Lamb wrote:
| > 
| > Whilst r-bioc-gviz builds successfully on unstable/amd64, according to
| > Debian Policy 4.9 packages may not attempt network access during
| > a build.
| > 
| >00:00:00.00 IP 5f02d4499efa.36140 > dns.z9.domain: 4778+ A? 
bioconductor.org. (34)
| >00:00:00.51 IP 5f02d4499efa.36140 > dns.z9.domain: 45901+ ? 
bioconductor.org. (34)
| >00:00:01.725656 IP dns.z9.domain > 5f02d4499efa.36140: 45901 0/1/0 (121)
| >00:00:03.219280 IP dns.z9.domain > 5f02d4499efa.36140: 4778 8/4/0 A 
52.222.253.6, A 52.222.253.158, A 52.222.253.218, A 52.222.253.224, A 
52.222.253.45, A 52.222.253.252, A 52.222.253.94, A 52.222.253.219 (298)
| >00:00:03.306580 IP 5f02d4499efa.8 > 52.222.253.6.https: Flags [S], 
seq 4243355363, win 29200, options [mss 1460,sackOK,TS val 493652159 ecr 
0,nop,wscale 7], length 0
| >00:00:03.347988 IP 52.222.253.6.https > 5f02d4499efa.8: Flags [S.], 
seq 1407308632, ack 4243355364, win 28960, options [mss 1412,sackOK,TS val 
1448496045 ecr 493652159,nop,wscale 8], length 0
| >00:00:03.348046 IP 5f02d4499efa.8 > 52.222.253.6.https: Flags [.], 
ack 1, win 229, options [nop,nop,TS val 493652169 ecr 1448496045], length 0
| >00:00:03.450001 IP 5f02d4499efa.8 > 52.222.253.6.https: Flags [P.], 
seq 1:518, ack 1, win 229, options [nop,nop,TS val 493652195 ecr 1448496045], 
length 517
| >00:00:03.491891 IP 52.222.253.6.https > 5f02d4499efa.8: Flags [.], 
ack 518, win 118, options [nop,nop,TS val 1448496060 ecr 493652195], length 0
| >00:00:03.495857 IP 52.222.253.6.https > 5f02d4499efa.8: Flags [.], 
seq 1:1401, ack 518, win 118, options [nop,nop,TS val 1448496060 ecr 
493652195], length 1400
| > 
| >   [..]
| > 
| > The full build log (including tcpdump output) is attached.
| 
| I can confirm that the build log contains
| 
|   URL 'http://bioconductor.org/BiocInstaller.dcf': status was 'Couldn't 
connect to server'
| 
| when using pbuilder or sbuild.  I guess the problem remained hidden
| since so far nobody did a tcpdump while building the package and since
| the build runs fine after checking that the resource is not available
| nobody noticed so far.
| 
| I admit I'm a bit clueless how to fix the issue since the build process
| of R packages is a bit "encapsulated" and I'm afraid about simply
| seeking the said URL and patching it out.  I'm not sure about the
| potential side effects for the resulting deb at package installation
| time.
| 
| Thus I'm forwarding the bug to Debian Science list for further advise.

I am fairly certain that this must be coming from the BioConductor side of
things.  R does call 'home' when you 'R CMD check --as-cran', but we of
course do not do that during builds.  We just call 'R CMD INSTALL ...'

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Upcoming new round of R package rebuilds [FWD: [Rd] R-devel object header changes that require reinstalling packages]

[Dirk Eddelbuettel]

On 18 September 2017 at 22:41, Charles Plessy wrote:
| Hello everybody,
| 
| I just wanted to relay the information that some R packages will need a
| rebuild after the next upgrade of R.  (see the email forwarded below.)

Common knowledge. I referenced it half-a-dozen times in the damned thread
about the binNMUs.  The ALTREP branch for R was announced as coming earlier
in the year, and is now in the r-devel master branch (ie R upstream).

We will switch to r-api-4 then which will finally break the effing block
posed upon by the release team in response to the 'R 3.4.0 has a change' bug
report by Johannes.

| (By the way, I apologise in advance that I am being crushed for time
| currently and will not be able to help much).

This will happen in April 2018.  Hopefully you will have more spare cycles then.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Upcoming new round of R package rebuilds [FWD: [Rd] R-devel object header changes that require reinstalling packages]

[Dirk Eddelbuettel]

On 19 September 2017 at 14:15, Johannes Ranke wrote:
| > But you escalated it
| 
| Mhm. I reported a bug with severity "normal". Maybe the language I used was 
| too dramatic?

The whole bug report was, pardon my French, complete and utter nonsense. The
folks who needed to know already knew.

But you increased the visibiity, and as a consequence you have now "freed"
all testing users from a current version of R.

| > And the net effect is no current R in testing for a year.  Really not a good
| > outcome.
| 
| This could still be overcome by introducing versioned Breaks,

I will not introduce Breaks for 100+ packages. It will only create
unanticipated side effects I as the maintainer the have to clean up.

That is a firm no.

I will also stop with the completely useless thread now. 

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Upcoming new round of R package rebuilds [FWD: [Rd] R-devel object header changes that require reinstalling packages]

[Dirk Eddelbuettel]

On 19 September 2017 at 11:07, Johannes Ranke wrote:
| Am Montag, 18. September 2017, 10:39:02 CEST schrieb Dirk Eddelbuettel:
| > Common knowledge. I referenced it half-a-dozen times in the damned thread
| > about the binNMUs. 
| 
| This (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868558) had
| escaped my attention, maybe others on this list had not seen it either?

I must have posted about a dozen times around it, and it is about as R
centric as it gets.  I have said everything I want to say about it, really
but briefly:

| The R 3.4.0 you uploaded to unstable broke packages from existing 
| installations (unstable). If you now say that I reported a change, not a bug, 

All it required was a set of _local_ package rebuilds. Which we could have
handled easily as per that report #868558.

But you escalated it, made it appear on the radar of the release team who do
what they do.

And the net effect is no current R in testing for a year.  Really not a good 
outcome.

And no, it wasn't an ABI change even if people repeat that ad nauseum.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)

[Dirk Eddelbuettel]

On 12 October 2017 at 14:26, Andreas Tille wrote:
| On Thu, Oct 12, 2017 at 07:06:33AM -0500, Dirk Eddelbuettel wrote:
| > 
| > On 12 October 2017 at 11:36, Andreas Tille wrote:
| > | yesterday you uploaded
| > | 
| > |   r-cran-rcpparmadillo 0.8.100.1.0-1
| > | 
| > | In the interest to close the transition bug opened you opened yourself
| > 
| > s/opened//   to make it a sentence
| > 
| > s/you/Seb/   to make it correct.  Not my transition at all.
| 
| 
| Debian Bug report logs - #868558
| transition: r-api-3.4
| Package: release.debian.org; Maintainer for release.debian.org is Debian 
Release Team <debian-rele...@lists.debian.org>;
| Reported by: Dirk Eddelbuettel <e...@debian.org>
| 
| 
| Could you please regardless whether you consider yourself involved into
| the bug that lists you as reporter respect the intention of your fellow
| DDs to finalise the transition and wait with uploading new r-* packages.

You. Still, Don't. Get. It.

I argued for several weeks for a more surgical binNMUs of 46 packages.  But
it was decided that we needed to force a rebuild of 500+ packages instead.

I proposed the former.  You talk about the latter.  You don't seem to
understand that they are not the same.

Dirk

| 
| Thank you
| 
|   Andreas.
| 
| -- 
| http://fam-tille.de

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)

[Dirk Eddelbuettel]

On 12 October 2017 at 11:36, Andreas Tille wrote:
| Hi Dirk,
| 
| yesterday you uploaded
| 
|   r-cran-rcpparmadillo 0.8.100.1.0-1
| 
| In the interest to close the transition bug opened you opened yourself

s/opened//   to make it a sentence

s/you/Seb/   to make it correct.  Not my transition at all.

Dirk


| it would be helpful if you would not upload r-* packages as long as the
| testing migration has not happened.
| 
| Thank you
| 
|  Andreas.
| 
| On Sat, Sep 23, 2017 at 11:58:20AM -0500, Dirk Eddelbuettel wrote:
| > 
| > See below for upcoming R 3.4.2 "pre-release" change.
| > 
| > I still consider this to be techically inferior and conceptually wrong and
| > inadequate, but there is little else than I can do about it.
| > 
| > May I assume that some of you who sp tiredlessly argued for it will now 
liase
| > with the release team to get 500+ forcefully rebuilt?
| > 
| > Dirk
| > 
| > 
| > r-base (3.4.1.20170921-1) unstable; urgency=medium
| > 
| >   * Initial rc build (r73337) of R 3.4.2 expected for Sep 28
| > 
| >   * debian/control: Package r-base-core now 'Provides: r-api-3.4' per the
| > Debian Release team. I still consider this to be wrong (as there was
| > no API change) but my hands are tied here.
| > 
| >   * debian/compat: Increased to 9
| > 
| >  -- Dirk Eddelbuettel <e...@debian.org>  Sat, 23 Sep 2017 11:49:56 -0500
| > 
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > 
| > 
| 
| -- 
| http://fam-tille.de

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Why does r-cran-rcppgsl not migrate to testing?

[Dirk Eddelbuettel]

On 8 September 2017 at 22:47, Andreas Tille wrote:
| Hi Dirk,
| 
| On Thu, Sep 07, 2017 at 02:46:04PM -0500, Dirk Eddelbuettel wrote:
| > 
| > On 7 September 2017 at 21:20, Andreas Tille wrote:
| > | Hi Dirk,
| > | 
| > | On Wed, Sep 06, 2017 at 04:22:33PM -0500, Dirk Eddelbuettel wrote:
| > | > On 6 September 2017 at 22:48, Andreas Tille wrote:
| > | > | On Wed, Sep 06, 2017 at 10:17:04AM -0500, Dirk Eddelbuettel wrote:
| > | > | > 
| > | > | > | Is there any list of affected packages?
| > | > | > 
| > | > | > I gave this URL about half a dozen times:
| > | > | > 
| > | > | >   http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html
| > | > | 
| > | > | Well, you know from own experience that not all information is 
reaching
| > | > | the target audience.  It might have helped to address Debian Science 
and
| > | > | Debian Med team to make some more noise.
| > | > |  
| > | > | > It contains the list, as well as a way to compute it.
| > | 
| > | Any chance to recompute the list just in case somebody else has also
| > | upgraded a package?  It would be nice if the list would have a timestamp
| > | of creation.
| > 
| > It should just work -- the write up is after all hanging off the RcppAPT
| > repo, so just install RcppAPT and then you can query R _and Debian_ from R.
| > The one step Prof Hornik suggested required CRAN sources to grep, but I 
think
| > I in the last iteration I proxied that by just fetching the .tar.gz from
| > CRAN.  Or at least it could be done.
| > 
| > If you have a question about RcppAPT maybe just open an issue at GitHub.
| 
| Dirk, you misunderstood my query:  I was asking you for upgrading your
| list which is now heavily outdated not how I can learn a tool.  You
| explained how often you linked to your page - a that frequently linked
| page should be up to date to avoid others from trying to pick up work
| that is now done.
| 
| Please try to understand that if you want to attract people to work on a
| common goal with you you should try to make their work as easy as
| possible.
|  
| > I'll be traveling this weekend so not sure I'll get to that before next 
week.
| >  
| > | > | The list is not fully up to date.  I recently uploaded a new version 
of
| > | > | r-cran-randomfields which remains inside the list.  I need to admit a
| > | > | shorter page which points directly to tasks to do which is up to date
| > | > | would be more motivating to lend a helping hand.
| > | > | 
| > | > | I just uploaded
| > | > | 
| > | > |r-cran-spdep
| > | > |r-cran-gam
| > | > |r-cran-mcmc
| > | 
| > | I uploaded as well:
| > | 
| > |   r-cran-data.table
| > |   r-cran-vegan
| > |   r-cran-bayesm
| > |   r-cran-expm
| > |   r-cran-phangorn
| > |   r-cran-maptools
| > |   r-cran-caret
| > |   r-cran-goftest
| > |   r-cran-igraph
| > |   r-cran-maps
| > |   r-cran-eco
| > |   r-cran-randomfields
| > |   r-bioc-genefilter
| 
| I worked down the whole list with exception of your own package
| r-cran-hdf5 and for two remaining packages I needed to package new

Thank you for updating the packages. I missed hdf5 as it is "special" --
orphaned upstreamed. I think there are newer hdf5 packages in BioConductor we
should probably try to switch to.

I never listed the remaining ones by maintainer. Mayne I will.

But as I said, traveling -- at my daughter's college and just between giving
two talks.

| dependencies.  I've pinged #debian-ftp on IRC asking for fast
| processing.
|  
| > That helps with the open bug report, thank you!  As you know I'd also love 
to
| > see them be current. I find with my r-cran-* packages (of which I have
| > several dozen) that it only takes a couple of minutes each time so I
| > generally do.
| 
| I admit that some packages took a bit longer in case of the team hijacks
| I did (Chris I keep on assuming that this is OK for you).  I also had to
| deal with binary files that should be documented in README.source (I
| wished we had a Debian R team clarifying things with ftpmaster in a more
| packagers friendly way).
| 
| Regarding your response below:  Dirk, I consider my own time to valuable
| to correct your offending accusations.  I felt it way better spent by
| just fixing the packages.  I have some ideas how we could enhance the
| situation but I'm not willing to discuss with you if you always turn to
| pointless insulting accusations.

Factually incorrect as I never say anything personal about you.

But I *will* point out poorly maintained packages (e.g. missing months worth
updates) as that is a simple observable fact.

I have put 15+ plus into maintaining R in a timely manner. I cannot recommend
people use r-cran-* packages as many simply stale. I still find th

Re: Why does r-cran-rcppgsl not migrate to testing?

[Dirk Eddelbuettel]

Andreas,

Mail CC'ed to debian-science goes into the debian-science folder which I
don't regularly open, so sorry for the delay.  If in doubt or if I don't
reply please email (or DM) me directly,

On 2 September 2017 at 16:17, Andreas Tille wrote:
| according to
| 
| https://qa.debian.org/excuses.php?package=r-cran-rcppgsl
| 
| r-cran-rcppgsl does not migrate to testing but I admit I do not really
| understand what to do.  Could you please have a look?

It is not just r-cran-rcppgsl -- but r-base 3.4.1 itself.

It is a trivial "monstly non-bug" bug report. But the release team won't act,
so I am now resigned to waiting.  I explained the case in

  https://bugs.debian.org/868558

and particularly in this write-up

  http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

which has a more fine-grained analysis.

I can actually no longer replicate the original issue 

  https://bugs.debian.org/861333

with any of the few (40-some now) packages still affected. They load and
function too for me.  (My test was not exhaustive though).

I am frustrated, but I can not get any change to happen. I tried an email to
debian-devel last week, but to no avail.

On 2 September 2017 at 16:22, Mattia Rizzolo wrote:
| That's due to #861333
| The solution would be some dozen binNMUs, that for some reason the
| release team is unhappy to schedule.  See https://bugs.debian.org/868558
| for the fuller story.

Exactly.

On 2 September 2017 at 16:25, Sébastien Villemot wrote:
| This is because of #861333 (essentially an ABI breakage). r-base is therefore
| prevented to migrate to testing, and since R packages have a tight dependency
| on the latest version of R, they cannot migrate either. Lots of R packages are
| currently stuck in unstable for that reason.

People keep waving the "ABI breakage" flag but it is really just a
garden-variety bug in R affecting __a subset of a subset__.

Dirk, frustrated

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Why does r-cran-rcppgsl not migrate to testing?

[Dirk Eddelbuettel]

On 6 September 2017 at 15:12, Mattia Rizzolo wrote:
| On Wed, Sep 06, 2017 at 07:37:07AM -0500, Dirk Eddelbuettel wrote:
| > It is a trivial "monstly non-bug" bug report. But the release team won't 
act,
| > so I am now resigned to waiting.  I explained the case in
| > 
| >   https://bugs.debian.org/868558
| > 
| > with any of the few (40-some now) packages still affected. They load and
| > function too for me.  (My test was not exhaustive though).
| > 
| > I am frustrated, but I can not get any change to happen. I tried an email to
| > debian-devel last week, but to no avail.
| 
| I wonder, what's blocking you from just sourcefully uploading all of
| those packages? Being only 40 would make it quite feasible IMO, and I
| bet there could be something you could change too (worse case, you could
| just bump Std-Ver :P).

I rather seriously considered it. I need a free weekend (not this one), and
maybe a volunteer (or two) to help.  We could just fetch the respective
packages, do a manual .1 version and upload to the DELAYED queue.  Shall we?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Why does r-cran-rcppgsl not migrate to testing?

[Dirk Eddelbuettel]

On 6 September 2017 at 16:49, Andreas Tille wrote:
| On Wed, Sep 06, 2017 at 07:37:07AM -0500, Dirk Eddelbuettel wrote:
| > I can actually no longer replicate the original issue 
| > 
| >   https://bugs.debian.org/861333
| > 
| > with any of the few (40-some now) packages still affected. They load and
| > function too for me.  (My test was not exhaustive though).
| 
| Is there any list of affected packages?

I gave this URL about half a dozen times:

  http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

It contains the list, as well as a way to compute it.

| I intend to refresh with new upstream sources anyway in the next couple of 
days.  May be we can do
| real uploads of most of the packages ourselves? 

Please do. Being behind upstream is essentially never a good idea.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Why does r-cran-rcppgsl not migrate to testing?

[Dirk Eddelbuettel]

Hi Andreas,

On 7 September 2017 at 21:20, Andreas Tille wrote:
| Hi Dirk,
| 
| On Wed, Sep 06, 2017 at 04:22:33PM -0500, Dirk Eddelbuettel wrote:
| > On 6 September 2017 at 22:48, Andreas Tille wrote:
| > | [Chris, I took the freedom to move r-cran-mcmc to Debian Science
| > |  team since I had the impression that this would generally OK for
| > |  you.]
| > | 
| > | Hi Dirk,
| > | 
| > | On Wed, Sep 06, 2017 at 10:17:04AM -0500, Dirk Eddelbuettel wrote:
| > | > 
| > | > | Is there any list of affected packages?
| > | > 
| > | > I gave this URL about half a dozen times:
| > | > 
| > | >   http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html
| > | 
| > | Well, you know from own experience that not all information is reaching
| > | the target audience.  It might have helped to address Debian Science and
| > | Debian Med team to make some more noise.
| > |  
| > | > It contains the list, as well as a way to compute it.
| 
| Any chance to recompute the list just in case somebody else has also
| upgraded a package?  It would be nice if the list would have a timestamp
| of creation.

It should just work -- the write up is after all hanging off the RcppAPT
repo, so just install RcppAPT and then you can query R _and Debian_ from R.
The one step Prof Hornik suggested required CRAN sources to grep, but I think
I in the last iteration I proxied that by just fetching the .tar.gz from
CRAN.  Or at least it could be done.

If you have a question about RcppAPT maybe just open an issue at GitHub.

I'll be traveling this weekend so not sure I'll get to that before next week.
 
| > | The list is not fully up to date.  I recently uploaded a new version of
| > | r-cran-randomfields which remains inside the list.  I need to admit a
| > | shorter page which points directly to tasks to do which is up to date
| > | would be more motivating to lend a helping hand.
| > | 
| > | I just uploaded
| > | 
| > |r-cran-spdep
| > |r-cran-gam
| > |r-cran-mcmc
| 
| I uploaded as well:
| 
|   r-cran-data.table
|   r-cran-vegan
|   r-cran-bayesm
|   r-cran-expm
|   r-cran-phangorn
|   r-cran-maptools
|   r-cran-caret
|   r-cran-goftest
|   r-cran-igraph
|   r-cran-maps
|   r-cran-eco
|   r-cran-randomfields
|   r-bioc-genefilter

That helps with the open bug report, thank you!  As you know I'd also love to
see them be current. I find with my r-cran-* packages (of which I have
several dozen) that it only takes a couple of minutes each time so I
generally do.

| For those who want to help but have no idea how to do a team upload:
| 
|   debcheckout --user  --git-track '*' 
|   cd 
|   dch --team
|   # do at least a Standards-Version: 4.1.0
|   # even better
|   uscan --verbose
|   # upgrade to new version
|   # commit + push your changes
| 
| Any Debian developer has commit permissions to Debian Med / Debian
| Science repositories.  Other users need to ask for team membership.
| It would be fine if you submit for instance
| 
|   git format-patch 
| 
| and attach these patches to a sponsoring request bug.
| 
| In case a package is not yet in VCS you can do the following:
| 
|   gbp import-dscs --debsnap --pristine-tar 
|   cd 
|   # ask maintainer whether it is OK to move the package
|   # into Debian Science team maintenance.  If yes,
|   # add Vcs Fields and the Debian Science maintainer list
|   # as Maintainer, keeping the former Maintainer as Uploader
|   # do changes as above
|   # to inject your freshly created repository you can use
|   svn checkout svn://anonscm.debian.org/debian-med/trunk/helper-scripts 
/tmp/helper-scripts
|   /tmp/helper-scripts/inject-into-alioth-git
| 
| This is basically what I did with the packages above and I'll try
| to keep on working on this.
|
| > | > | I intend to refresh with new upstream sources anyway in the next 
couple of days.  May be we can do
| > | > | real uploads of most of the packages ourselves? 
| > | > 
| > | > Please do. Being behind upstream is essentially never a good idea.
| > | 
| > | I'd prefer if you would leave out at least every second chance to repeat
| > | this.  We could talk about this once somebody might pay somebody to
| > | follow each and every update of any random R package.
| > 
| > I may once you start to maintain them -- instead of just hoarding them Take
| > but one example: https://packages.debian.org/sid/r-cran-data.table
| > 
| > Exactly who is served by not updating one of the more widely used to package
| > to one of the two releases that happened _this calendar year_ ?
| 
| If you would ask a non-polemic question I would consider answering
| instead of working on the packages even if you are stealing the topic of
| the thread. 

Sorry, but you started thi