Re: Looking for sponsor for r-cran-reshape2 and r-cran-ggplot2
Hi Andreas,
Sorry for the late response.
On Tue, Feb 14, 2012 at 4:23 PM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi Carlos,
>
> On Tue, Feb 14, 2012 at 10:58:42AM -0500, Carlos Borroto wrote:
>> They are at:
>> git+ssh://git.debian.org/git/debian-med/r-cran-reshape2
>
> Uploaded. Please verify that it is really arch=any (I again noticed
> this after uploading and think it could rather be arch=all). This could
> be fixed in a future release after ftpmaster might have moved it to
> unstable.
>
I did changed to arch=all and git push is showing as everything is
up-to-date, are you seeing it still as arch=any?.
I don't quite understand when to use one or the other, even after
reading "Debian Policy"[1]. I see if I leave it as arch=any, the
default, independent packages for each architecture will be created.
This doesn't tell me when this is the desired result thou. I'm
guessing anything that is a scripting language can be arch=all, as it
doesn't need to be compiled, but I'm not quite sure about R libraries.
Are they compiled?. I do see some .so files being created in some
cases.
[1]http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
>> git+ssh://git.debian.org/git/debian-med/r-cran-ggplot2
>
> Here I changed some slight detail in the short description (removed
> article in the beginning according to lintian warning). Moreover I'm
> afraid that we will face some "binary without source" issue in this case
> for data/*.rda. I do not know ftpmaster's recent policy about this but
> you should be prepared to answer the question how these data can be
> edited. Also when looking at the size of these files it might make
> sense to provide these data in an extra binary package called something
> like r-cran-ggplot2-data / r-cran-ggplot2-common /
> r-cran-ggplot2-examples for the case that they might be useful for this
> R package but not terribly needed for the final purpose of your
> BioConductor packages.
>
I look into moving the data files into their own binary package, it
seems reasonable to do so. Do you remember any r-cran-* example I
could look into?
>> These are the last two R dependencies r-bioc-cummerbund needs. I'm
>> quite happy and grateful of all the help I'm getting.
>
> Well, it's a give and take what we are calling teamwork. By your input
> Debian (Med) becomes better and so we are happy if you take over a job
> we might not be able to afford time wise. So thanks for your work.
>
>> I was wondering what would be the best way to keep track of future updates?
>
> Good question. Usually we are tracking upstream versions on our tasks
> pages but these helpers itself are not relevant for Biology in the first
> place so we will probably not include these. So I see several options:
>
> 1. You create a cron job calling uscan on your local machine
> (should be somewhere documented in uscan or related man pages)
> 2. We create a (fake) task which just lists all our prerequisites
> without creating a metapackage from this. I'm not fully
> convinced about this.
> 3. You can watch the QA page specifically the last columns at
> http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org&ordering=3
> (Packages that are in no specific task are on the bottom of
> this page).
> 4. On my long term todo list I have an automatic script which
> I might run weekly or monthly which sends mail to the mailing
> list about new upstream versions and other problems. While I
> had this script ready in the end of 2010 and was running it
> for testing purposes it was heavily spoiled by some problems
> with UDD and shame on me I did not yet managed to get it working
> again for more than a year. (All this packaging, sponsoring,
> etc. seems to attract my attention more because I do not like
> letting other people wait for us to work and so my own coding
> is always lagging behing. :-()
>
> Hope these hints will help for the moment
>
I like 3, it would be great if you could filter be uploader. Also 4
seems like a nice option, as other people could jump in and help with
packages they wouldn't other wise consider.
-Carlos
Reply to: