[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: packaging Siconos



Andreas,

Thanks very much for your reply.

On Wed, Jan 4, 2017 at 12:40 PM, Andreas Tille <andreas@an3as.eu> wrote:
>> If so, I can report a problem registering an account, I have tried
>> twice and both times after email verification I am greeted with this
>> error message:
>>
>> "Exiting with error
>>
>> Could Not Get User"
>
> Hmmm, I'd naively say please try later again.  If this does not help
> you might need to contact alioth admins.

Ok, I tried again and discovered it was automatically adding "-guest"
to my username.  Now I managed to verify the account, which has the
word "-guest" appended, which is ok, I guess.


> You might like to have a look at "Sponsering of Blends"[2].

I see, my first time encountering the Blends concept so I will read up.

>>   - public domain code from http://www.netlib.org, in particular
>> "odepack"; is there any history of this code being packaged previously
>> for Debian?  I do not want to duplicate efforts, but would be willing
>> to make packages for what we use.
>
> Not that I'm aware of.  I only know that lapack is packaged.

Ok so perhaps it would be a useful endeavour then.  I'll look into
making a few packages with our dependencies.  I do notice that we have
modified a few headers in those dependencies to make them include a
common BLAS header for example, but I suppose such changes will make
sense for Debian too.


>>   - numerics_bindings: this apparently has already been proposed for
>> Debian in 2009 but was closed, perhaps out of lack of interest, would
>> it be possible for it to be re-opened?  https://bugs.debian.org/536270
>
> Either reopen or create a new ITP.  Both is fine.

Ok, excellent, thank you.

>>   - two of our optional dependencies do have weird license situations:
>> PATH has a strange license found at
>> http://pages.cs.wisc.edu/%7Eferris/path/LICENSE and SOL/lumod seems to
>> have no license at all:
>> http://web.stanford.edu/group/SOL/software/lumod/ ; so the question
>> is, should I remove these from our source release tarball using a
>> patch?
>
> Since no license is per definition non-free you need to remove it in any
> case.  You might like to contact the authors of both projects to choose
> a free license.  I've done this with varying success in the Debian Med
> team[3].  I think when writing to the authors a good start of your
> e-mail would be:
>
>    I'm writing you on behalf of the Debian Science team which is
>    a group of maintainers inside Debian with the objective to
>    package free software with relevance to scientific research for
>    official Debian.

I will do so.

>> 3) I would like to know what Debian Science thinks of the static
>> linking or private library approach, vs. making dedicated packages for
>> these collections of Fortran routines.
>
> To say it very shortly: Static libraries are sucking.  Feel free
> to ask for a longer explanation.

No need, I understand.


> Hope this helps

Indeed, thanks for the links!

regards,
Steve


Reply to: