Hi Andreas, Sorry for the late response.
On Tue, Feb 14, 2012 at 4:23 PM, Andreas Tille <[email protected]> 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/[email protected]&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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CABgGhBKrXoA1fnUbX2Gg6EXDsiotjAFpmzjzPXdD=mtm_or...@mail.gmail.com
