Re: tasks files maintence (Re: RFS: graph isomorphism)
Le Thu, Aug 06, 2009 at 09:04:11PM +0200, Andreas Tille a écrit : > On Thu, Aug 06, 2009 at 10:37:31AM -0300, David Bremner wrote: > > > Or maybe there is some alioth magic that could make all debian-science > > members automatic members of blends. > > I don't think that there is such a magic. IMHO the only chance is > to open it for all alioth members. I would not have real problems > with this approach because I'm reading the commit list - but for the > moment there was not much need to do so. Hi Andreas, I think that ACLs can also handle multi-project write access, since it knows them as groups: ple...@alioth:~$ getfacl debian-med # file: debian-med # owner: scm-gforge # group: debian-med user::rwx group::rwx other::r-x I never used ACLs before, so I do not know if it would require the intervention of an Alioth admin or not… Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: tasks files maintence (Re: RFS: graph isomorphism)
On Thu, Aug 06, 2009 at 10:37:31AM -0300, David Bremner wrote: > For me, joining the blends group is fine. bremner-guest added to Blends project. > But in the long run I think > moving into debian-science svn would make it more a natural part of > the team workflow, rather than something you have to manage/encourage > by asking about what task a given new package goes in. Well, if it's only the workflos SVN knows external resources. These are used to put debian-edu and debian-gis source into the blends repository and in turn we might be able to do this in the Debian Science project as well (but I guess proper permissions are needed). I agree that its debatable where to keep the original source for the tasks file - but up to now nobody insisted on moving it and I'm not heavily motivated to change a running system. > Or maybe there is some alioth magic that could make all debian-science > members automatic members of blends. I don't think that there is such a magic. IMHO the only chance is to open it for all alioth members. I would not have real problems with this approach because I'm reading the commit list - but for the moment there was not much need to do so. > Would that be desirable from a > blends point of view delegate adding users like that? It doesn't > matter so much where the svn is I guess, I'm mainly thinking the extra > adminstrative hoop. Considering the number of really interested people it was easily maintainable. > On a related topic it would be nice if there was some semi-automatic > way to smooth the flow of ITPs into the tasks files. This would actually be a nice thing, but I have no idea how to approach this. Currently I'm watching ITPs as far as my time permits and just copy the information which is not that hard if proper ITPs are filed. > Perhaps > something along the lines of the Package Entropy Tracker watching the > git repos. Perhaps something useful will come out of the pkg-perl > teams investigations of git. Well, one slight chance I see is that ITPs might be moved in a structured way to UDD and we just pick by bug number. But that's a lot of work for only one use case (I do not see much other use for this information in UDD) and does not seem to be worth the effort. Kind regards Andreas. -- http://fam-tille.de Klarmachen zum Ändern! -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
tasks files maintence (Re: RFS: graph isomorphism)
Andreas Tille wrote: >On Thu, Aug 06, 2009 at 08:12:09AM -0300, David Bremner wrote: >Currently it is organised that way that you have to be a member of >Blends team on alioth. There is no explicite need for this and it >might also go into the debian-science SVN (but it has to be SVN for >the moment). I feel a bit lazy about moving from the blends repository >and would rather like to add people to this group - but if you think >that's an extra burden just ask me to move. Debian Edu and Debian GIS >have their tasks files in their SVN repositories - all other Blends >source packages are in the blends group. For me, joining the blends group is fine. But in the long run I think moving into debian-science svn would make it more a natural part of the team workflow, rather than something you have to manage/encourage by asking about what task a given new package goes in. Or maybe there is some alioth magic that could make all debian-science members automatic members of blends. Would that be desirable from a blends point of view delegate adding users like that? It doesn't matter so much where the svn is I guess, I'm mainly thinking the extra adminstrative hoop. On a related topic it would be nice if there was some semi-automatic way to smooth the flow of ITPs into the tasks files. Perhaps something along the lines of the Package Entropy Tracker watching the git repos. Perhaps something useful will come out of the pkg-perl teams investigations of git. All the best, David -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: graph isomorphism
On Thu, Aug 06, 2009 at 08:12:09AM -0300, David Bremner wrote: > I guess nauty in mathematics Done. I did not added the information for prospective packages and hope it will show up in new soon which makes the package available on the tasks pages automatically. > maybe libnauty-dev in > mathematics-dev. I'm not sure if the -dev tasks are intended to be > used for only packages that have no real UI, or if splitting the > binary packages from a single source package is a reasonable use. Whatever makes sense. I just added a "Suggests" in mathematics-dev. Just correct me if you think a Depends or just not mentioning might make more sense. We just want to support people who try to develop mathematical applications. > I have also ITP'ed a DFSG free alternative (bliss) that seems quite > functional. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528925. > I guess it can also be added to the same task(s). Added to tasks file. > Perhaps it is time for a reminder or a link to how tasks work; I > confess to not paying enough attention so far. Edit svn://svn.debian.org/svn/blends/projects/science/trunk/debian-science/tasks > Is it be possible for > members of the debian science team to directly edit debian science > tasks? Currently it is organised that way that you have to be a member of Blends team on alioth. There is no explicite need for this and it might also go into the debian-science SVN (but it has to be SVN for the moment). I feel a bit lazy about moving from the blends repository and would rather like to add people to this group - but if you think that's an extra burden just ask me to move. Debian Edu and Debian GIS have their tasks files in their SVN repositories - all other Blends source packages are in the blends group. Kind regards Andreas. -- http://fam-tille.de Klarmachen zum Ändern! -- 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
On Thu, Aug 06, 2009 at 01:05:05PM +0200, Steffen Moeller wrote: > I personally think that we should rather investigate, to what degree we could > perform the > automation of BioC packages. This idea was the basic background of my reasonings in this thread. I would dream of kind of a list of packages which are "interesting for us" and than create source packages for these out of the cran2deb effort which should be maintained by us (regarding those information which needs manual work like copyright file). It would be great if this information could be included in the "basic source of information" (= cran2deb) as I said previousely to make sure our work will not be overriden by further updates. Kind regards Andreas. -- http://fam-tille.de Klarmachen zum Ändern! -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: graph isomorphism
Andreas Tille wrote: >On Wed, Aug 05, 2009 at 10:57:22PM -0300, David Bremner wrote: >> Description : graph isomorphism testing library, with command line >> tools >In which ouf our categories[1] would this package fit best according >to your opinion? I guess nauty in mathematics maybe libnauty-dev in mathematics-dev. I'm not sure if the -dev tasks are intended to be used for only packages that have no real UI, or if splitting the binary packages from a single source package is a reasonable use. >> Unfortunately upstream is not interested in relicensing the package. >:-( >Thanks for working on this (and ping me in case nobody else shows >up as a sponsor) I have also ITP'ed a DFSG free alternative (bliss) that seems quite functional. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528925. I guess it can also be added to the same task(s). Upstream of polymake has agreed in principle to migrate, but (surprise!) has very little time now. So I think even as a build-dep nauty will be required for one release cycle. And in any case, it is in some sense the standard software for graph isomorphism. Perhaps it is time for a reminder or a link to how tasks work; I confess to not paying enough attention so far. Is it be possible for members of the debian science team to directly edit debian science tasks? All the best, David -- 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
Salut, Charles Plessy wrote: > Le Tue, Jul 28, 2009 at 11:47:23AM +0200, Steffen Moeller a écrit : >> from the Debian-med perspective I personally am more interested to learn >> about the >> possibility to get BioConductor in. If I recall correctly, the major >> challenge is to get >> the machine for the redistribution of the packages, right? > > By the way, I just realised that the base (biobase) BioConductor package can > be > built without problem with /usr/share/R/debian/r-cran.mk. How about following > the same logic as for CRAN and package the most frequently used components in > our main archive? this would sound just right to me. A problem might be a higher incompatibility of package versions between bioconductor releases. So we would need to synchronise ourselves strongly, which is exactly what the automated effort should perform for us. But this might but be of concern for the majority of the moer central classical BioC packages, indeed. I personally think that we should rather investigate, to what degree we could perform the automation of BioC packages. Many greetings Steffen -- 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
Le Tue, Jul 28, 2009 at 11:47:23AM +0200, Steffen Moeller a écrit : > > from the Debian-med perspective I personally am more interested to learn > about the > possibility to get BioConductor in. If I recall correctly, the major > challenge is to get > the machine for the redistribution of the packages, right? By the way, I just realised that the base (biobase) BioConductor package can be built without problem with /usr/share/R/debian/r-cran.mk. How about following the same logic as for CRAN and package the most frequently used components in our main archive? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
