RFS: graph isomorphism

[David Bremner-4]

* Package name    : nauty
  Version         : 2.4~b7-1
  Upstream Author : Brendan McKay <bdm@...>
* URL             : http://cs.anu.edu.au/~bdm/nauty/
* License         : non-free/pacifist. See below.
  Programming Lang: C
  Section         : non-free/math

  Description     : graph isomorphism testing library, with command line tools

 nauty (no automorphisms, yes?) is a set of procedures for determining
 the automorphism group of a vertex-coloured graph. It provides this
 information in the form of a set of generators, the size of the
 group, and the orbits of the group. It is also able to produce a
 canonically-labelled isomorph of the graph, to assist in isomorphism
 testing.

nauty is a build dependency of polymake (ITP 461976)

Unfortunately upstream is not interested in relicensing the package.
Non-free bits of the license are follows:

  Copyright (1984-2009) Brendan McKay. All rights reserved. Permission
  is hereby given for use and/or distribution with the exception of sale
  for profit or application with nontrivial military significance.
 
It builds these binary packages:
libnauty-dev - library for computing graph automorphisms (development files)
libnauty0d - library to compute graph automorphisms and canonical labellings
nauty      - command line tools to compute graph automorphisms

The package appears to be lintian clean.

The upload would fix these bugs: 529094 (ITP)

I would be grateful if someone uploaded this package for me.

Warm regards
 David Bremner


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

Sorry, doze-n-send, strikes again.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/n/nauty
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-6]

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?

> 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)

          Andreas.

[1] http://blends.alioth.debian.org/science/tasks/ 

--
http://fam-tille.de
Klarmachen zum Ändern!


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

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-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

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-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

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-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

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-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

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:

plessy@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-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

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

>Thanks for working on this (and ping me in case nobody else shows
>up as a sponsor)

>          Andreas.

Hi Andreas;

So far no one else has replied. If you have a chance to look at it,
that would be great.

To recap

   git clone git+ssh://alioth.debian.org/git/debian-science/packages/nauty.git  && cd nauty && debuild

Or there is a source package on mentors.debian.net

   dget http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc

All the best,

David

P.S. I managed (on second try :) to update the tasks entry for
latexdiff.  Since it is a perl program, and maybe not "core science" I
decide to maintain it in pkg-perl.



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

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

>Thanks for working on this (and ping me in case nobody else shows
>up as a sponsor)

>          Andreas.

Hi Andreas;

So far no one else has replied. If you have a chance to look at it,
that would be great.

To recap

   git clone git+ssh://alioth.debian.org/git/debian-science/packages/nauty.git  && cd nauty && debuild

Or there is a source package on mentors.debian.net

   dget http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc

All the best,

David

P.S. I managed (on second try :) to update the tasks entry for
latexdiff.  Since it is a perl program, and maybe not "core science" I
decide to maintain it in pkg-perl.



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

I found a silly packaging bug that causes the package to FTBFS almost
everywhere.

I uploaded a new version to

  http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc

or from

  git://git.debian.org/git/debian-science/packages/nauty.git

  signed tag: debian/2.4b7rc2

I know many people (including me) are not too enthusiastic about
spending time and effort on non-free software, however

  - nauty is the de-facto standard for graph isomorphism computation
  - I'm packaging it as a build depends for polymake, a GPLed package
   that I'm currently packaging for contrib, but hopefully will
   migrate to main by squeeze+1 (needs about a page of upstream code
   rewritten to replace the build-depends on nauty).  Several people
   have inquired about polymake packages, so I don't think it is a pure
   vanity package.

I hope that somebody at least downloads and test-builds this version,
since I'm pretty sure nobody did the last one :)

All the best,

David


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[smr99]

Hi David,

I'm willing to sponsor nauty.


On Sat, Sep 05, 2009 at 02:11:20PM -0300, David Bremner wrote:
>
> I found a silly packaging bug that causes the package to FTBFS almost
> everywhere.
>
> I uploaded a new version to
>
>   http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc

I had a very quick look.  It builds and seems to produce correct packages.
However, there is some weird output during the process:

  dh --with quilt /usr/share/topgit/tg2quilt.mk                                                                              
  dh: Unknown sequence /usr/share/topgit/tg2quilt.mk (choose from: binary binary-arch binary-indep build clean install patch)

I don't have topgit installed.  Maybe you do, and don't see this
warning.  As I say, on first glance the .debs appear OK, so this
doesn't appear to do any harm; but better if it can be avoided.


Cheers,
-Steve

[Andreas Tille-5]

On Thu, Aug 06, 2009 at 10:37:31AM -0300, David Bremner wrote:
> 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.

I perfectly agree here and IMHO the apropriate way would be the
following:

  1. Move information of WNPP bugs into UDD
  2. Put WNPP number into tasks file (instead of copying
     the WNPP info into tasks file
  3. Render information from UDD on the tasks pages

The problem is 1. because it depends from the quality of the bug reports
to get really structured information.  In principle the reportbug
template is structured enough to enable automatic parsing - but
reporters are sometimes not strict enough to follow the template.

The procedure is one of my long term goals - I would not mind if
somebody might tackle item 1. - the other items are really cheap
to implement.

Kind regards

     Andreas.

--
http://fam-tille.de
Klarmachen zum Ändern!


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Fri, Aug 07, 2009 at 09:05:17AM +0900, Charles Plessy wrote:

>
> I think that ACLs can also handle multi-project write access, since it knows
> them as groups:
>
> plessy@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???

I would really welcome if somebody would care for this.  It would be a
quite reasonable solution.

Kind regards

     Andreas.

--
http://fam-tille.de
Klarmachen zum Ändern!


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Sat, Sep 05, 2009 at 09:27:49PM +0200, Andreas Tille a écrit :

> On Fri, Aug 07, 2009 at 09:05:17AM +0900, Charles Plessy wrote:
> >
> > I think that ACLs can also handle multi-project write access, since it knows
> > them as groups:
> >
> > plessy@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???
>
> I would really welcome if somebody would care for this.  It would be a
> quite reasonable solution.

Hi all,

I figured out that only Alioth admins can modify the repository ACLs. Now the
Blends repository is writable for debian-med. As announced on the debian-blends
mailing list, just let me know if you would like that the members of the
debian-science Alioth project also get write access to the Blends subversion
repository. This would enable each debian-science member to do ‘debcheckout -a
debian-science’ and modify the task files.

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-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...