Aw: Re: Removing ATLAS?

[Steffen Möller]

Hi all,

EMMAX is (was) important
https://genome.sph.umich.edu/wiki/EMMAX

but I admittedly cannot invest into maintaining this or atlas.
My suggestion would be to talk back to upstream about transitioning to an 
alternative. I have no idea about how difficult this would be to patch 
ourselves.

Best,
Steffen

> Gesendet: Montag, 10. Juli 2023 um 22:01 Uhr
> Von: "Andreas Tille" 
> An: debian-science@lists.debian.org
> Betreff: Re: Removing ATLAS?
>
> Hi Sébastian,
> 
> Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot:
> > 
> > So, given all that, I’m inclined to (try to) remove atlas during the
> > trixie development cycle.
> 
> Sounds reasonable.
>  
> > Any thought on this?
> 
> I've checked my responsibility for the dependencies and stumbled about
> emmax
> 
> 
> emmax.c:10:10: fatal error: clapack.h: No such file or directory
>10 | #include 
>   |  ^~~
> compilation terminated.
> 
> 
> and noticed
> 
> $ apt-file search clapack.h
> libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h
> ... (other instances are not blas related)
> 
> which was probably the reason why I've picked libatlas-base-dev
> originally.  I would not say that emmax is important and its
> also a not maintained upstream any more.  However, I vaguely
> remember that this
>#include 
> in some code pieces of Debian Med was the reason to actually
> pick this blas implementation.  Any hint how to deal with such
> cases?
>  
> Kind regards
> Andreas.
>  
> > Checking reverse dependencies...
> > # Broken Depends:
> > ceres-solver: libceres-dev
> >   libceres3
> > colmap: colmap [amd64 arm64 i386 mips64el mipsel ppc64el s390x]
> > dune-common: libdune-common-dev
> > emmax: emmax
> > ergo: ergo
> > iml: libiml0
> > nipy: python3-nipy-lib [armel mipsel]
> > psfex: psfex
> > python-escript: python3-escript [armel mipsel]
> > python3-escript-mpi [armel mipsel]
> > qm-dsp: libqm-dsp0
> > scamp: scamp [amd64 arm64 mips64el ppc64el s390x]
> > scikit-misc: python3-skmisc
> > sight: libsight [amd64]
> > source-extractor: source-extractor
> > xmds2: xmds2
> > 
> > # Broken Build-Depends:
> > ceres-solver: libatlas-base-dev
> > dune-common: libatlas-base-dev
> > emmax: libatlas-base-dev
> >libatlas3-base
> > ergo: libatlas-base-dev
> > ghmm: libatlas-base-dev
> > halide: libatlas-base-dev
> > hpcc: libatlas-base-dev
> > iml: libatlas-base-dev
> > ncl: libatlas3-base
> > odin: libatlas-base-dev
> > opm-material: libatlas-base-dev
> > phast: libatlas-base-dev
> > plink1.9: libatlas-base-dev
> > plink2: libatlas-base-dev
> > psfex: libatlas-base-dev
> > qm-dsp: libatlas-base-dev
> > scamp: libatlas-base-dev
> > scikit-misc: libatlas-base-dev
> > source-extractor: libatlas-base-dev
> > theli: libatlas-base-dev
> > xmds2: libatlas-base-dev
> > 
> > Dependency problem found.
> > 
> 
> 
> 
> 
> -- 
> http://fam-tille.de
> 
>

freecad - python autotests fail on arm+powerpc

[Steffen Möller]

Hello, following https://tracker.debian.org/pkg/freecad to
https://ci.debian.net/data/autopkgtest/testing/armhf/f/freecad/19724334/log.gz
I just don't grasp

test_issue_4456 (parttests.regression_tests.RegressionTests)
0004456: Regression : Part.Plane.Intersect do not accept plane as argument ... 
ok

==
ERROR: testSchemeTranslation (UnitTests.UnitBasicCases)
--
Traceback (most recent call last):
  File "/usr/share/freecad/Mod/Test/UnitTests.py", line 126, in 
testSchemeTranslation
q2 = FreeCAD.Units.Quantity(t[0])
ValueError: syntax error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/freecad/Mod/Test/UnitTests.py", line 131, in 
testSchemeTranslation
print (u" ".join(e).encode("utf-8").strip())
TypeError: can only join an iterable


If someone could help out with a patch this would be fantastic.

Many thanks!

Steffen

Re: Google Summer of Code, Debian Science

[Steffen Möller]

You are aware of https://wiki.debian.org/DebianScience/ROOT ?

On 22.02.22 17:19, Stephan Lachnit wrote:

On Mon, Feb 21, 2022 at 5:43 PM Anton Gladky  wrote:

If somebody wants to be a co-mentor or if you have better ideas
for the project, please let me know.

I would love to have a student to bring up packaging of common HEP
packages (High Energy Physics), most notably ROOT [1] and Geant4 [2].
I've already done a bit ([3] resp. [4]), but I'm currently not working
actively on it anymore.

If anyone would be interested to co-mentor this, I would consider
mentoring this. However it's unlikely that I will do it alone as I'm
hopefully a Summer Student myself (not at GSoC).

Regards,
Stephan

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981113
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965964
[3] https://salsa.debian.org/science-team/root
[4] https://salsa.debian.org/science-team/geant4

Re: RFS faber - build dependency for boost-python

[Steffen Möller]

Fantastic - thank you tons!
Steffen

On 11.02.22 11:44, Étienne Mollier wrote:

Hi Steffen,

Steffen Möller, on 2022-02-08:

https://salsa.debian.org/python-team/packages/faber

I had asked the Debian boost folks already to comment on that package
but have not heard back. Faber is a build tool that the upstream boost
community has elevated as the next thing for their Python interface. But
it can also be used as a substitute for make.

Anyway. Could someone please have a look that I have not borked to
smoothen the transition through NEW? Please feel free to upload.

Please kindly check the buildability of the package using a
clean chroot (automating this with pbuilder or sbuild, or
anything doing similar job at your preference.  :)  I had to
append python3-yaml  to the build dependencies to go
through the build and test process.

There were some Lintian issues afterwards, which you might want
to address:

W: faber: useless-whatis-entry usr/share/man/man1/faber.1.gz
I: faber source: debian-watch-contains-dh_make-template  [debian/watch]
I: faber: spelling-error-in-description platoform platform
I: python3-faber: spelling-error-in-description platoform platform

(With help2man, you can set the whatis entry with --name flag.)

You will have to document as well the following files in
d/copyright, as otherwise the package would probably get
rejected from NEW:
   - doc/_static/boost.css
   - src/faber/termcolor.py
   - src/faber_bench/images/stop.svg (looks CC0/public domain,
 but I am unsure)
Maybe I missed other files, so don't hesitate to do one more
review on your end.

I don't have access to the Debian Python team repository, so I
haven't pushed nor uploaded anything.

In hope this helps,

RFS faber - build dependency for boost-python

[Steffen Möller]

Hello,

This is about

https://salsa.debian.org/python-team/packages/faber

I had asked the Debian boost folks already to comment on that package
but have not heard back. Faber is a build tool that the upstream boost
community has elevated as the next thing for their Python interface. But
it can also be used as a substitute for make.

Anyway. Could someone please have a look that I have not borked to
smoothen the transition through NEW? Please feel free to upload.

Many thanks!

Best,
Steffen

Re: alphafold Debian packaging ?

[Steffen Möller]

On 12.01.22 17:24, M. Zhou wrote:

Even more complicated is the underlying software dependency tree.

alphafold depends on dm-haiku, jax, tensorflow.
dm-haiku depends on jax.
jax depends on XLA from tensorflow.
tensorflow still in NEW.

Long way to go. Mhhh.


That is what I had thought, too. On

https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=1840067013

I once collected the immediate dependencies and can confirm that it
there is quite a bit of homework out there. If the only purpose is to
bring AlphaFold to Debian then I suggest not to do it. The benefit may
be to improve the software basis of Debian at large with it. But also, I
can do something good elsewhere and all these releases update so
quickly, to me it stopped being fun.


What's also complicated is the GPU support. Currently the only
working modern deep learning framework in our archive is pytorch,
which is only compiled with cpu support.

pytorch-cuda requires cudnn. I gave up cudnn packaging a few
times and I eventually realized that I dislike working on
nvidia stuff even if I have to use it.

pytorch-rocm is a good way to go. As you can see on debian-ai@
people are still working hard to get ROCm into debian.

Intel GPU support is too new to evaluate.


To have ROCm as a source package with Debian will be good for everyone.
IMHO this may actually dwarf the benefit of having AlphaFold with us.
So, yes, if something like AlphaFold is something that we need as a
carrot to improve our Java infrastructure, then I am all up for it.

The prospect to have a community-regenerated knowledge base for
AlphaFold is also very tempting.

Steffen


On Wed, 2022-01-12 at 16:54 +0100, Gard Spreemann wrote:

Andrius Merkys  writes:


On 2022-01-12 17:34, Gard Spreemann wrote:

And their code repository is Apache. Or did you find the actual
pretrained models somewhere under CC-BY-NC?

Interesting. Maybe I am looking at some other source. Am I right to
assume we are talking about [3]? If so, it says that the parameters
are
CC-BY-NC here: [4].

[3] https://github.com/deepmind/alphafold
[4] https://github.com/deepmind/alphafold#model-parameters

Interesting indeed! So we have:

  – Training data: A plethora of different licenses.

  – Code: Apache

  – Trained model: CC-BY-NC-4.0

  – Output of said trained model: CC-BY-4.0 [5]

Nightmarish!

[5] See under "license and attributions" on https://alphafold.com


  -- Gard

Re: alphafold Debian packaging ?

[Steffen Möller]

I am only aware of someone who got it to run on Debian :)  I agree that
it would be nice to have. Very nice.

Cheers,
Steffen

On 11.01.22 14:47, PICCA Frederic-Emmanuel wrote:

Hello guyes,

I would like to know if you are aware of an effort to package alphafold[1] on 
Debian ?

Cheers

Frederic

[1] https://alphafold.com/

Re: Contributing to yosys maintenance

[Steffen Möller]

Hi Daniel,

On 30.12.21 22:38, Daniel Gröber wrote:

Hi Anton and Steffen,

On Thu, Dec 30, 2021 at 10:11:26PM +0100, Anton Gladky wrote:

I have just added you to the group. Welcome on board!
You can commit directly in git, but please coordinate
your work with an active uploaders of this package, if
there are any.

Awesome, thanks for the quick response.

So I guess I'll at least push new upstream release into the upstream branch
and then open an MR for the rests of the changes while I wait for a
response. That shouldn't step on anyone's toes, right?


äh - no, not yet. Wait for Ruben's reply. The integrity of the upstream
orig.tar.gz is a crucial part. You could be evil and introduce something
that then Ruben signs? Nope.

Also, yosys (like most packages on salsa) comes with a pristine-tar
branch. Please look at git-buildpackage and, preferably, get a mentor
for your first upload to salsa. I am not sure about any policy document
for science, but for med there is
https://med-team.pages.debian.net/policy/ which should also apply to
salsa (just s/med/science/g) - please read that prior to uploading to salsa.




Please also look at the electronics team.

I'm also planning on packaging the ghdl yosys integration so I'll likely
have to :)


Very nice. I happen to be behind
https://github.com/ghdl/ghdl-yosys-plugin/issues/162, so your work is
most welcome, indeed. Feel free drop a note in that issue that you
surfaced to address this.

Best,
Steffen

Re: Contributing to yosys maintenance

[Steffen Möller]

Hi Daniel,

On 30.12.21 21:08, Daniel Gröber wrote:

I'm working on packaging the latest version of yosys and related packages
for Debian.


Nice. I was not aware of the many new releases - clifford.at seems down
and https://github.com/YosysHQ/yosys is the new home?


What's the procedure in debian-science for being added to the salsa org/git

It is already on salsa, albeit not in
https://salsa.debian.org/electronics-team but in
https://salsa.debian.org/science-team/yosys

repo on salsa[1] or should I just post MRs/patches to the BTS?

Please contact the current maintainer, i.e. Ruben. He will either
immediately update the package or direct you with the next steps to
take. Should he not reply then I am dead confident that he will
appreciate a team upload, feel free to PM me, then. Please also look at
the electronics team.

[1]: Just in case, my username there is dxld-guest.


Welcome.

Best,
Steffen

LinuxCNC in New Queue - upstream as an alternative to teams on salsa

[Steffen Möller]

Hello,

LinuxCNC.org has its own Debian repository since a couple of decades.
 and I have worked as DDs with upstream over the past few weeks
to eliminate a series of lintian errors and sidetracked ourselves here
and there, but yesterday LinuxCNC arrived in the New Queue. Its runtime
(suggested) dependency "mesaflash" was already uploaded a month earlier.
Two developers from upstream agreed to become Debian Maintainers.

What I am fond of is that we have so far resisted to bring the
Debianisation to salsa. Everything went through upstream's github
repository. From my side this was motivated as an expression of respect
for the long history that Debian has with LinuxCNC. It was important to
me not to split/disturb their community because of Debian. Debian
developers should just help and support.

So, I think this has worked. If you happen to be close to robotics
and/or CNC machining, or close to those who are near, please get in
touch with them or .  prepared for the introduction of
po4a to help with their localisation that certainly can use more
eyeballs and help orchestrating translators with less ITish backgrounds.

Best,
Steffen

Re: Debian Math Team

[Steffen Möller]

While I agree, this may also be good thing. There will be more Sprints
(I hope) with then more people that are brought to our community at
large. And Debian so far does very well in keeping all those fragments
together.

Best,

Steffen

On 30.10.21 01:55, Anton Gladky wrote:

Hi Doug,

well, I think that it just increases a fragmentation. But it is up to you.

Best regards

Anton

Am Fr., 29. Okt. 2021 um 22:04 Uhr schrieb Torrance, Douglas
:

During the Debian Science BoF at this year's DebConf, there was some
discussion of creating a team devoted to packaging mathematical software.

This seemed like a pretty good idea, so I figured that I'd go ahead and
start working on getting it set up.  I've already created a Salsa group [1]
and a team on the Debian Package Tracker [2].  If you're interested in
joining, then you should be able to sign up at these links.

I figured next would be applying for a mailing list, putting together a team 
policy, etc.  Any thoughts?

Doug

[1] https://salsa.debian.org/math-team
[2] https://tracker.debian.org/teams/math/

Datasets downloaded by scikit-learn as separate packages?

[Steffen Möller]

Hello,

This goes out to the good fellas who care about scikit-learn. There is
tutorial for the qiime package that has classifier prepared that only
works with the latest stable version (0.24.2). We are at 0.23.2 in Debian.

I gave an update of Scikit-Learn a shot and while the main build was
fine, I was eventually greeted with many download errors for datasets
that it uses as examples, as in

/home/steffen/Science/scikit-learn/examples/inspection/plot_partial_dependence.py
failed leaving traceback:
Traceback (most recent call last):
  File
"/home/steffen/Science/scikit-learn/examples/inspection/plot_partial_dependence.py",
line 50, in 
    cal_housing = fetch_california_housing()
  File
"/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build/sklearn/utils/validation.py",
line 63, in inner_f
    return f(*args, **kwargs)
  File
"/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build/sklearn/datasets/_california_housing.py",
line 134, in fetch_california_housing
    archive_path = _fetch_remote(ARCHIVE, dirname=data_home)
  File
"/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build/sklearn/datasets/_base.py",
line 1194, in _fetch_remote
    urlretrieve(remote.url, file_path)
  File "/usr/lib/python3.9/urllib/request.py", line 239, in urlretrieve
    with contextlib.closing(urlopen(url, data)) as fp:
  File "/usr/lib/python3.9/urllib/request.py", line 214, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.9/urllib/request.py", line 517, in open
    response = self._open(req, data)
  File "/usr/lib/python3.9/urllib/request.py", line 534, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
  File "/usr/lib/python3.9/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.9/urllib/request.py", line 1389, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
  File "/usr/lib/python3.9/urllib/request.py", line 1349, in do_open
    raise URLError(err)
urllib.error.URLError: 


The original data is typically available. But these are classics with
often unclear licenses, here as in

# The original data can be found at:
# https://www.dcc.fc.up.pt/~ltorgo/Regression/cal_housing.tgz
ARCHIVE = RemoteFileMetadata(
    filename='cal_housing.tgz',
    url='https://ndownloader.figshare.com/files/5976036',
    checksum=('aaa5c9a6afe2225cc2aed2723682ae40'
  '3280c4a3695a2ddda4ffb5d8215ea681'))


The build currently ends with

I: pybuild pybuild:284:   (mv
/home/steffen/Science/scikit-learn/sklearn/conftest.py
/home/steffen/Science/scikit-learn/sklearn/conftest.py.test; mv
/home/steffen/Science/scikit-learn/sklearn/datasets/tests/conftest.py
/home/steffen/Science/scikit-learn/sklearn/datasets/tests/conftest.py.test;
cd /home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build &&
python3.9 -c 'import sklearn; sklearn.show_versions()')
mv: cannot stat
'/home/steffen/Science/scikit-learn/sklearn/conftest.py': No such file
or directory
mv: cannot stat
'/home/steffen/Science/scikit-learn/sklearn/datasets/tests/conftest.py':
No such file or directory

System:
    python: 3.9.7 (default, Sep  3 2021, 06:18:44)  [GCC 10.3.0]
executable: /usr/bin/python3.9
   machine: Linux-5.10.0-8-amd64-x86_64-with-glibc2.32

Python dependencies:
  pip: 20.3.4
   setuptools: 52.0.0
  sklearn: 0.24.2
    numpy: 1.19.5
    scipy: 1.7.1
   Cython: 0.29.21
   pandas: 1.1.5
   matplotlib: 3.3.4
   joblib: 0.17.0
threadpoolctl: 2.1.0

Built with OpenMP: True
I: pybuild base:232: cd
/home/steffen/Science/scikit-learn/.pybuild/cpython3_3.9/build;
python3.9 -m pytest -m "not network" -v -k "not test_old_pickle and not
test_ard_accuracy_on_easy_problem"
ImportError while loading conftest
'/home/steffen/Science/scikit-learn/conftest.py'.
../../../conftest.py:14: in 
    from sklearn.utils import _IS_32BIT
../../../sklearn/__init__.py:81: in 
    from . import __check_build  # noqa: F401
../../../sklearn/__check_build/__init__.py:46: in 
    raise_build_error(e)
../../../sklearn/__check_build/__init__.py:31: in raise_build_error
    raise ImportError("""%s
E   ImportError: No module named 'sklearn.__check_build._check_build'
E
___
E   Contents of /home/steffen/Science/scikit-learn/sklearn/__check_build:
E   setup.py  _check_build.c __pycache__
E   _check_build.pyx  __init__.py
E
___
E   It seems that scikit-learn has not been built correctly.
E
E   If you have installed scikit-learn from source, please do not forget
E   to build the package before using it: run `python setup.py install` or
E   `make` in the source directory.
E
E   If you have used an installer, please check that it is suited for your
E   Python version, your operating system and your platform.
E: pybuild pybuild:353: test: plugin distutils 

Aw: ASTM Lab equipment protocol

[Steffen Möller]

Hi Rob,

> Which Debian packages support the ASTM lab equipment (over TCP)
> protocol? An overview would be nice.

Nothing in Debian, and nothing anywhere, so it felt.
Found a Python package implementing the ASTM standard from 2013, which we could 
(help you to) maintain in Debian. But otherwise, there was not too much Free 
software available from what a quick web search offered. What would you like to 
see?

Best,
Steffen

Re: Fwd: stan packaging

[Steffen Möller]

Am 18.06.2021 um 13:33 schrieb Stéphane Glondu:

Hello,

Le 05/06/2021 à 14:51, Steffen Möller a écrit :

You may have heard of R and a (fairly) new kid on the block, Julia, and
there is something in between that is also tantalizingly different such
that all math environments have interfaces to it: stan
(https://mc-stan.org).  Now, I did not get too far with my attempt to
get the command line compiled - the lines below sum this up: I need the
ppx_jane package and not unlikely also others that I am not yet aware of.

Is there someone out there on this list who would like to work on this?

ppx_jane is a sort of meta-package depending on many Jane Street's ppx
rewriters. Jane Street tend to release many small packages. Those are
generally easy to debianize, but it often happens that they must be
updated in lockstep. That and their number make their maintenance
impractical.

Installing ppx_jane in a clean opam environment brings 24 packages that
are not in Debian. All of them except octavius are Jane Street packages
versioned v0.14.x. Packaging (and maintaining the packages) sounds like
a big effort, at least with the way we do things at the moment. But
things certainly could be improved.



Thank you, Stéphane, I think this triggers a pause on my end.

Best,
Steffen

Fwd: stan packaging

[Steffen Möller]

Dear OCaml maintainers,

My last contact with ML was about 30 years ago and, yes, there is a part
in me that wants to dive back into it, but there are other things that I
can also do that I can help Debian more with, I think. So, I come here
to ask for help.

You may have heard of R and a (fairly) new kid on the block, Julia, and
there is something in between that is also tantalizingly different such
that all math environments have interfaces to it: stan
(https://mc-stan.org).  Now, I did not get too far with my attempt to
get the command line compiled - the lines below sum this up: I need the
ppx_jane package and not unlikely also others that I am not yet aware of.

Is there someone out there on this list who would like to work on this?

Many thanks!
Steffen



 Weitergeleitete Nachricht 
Betreff:Re: stan packaging
Datum:  Sat, 5 Jun 2021 03:19:47 +0530
Von:Nilesh Patra 
An: Steffen Möller 
Kopie (CC): Debian Science 



On 04/06/21 10:27 PM, Steffen Möller wrote:

Sigh. cmdstan needs stanc3 (to be packaged) which needs dune (available)
which needs https://opam.ocaml.org/packages/ppx_jane/ppx_jane.v0.14.0/
(to be packaged). This is a bit beyond my  routine.

Do we have OCaml folks on this list?


I think it'd be best to ask in https://lists.debian.org/debian-ocaml-maint/
It looks doable, can give it a try but the dependency(and transitive)
list is rather
huuuge, admittedly

Nilesh

Re: stan packaging

[Steffen Möller]

Hi Mo,

will do. Could you please check if you have something not pushed (tags
in particular) for stan?

Best,
Steffen

Am 04.06.2021 um 09:54 schrieb M. Zhou:

Hi Steffen,

Please feel free to take them over :-)
I'm focusing on other packages currently.

On Thu, 2021-06-03 at 23:05 +0200, Steffen Möller wrote:

Hi Mo,

Thank you tons for you initiative on stan. I did a few smallish
changes
to the math library and have a few more of the same for the stan
package
that are triggered from the build tests. Now, I would like to proceed
to
https://github.com/stan-dev/cmdstan, so we have something to start
from
the shell, too (maybe stan-cmdstan as a package name?).  This might
require update of stan-math and stan - would you mind?

Best,
Steffen

Re: Quick Poll: Debian to better support hardware acceleration?

[Steffen Möller]

Am 21.05.21 um 15:55 schrieb Thomas Schiex:
> I'm a computer scientist working in AI and structural biology. I'm
> sorry to say that CUDA has slowly invaded a lot of our scientific
> pipelines, for Deep learning, convex optimization and molecular
> simulations.
>
> I just could not vote for option 2 even if option 1 is tolerable (I'm
> using it).
>
> Le 21/05/2021 à 15:35, Julien Puydt a écrit :
>> Le vendredi 21 mai 2021 à 04:40 +, M. Zhou a écrit :
>>> Q: How far should Debian go along the way for supporting hardware
>>> acceleration solutions like CUDA?
>>>
>>> Choice 1: this game belongs to the big companies. we should offload
>>> such burden to third-party providers such as Anaconda.
Once you decide to go the conda/brew/guix route, you are likely to stick
to it also for your applications. Debian is then left out.
>>> Choice 2: we may try to provide what the users need.
Please. Otherwise we fail them.
>>> Choice 3: 
>> I'm not a user of anything like it (as far as I know...), but it's
>> Debian's mission to make useful software available : choice 2.

Free CUDA drivers will take a bit longer to surface. We should have the
non-free now and the free shall be supported - happily so with Debian
Money if that changes anything. But our users should not need to wait.
ROCm is late in the game, which is unfortunate.

Would be great to have also more from Xilinx and Altera/Intel in our
distribution to detect and program their FPGA.

Thanks!

Steffen

Done Re: [RFS] apertium-cy-en

[Steffen Möller]

I suggest you add a note in d/changelog that this team-upload fixes the
migration to testing. And if it builds for you then close the bug with
this upload.

Best,
Steffen

Am 24.12.20 um 13:47 schrieb Nilesh Patra:
> Hi,
>
> Currently apertium-cy-en seems to be blocking apertium's testing
> migration as can be seen here:
> https://qa.debian.org/excuses.php?package=apertium
> 
>
> I've fixed it, at least temporarily, pushed to salsa and kept the
> changelog UNRELEASED for now. Please upload or grant access to upload:
>
> gbp clone --pristine-tar
> https://salsa.debian.org/science-team/apertium-cy-en
> 
>
> OR
>
> dcut dm --uid npatra...@gmail.com  --allow
> apertium-cy-en
>
> PS: apertium-kaz-tat has bug #973154 reported for FTBFS, but it seems
> to build just fine in my chroot. I also replied to the bug - could you
> please try it once, if it builds? If yes, maybe then we simply close
> the bug?
>
> Thanks and Regards
> Nilesh

Re: RFS: robot-testing-framework/2.0.1-1 [ITP] -- Robot Testing Framework

[Steffen Möller]

@Nilesh, if you can help out with a Nilesh-typical review then I happily
sponsor.

Best,

Steffen

Am 15.12.20 um 09:57 schrieb Nilesh Patra:

Hi Daniele

On Tue, 15 Dec, 2020, 2:14 pm Daniele E. Domenichelli,
mailto:ddomeniche...@drdanz.it>> wrote:

Any other comment on this package?
Will anyone sponsor the upload?


Disclaimer: I'm not a DD yet, and hence can't sponsor.

I had a look at the package, and it seems to Depend on python2?

python2 has reached end of the line support and is not in unstable
anymore.
It will also not be a part of next stable release as well.

Can you port the code to be compatible with python3.9? And
additionally other deprecated version too?

Btw, you could also CC debian-ment...@lists.debian.org
 to get more people to have a
look and sponsor the package.

Thanks for all your work on this!

Nilesh

Re: Tinyarray packaging

[Steffen Möller]

Hi Christoph,


On 21.09.20 18:03, Christoph Groth wrote:
> Hello,
>
> As mentioned [1], Steffen Möller and Andreas Tille helped to finish the
> packaging of Tinyarray [2].  Here, I would like to continue off-list
> discussions we had.
>
> Andreas Tille wrote:
>
>> The cythonized files are not really needed for Debian packaging.  Its
>> mandatory to re-build them in the package build process anyway.
>> Otherwise this is considered as the usage of foreign binary code.
>> Thus it makes sense to use a tarball without cython results.
> Actually, tinyarray is a pure C++ Python extension.  There’s no Cython
> in there.  My remark on upstream tarballs containing cythonized files
> was more general, extending to the other packages that I intent to
> package, like Kwant.
>
> Kwant contains substantial amounts of Cython code, and since the
> beginning we have been following the advice of Cython documentation [3]:
>
> “It is strongly recommended that you distribute the generated .c files
> as well as your Cython sources, so that users can install your module
> without needing to have Cython available.”
>
> But for Debian it is of course possible to re-cythonize.  However, this
> does not change the fact that the upstream tarballs contain the
> cythonized files.  And I always believed that Debian is very careful
> (not to say pedantic) about upstream tarballs and keeps them as
> immutable artifacts.

Nothing is patched and hidden (all patches go to debian/patches) but it
is ok to just skip a few files that upstream otherwise ships. For
instance, some upstreams have autoconf/-make generated files in their
source tree. Just anything that is machine-generated should go and
cython, i.e. cython3 now, becomes a build-dependency.

Please have a look at d/copyright files that specify "Files-Excluded"
(man uscan) .  When d/watch then features a
"repack,repacksuffix=+ds,dversionmangle=auto" you are indicating with
the "+ds" in your version that the source tree is not complete and uscan
prepares the source tree for you as instructed by Files-Excluded.

>> If you are tagging releases properly in your
>>
>> https://gitlab.kwant-project.org/kwant/kwant
>>
>> I would prefer this over PyPI.  But using PyPI is fine was well.
> Sure, the tags are correctly signed and we keep them immutable.  We’ve
> been using PyPI in debian/watch, since it is likely *even* more
> persistent ;-) than our own gitlab instance.
>
> However, the only officially released tarballs are those to be found on
> PyPI and on https://downloads.kwant-project.org/.
PyPI is fine. You are the maintainer - you decide, really.
> Is it OK use the gitlab-generated tarballs as upstream for Debian?

You specify in d/copyright how to exclude all the Cython-generated files
and then have uscan repack a .xz source tree that you then
gbp import-orig --pristine-tar  ...
into your local git repository.

> I guess that’s fine, other than that the upstream tarball for a given
> version will then differ from the one used by everyone else.
Hm. Yes. Let alone because of the cython-removal. The xz format is more
efficient than the gz, you will like it. Otherwise set compression=gz in
d/watch.
>> I just sponsored tinyarray.  In principle I would love if Christoph
>> would use
>>
>>  https://wiki.debian.org/DebianPureBlends/SoB
>>
>> It perfectly fits since the its scientific software.  May be even
>> tinyarray would fit in some of the Debian Science Blend?  The final
>> target will fit in any case and I'd strongly recommend to use
>> a repository under science-team for its packaging.
> I’m happy to follow any guidelines, I’m just a bit confused with what
> “DebianPureBlends” has to do with packaging tinyarray for Debian.
> I thought that Debian Pure Blends is an umbrella-term for specialized
> sub-distributions of Debian.
>
> I’m also OK with moving tinyarray to debian-science if this is useful
> and possible.

We just had a series of Python packages moved from med-team to the
Python packaging team - I think it is fine as it is.

We can address bits together via skype or so if I was unclear or you get
stuck for whatever reason.

Best,

Steffen



> [1] https://lists.debian.org/debian-science/2020/09/msg00043.html
> [2] https://salsa.debian.org/python-team/modules/python-tinyarray
> [3] 
> https://cython.readthedocs.io/en/latest/src/userguide/source_files_and_compilation.html#distributing-cython-modules

Re: p4c in debian-science?

[Steffen Möller]

Hi,

Have you considered the electronics team?

https://salsa.debian.org/electronics-team

Best,

Steffen


On 25.08.20 23:19, itd wrote:
> Hi,
>
> is p4c [1]---reference compiler for the P4 [2] programming
> language---within scope for this team?  (I am considering to package
> p4c.  Currently thinking about "how do you plan to maintain it?" from
> reportbug's ITP template.)
>
> [1]: https://github.com/p4lang/p4c
> [2]: https://sigcomm.org/node/3503 & https://p4.org/
>
> Thank you.
>
> Regards
> itd
>
> PS:  Please keep me in CC, I'm not subscribed to debian-science@l.d.o.
>

Re: [RFS] seaborn

[Steffen Möller]

Allowed.

On 10.08.20 20:57, Nilesh Patra wrote:
> Hi,
> currently seaborn FTBFS as reported in: #966991
> I've fixed this temporarily with a patch which can be conveniently
> dropped with the next upstream release.
> My changes are pushed to the team repo[1].
> Please:
>
> gbp clone --pristine-tar https://salsa.debian.org/science-team/seaborn
> 
>
> OR
>
> Grant DM access: PGP key fingerprint:
> 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1
>
> Thanks and Regards
> Nilesh

Re: [RFS] sleef

[Steffen Möller]

allowed

On 30.07.20 15:07, Nilesh Patra wrote:
> Hi,
> I've fixed gcc-10 FTBFS for sleef as reported here in RC bug #957809.
> It now builds with passing tests.
> I've pushed my changes to the team-repo[1]
> Please:
>
> gbp clone --pristine-tar https://salsa.debian.org/science-team/sleef
> 
>
> OR
>
> Grant DM access: PGP key fingerprint:
> 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1
>
> Thanks and regards
> Nilesh

Re: Interested in packaging nextpnr

[Steffen Möller]

Heyho,

On 11.05.20 23:41, Kurt Kremitzki wrote:

Hi Nate,

On Monday, May 11, 2020 3:45:10 PM CDT Nathaniel Graff wrote:

<-snip->
I welcome and appreciate any feedback!

Thanks,
Nate Graff

It's funny, I just purchased an iCEBreaker FPGA over the weekend, was looking at the 
state of supporting software in Debian, and noticed this wasn't packaged last night. Like 
Andreas Tille often says, the definition of a team is "waking up in the morning and 
realizing that somebody else has solved your problem from yesterday." So, thanks for 
the effort on this and welcome!


This is very nice to hear. I am very much looking forward to this.
Wanted to start packaging it myself already :o) However, please also
have a look at

https://salsa.debian.org/electronics-team

I have some confidence that you and nextptr will appreciate the vicinity
to the other packages. So you likely prefer to accommodate nextflow over
there, instead. I am not so ultimately sure about how nextptr will get
along with fpga-icestorm, but maybe the two can somehow be suggested to
each other.

Best,

Steffen

Re: Welcoming Mo Zhou as GSoC student

[Steffen Möller]

+1

On 05.05.20 10:33, Ole Streicher wrote:

Congratulations, Mo!

This is really great and will improve the Debian
science ecosystem a lot! I look forward to this!

Best regards

Ole

Andreas Tille  writes:

Hi,

I've got confirmation that Mo Zhou is accepted as GSoC student
for the topic

BLAS/LAPACK Ecosystem Enhancement for Debian

I'm really happy that Mo is taking over this task and I could not
imagine anybody more competent for this task.  Mo, good luck for this
time!  I do not think that you need any specific introduction here. ;-)

Kind regards

 Andreas.

Request to source-only upload https://salsa.debian.org/science-team/ricks-amdgpu-utils/

[Steffen Möller]

Hello,

My GPG key expired, could someone please source-only upload Rick's
AMDGPU utils from
https://salsa.debian.org/science-team/ricks-amdgpu-utils/ ? I have run
it through cowbuilder.

Many thanks

Steffen

Testing parallel execution Re: h5py and hdf5-mpi

[Steffen Möller]

How do autotests work for MPI?


We simply configure the test script to invoke the same tests using
mpirun.


This is a bigger issue.  We have test suites that test MPI features
without checking MPI processor counts (eg the Magics /Metview code).
One workaround is to enable oversubscribe to allow the test to work
(inefficiently), though the suites that use MPI should really detect
and disable such tests if resources are not found. We will always have
features in our codes that our build/test systems aren't capable of
testing: eg. pmix is designed to work scalably to > 100,000 cores. We
can't test that :-)


Maybe the testing for many cores does not need to happen at upload time.
And maybe the testing for behavior in parallel environments does need to
be performed for all platforms but just one. There could then be a
service Debian provides, analogously to reproducible builds etc,  that
performs testing in parallel environments. The unknown limits of
available cores is something the users of
better-than-what-Debian-decides-to-afford infrastructure can address
themselves. The uploader of a package/build demons would just invoke the
parallel run on a single node. Personally, I would like to see multiple
tests, say consecutively on 1,2,4,8,16,32,64,128,256 nodes and stop
testing when there is no more speedup. How many packages would reach
beyond 32?

There are quite some packages in our distro that are multithreaded, i.e.
that don't need mpi. Today, we don't test their performance in parallel
either. But we should. Don't have any systematic way to do so, yet,
though. I could also imagine that such a testing in parallel
environments help gluing our distro with upstream developers a bit more.
Maybe this is something to discuss together with the cloud team who know
how to spawn an arbitrary number of nodes, quickly? And maybe have an
outreach to phoronix.com and/or their openbenchmarking.org?

Steffen

Re: h5py and hdf5-mpi

[Steffen Möller]

On 13.08.19 06:01, Drew Parsons wrote:

On 2019-08-13 03:51, Steffen Möller wrote:

Hello,


There are a few data formats in bioinformatics now depending on hdf5 and
h5py is used a lot. My main concern is that the user should not need to
configure anything, like a set of hostnames. And there should not be
anything stalling since it waiting for contacting a server. MPI needs to
be completely transparent and then I would very much like to see it.


MPI is generally good that way.  The programs runs directly as a
simple serial program if you run it on its own, so in that sense it
should be transparent to the user (i.e. you won't know its mpi-enabled
unless you know to look for it).  A multicpu job is launched via
running the program with mpirun (or mpiexec).

e.g. in the context of python and h5py, if you run
  python3 -c 'import h5py'
then the job runs as a serial job, regardless of whether h5py is built
for hdf5-serial or hdf5-mpi.

If you want to run on 4 cpus, you launch the same program with
  mpirun -n 4 python3 -c 'import h5py'

Then if h5py is available with hdf5-mpi, it handles hdf5 as a
multiprocessor job.  If h5py here is built with hdf5-serial, then it
runs the same serial job 4 times at the same time.

To reiterate, having h5py-mpi available will be transparent to a user
interacting with hdf as a serial library. It doesn't break serial use,
it just provides the capability to also run multicpu jobs.



This sounds like an omission not to feature, then. Please go for it.



How do autotests work for MPI?

We simply configure the test script to invoke the same tests using
mpirun.


I am somewhat uncertain that Debian needs to be the instance testing
this. But given all the hick-ups that are possibly introduced by
parallelization - would be good to test it. And Debian should then take
some pride in it and announce that.

Does Debian have any mechanisms to indicate that a software can run in
parallel? I am thinking about all the automation that now controls
workflows - like toil and/or cwl - or the testing of reverse
dependencies on some buildd. These can check for the presence for a
binary but don't immediately know if they should start it with mpirun.

Best,

Steffen

Re: h5py and hdf5-mpi

[Steffen Möller]

Hello,

On 12.08.19 18:15, Ghislain Vaillant wrote:

Le lun. 12 août 2019 à 17:04, Mo Zhou  a écrit :

Hi Drew,

thanks for the commits to h5py.

On 2019-08-12 03:10, Drew Parsons wrote:

We need to change h5py to support hdf5-mpi.  h5py is somewhat crippled
as serial-only.

I didn't even notice that since my use case for hdf5 is light-weight.
(training data is fully loaded from hdf5 into memory)

Same here. My use case for h5py is for storing medical images and raw
data, all of which usually fit into a single workstation.


We could just do it straight away in python3-h5py.  Is there much
point having h5py support both hdf5-serial and hdf5-mpi?  Perhaps
there is, in which case we need to set up multiple builds and use
alternatives to set the preferred h5py.

In fact I don't know. Maybe @ghisvail could answer?

I can't answer this question since I have never used the parallel
builds of HDF5 and h5py.

Are we really sure alternatives are appropriate for this particular use case?

Python has got other means for injecting alternative dependencies such
as PYTHONPATH and virtualenvs.


A related question, is there much point setting up support for
hdf5-mpich as well as hdf5-openmpi?  Increasing build and
package-alternatives complexity, but once it's done once to
distinguish hdf5-serial from hdf5-mpi, it's not that much more work to
also split hdf5-mpi between hdf5-mpich and hdf5-openmpi.

My personal opinion is to just choose a reasonable default,
unless users shouted for that.

Same here.

We can't catter to every use case in the scientific community, so the
best we can do is choose something sensible with the data point we
have got (if any) and later reconsider with users feedback.


Compiling every possible configuration will eventually make
the science team maintenance burden notorious. h5py is not
like BLAS64/BLAS-flavours which are clearly needed by some
portion of scientific users.

There is also the question of long-term maintainability. For HPC
builds, people will build their stack from source anyway for maximum
performance on their dedicated hardware. That was the case back when I
used to work for a university. I don't think targeting these users is
worth the trouble compared to research staff who want to prototype or
deploy something quickly on their respective workstation or laptop
where resources are more constrained. That's the background I am
coming from personally, hence why MPI never was considered at the
time.

Your mileage may vary of course, and I welcome (and value) your opinions.

Please let me know.


There are a few data formats in bioinformatics now depending on hdf5 and
h5py is used a lot. My main concern is that the user should not need to
configure anything, like a set of hostnames. And there should not be
anything stalling since it waiting for contacting a server. MPI needs to
be completely transparent and then I would very much like to see it.

For packaging I would prefer it all to be as simple as possible, so not
dragging in MPI would be nice, i.e. I would like to see the -serial
package that provides hdf5. As long as the two different flavours of MPI
cannot be used in mixed setups, I suggest to have hdf5-openmpi and also
hdf5-mpich if you still have the energy left.

How do autotests work for MPI?

Cheers,

Steffen

e4s - there is so much out there - too much for us to cope

[Steffen Möller]

Hello,

I just came across https://e4s-project.github.io/ and am both fascinated
and shocked about how free HPC software much I am not aware of. Their
answer to everything are containers. Does anyone on this list have any
ties with these folks?

Would Debian (and Ubuntu with it) benefit from packaging more of it? I
have seen the HDF5 library as something we ship, nothing else, really.
Would anybody know how to get some funding for packaging this
infrastructure? I admit thatI would rather want learn how to use these
packages than to invest my time into packaging them. Sounds like I
should just go for the tutorials and then the containers, right?

Cheers,

Steffen

Science-supporting Crypto Currency - an issue for Debian Science?

[Steffen Möller]

Hello,

I discovered Gridcoins for me (https://www.gridcoin.us). They have a 
package for Ubuntu and I have toyed with the thought to bring their 
wallet also to Debian - too busy, have instead created an Ubuntu 
instance with some cloud provider. And it works. It works nicely. So 
nicely, that I want it to succeed also more in our daily routines and 
also for less technical people who this way can contribute to the sciences.


I know there is https://salsa.debian.org/cryptocoin-team/ and any Debian 
package for the Gridcoin wallet should likely go there - but is there 
any opinion of my listmates about it? There are other interesting 
presumed science-relevant technologies emerging like the Golem Network 
(https://golem.network/) that would compete for resources. Is this all 
anything the Debian Science should somehow support or otherwise position 
itself? I personally see this all as valuable since this allows for 
collaborations to perform community sciences with more complicated and 
resource-demanding workflows than what would fit on single 
computers/local clusters and what should be discussed by many 
contributing brains.


Cheers,

Steffen

Uploaded maeparser to salsa for internal review

[Steffen Möller]

Hello,

I had addressed an update rdkit which prompted me with a couple of new
dependencies - maeparser is one of them. I named it
"schroedinger-maeparser" since I had felt to be much clearer for those
who have no immediate association of mae with the .mae ending of Maestro
files. Like me.

The github account of Schroedinger happily ignored the Umlaut in their
name. My name having the same Umlaut, I felt inclinded to save it, so I
am spelling it as what I think to be called a digraph "oe". It feels
natural to me, no idea if you want that for our Debian packages, though.

I originally planned to upload the package to debichem, but I could not
create a directory over there, so, it landed on
https://salsa.debian.org/science-team/schroedinger-maeparser. I hope
that is OK.

Wrt to the SOVERSION I am in contact with upstream
(https://github.com/schrodinger/maeparser/issues/22).

Cheers,

Steffen

Re: Package for Apache SINGA - a deep learning library

[Steffen Möller]

Hello,

On 01.11.17 16:37, Moaz Reyad wrote:
> Hi All,
>
> About two months ago, I submitted a RFS for SINGA:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873459
> 
>
> But I did not find any sponsor until now.
>
> SINGA is an Apache incubator project and we are working on graduating
> it from the incubator to become a top level project. Creating a Debian
> package will increase its usability and help gaining more users. This
> will eventually help in the project graduation.
>
> It is also my first Debian package, so I have a little experience. But
> it is a good opportunity to learn, so I can help in packaging other
> software in future.
>
> I see that there is a discussing about deep learning software
> (Theano/TensorFlow), would you also consider helping with the SINGA
> package?
>
I have not seen any reply to your kind request so I thought I should at
least say hello. I am somewhat busy though and I tend to think you
deserve someone with more leisure at his/her hands, preferably someone
who has some experience with your software too - have you found a
sponsor already, possibly?

Cheers,

Steffen

Re: It's not exactly science, but...

[Steffen Möller]

On 25.08.17 21:39, Andreas Tille wrote:
> Hi,
>
> On Sat, Jul 29, 2017 at 08:13:53PM -0500, JohnT wrote:
>> I've noticed that there aren't any clearcut metapackages or distros
>> focused on business (office mgmt, contact lists of customers, prospects,
>> vendors, etc, specialized software for real estate, insurance, law,
>> vehicle sales, repair and parts, shipping, receiving and logistics,
>> various accounting topics, factory operation, farming, and other common
>> types of small businesses that may like to use off-the-shelf open-source
>> software. Is this a set of niches Debian developers would have some
>> interest in working on?
> Since I like the idea in principle you might like to take over the dead
> list debian-enterprise.

I also like the idea. Call out for a Sprint to develop/implement a strategy,
I suggest. Mine would likely be to start with big data and GIS since we
have quite some bits on that already and it is somewhat trendy to attract
a larger audience with an announcement.

Some vicinity to teaching institutions may help.

Steffen

Re: Looking for a sponsor : openmeca package [ITP: #850590]

[Steffen Möller]

Hello Damien,

On 17.04.17 22:12, dada wrote:
> Hello all,
> I am looking for a sponsor for the openmeca software :
> https://gitlab.com/damien.andre/openmeca
I like it, thank you for preparing your package.
> I open an
>  - ITP : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590
>  - RFS : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851936
>  - and fill an entry in the SoB page :
> https://wiki.debian.org/DebianPureBlends/SoB
>  - git repository :
> https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/
>  - menthor repository : https://mentors.debian.net/package/openmeca
>
> This package was previously rejected by the FTP team. I rewrite (with
> a high
> attention) a new copyright file and I put out some source files
> (already packaged
> by debian).

>
>
> Actually, Lintian give me the following warning :
> I unused-file-paragraph-in-dep5-copyright
> paragraph at line 21
> paragraph at line 31

I'll send a revised version to you directly. This will eliminate one
warning if not both.

> P debian-watch-may-check-gpg-signature

When you click on the hyperlink of those headers then you get to a
detailed description which is typically very informative and
educational. Please check out e.g.
https://lintian.debian.org/tags/debian-watch-may-check-gpg-signature.html
in this case.

> openmeca
> I desktop-entry-lacks-keywords-entry
> usr/share/applications/openmeca.desktop
> I hardening-no-bindnow
> bin/openmeca
> I hardening-no-fortify-functions
> bin/openmeca
Please have a look at https://wiki.debian.org/Hardening .
> I spelling-error-in-binary
> bin/openmeca registe register
> bin/openmeca LengH Length
> bin/openmeca ot to
> bin/openmeca sofware software
> bin/openmeca informations information
This is something for upstream to fix, but since you are also upstream,
well :o) I have contributed a typos.patch that fixes the last two typos
in the source tree. It is in the debian-science git repository.
> P no-upstream-changelog
> openmeca-dbgsym
> W debug-file-with-no-debug-symbols
>
> usr/lib/debug/.build-id/f5/8607823e68e02397132b8d908a287c69063706.debug
My hunch is that you have a strip already in your regular build, which
is why nothing is left at this stage for the Debian packaging to separate.
> Please feel free to contact me for any further information.
> Thank you,
Thank you for your efforts. You started with an impressively big
project. Your next packages will be easier.

Best,

Steffen

Re: Why is libosmocore maintained in Debian Science?

[Steffen Möller]

Heya,

I personally like it in Debian Science. What came to mind is a friendly
bunch of people, some of which also associated with Debian Science, of
https://alioth.debian.org/projects/pkg-fso/ . The repository is not
overly active, anyway, _if_ you feel like moving it then this may be a
good new home - as would be a group github repository.

Steffen


On 12/02/2017 20:37, Ruben Undheim wrote:
> Hi,
>
> There is not really a well thought out reason for maintaining it in
> the Debian Science team.
>
> I arrived at these mobile packages via software-radio packages such as
> "osmo-trx", which I sort of consider science. Getting to libosmocore,
> we are getting higher in the OSI model, and suddenly it becomes more
> of production environment applications.
>
> I guess I was just thinking that most of my other packages have been
> science packages, I am in the Science team, and there are friendly
> sponsors interested in these packages also in the Science team. Also,
> where to draw the line between science and not science is not very
> clear.. A third reason is that I have been told that it is better to
> maintain packages in teams, and of those teams in which I am a member,
> Debian Science was the only one that vaguely could fit.
>
>
> Cheers
> Ruben
>
>
> 2017-02-11 19:03 GMT+01:00 Andreas Tille :
>> Hi Thorsten,
>>
>> On Sat, Feb 11, 2017 at 02:13:49PM +0100, Thorsten Alteholz wrote:
>>> On Fri, 10 Feb 2017, Andreas Tille wrote:
 I admit I have no idea why this is maintained inside Debian Science.
>>> As I have similar packages in the pipeline, I was wondering as well whether
>>> Debian Science should be their new home. Maybe this is a good opportunitiy
>>> to start an own mobile team?
>> As I said there is no point in beeing exclusive but I think newcomers
>> who might also intend to package some mobile applications might fail to
>> find their potential team mates "hidden" in Debian Science team.  If
>> you ask me I think a Debian mobile team is a pretty good idea - it could
>> even use the Blends framework to categorise their packages.
>>
>> I'd really welcome if you would create such a team.
>>
>> Kind regards
>>
>>  Andreas.
>>
>> --
>> http://fam-tille.de

Aw: request for review: new yosys packages

[Steffen Möller]

Hi Sebastian,

> Gesendet: Freitag, 25. März 2016 um 05:51 Uhr
> Von: "Sebastian Kuzminsky" 
> An: debian-science@lists.debian.org
> Betreff: request for review: new yosys packages
>
> Hi folks, I'm a new member joining the debian-science team.  I've been
> working with Ruben Undheim on updating the yosys package, which does
> Verilog RTL synthesis for FPGAs.
> 
> I recently completed a reorganization of the packaging that we had
> discussed, and Ruben suggested I ask for further feedback here.  My work
> is based on the 0.6-1 packaging of yosys which I did under Ruben's
> guidance.  My proposed new packaging is in this branch:
> 
> https://anonscm.debian.org/cgit/debian-science/packages/yosys.git/log/?h=doc-dev-debs
> 
> It splits the old yosys deb into two packages, yosys and yosys-dev, and
> it adds a new yosys-doc package.
> 
> Since it adds new binary packages (from the existing source package), I
> understand it needs special authority to upload.
> 
> I'm seeking someone with this authority to review my packages and
> provide me feedback, iterate until they are acceptable, and then sponsor
> the new packages with an upload.

a warm welcome from my side. If Ruben has seen your work and is certain
that it is good enough for an upload then it certainly is :)

Let me go to where my key is and I'll upload. Many thanks (and regards)
also to Ruben for his mentoring.

Best,

Steffen

Re: RFS: openbsc/0.15.0-1 [ITP]

[Steffen Möller]

I have changed my mind and just uploaded. Just contact Ruben, anyway :)

Steffen


On 26/02/16 11:45, Steffen Möller wrote:
> Hello,
>
> Ruben's packages are typically just ready to upload. And the OpenBSC is
> a mind-boggling Open Source movement with consequences that we do not
> yet grasp, really. It is about running your own mobile phone
> infrastructure. To help Ruben's network in the community to develop I
> happily delay my sponsoring and hope someone to jump in  or it will
> be next Monday.
>
> Best,
>
> Steffen
>
> On 20/02/16 18:34, Ruben Undheim wrote:
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>> Dear mentors and Debian Science fellows,
>>
>> I am looking for a sponsor for the new package "openbsc":
>>
>>  Package name:  openbsc
>>  Version:   0.15.0-1
>>  Upstream author:   Osmocom
>>  License:   Mainly AGPL-3+
>>
>>
>> Andreas Tille and Steffen Möller have helped me sponsoring all the libraries
>> needed by OpenBSC, and now the time has come to actually get OpenBSC itself
>> uploaded!
>>
>> Is there anyone else who would like to help me out this time? The maintainer
>> for the package is "Debian Science Maintainers" and I am currently the only
>> listed uploader. I am a DM, so strictly only one upload is necessary.
>>
>>
>> It builds these binary packages:
>>
>>   osmocom-bsc
>>   osmocom-nitb
>>   osmocom-ipaccess-utils
>>   osmocom-bs11-utils
>>   osmocom-sgsn
>>   osmocom-gbproxy
>>   osmocom-bsc-nat
>>   openbsc-dev
>>
>> For further information about OpenBSC, please see:
>>  - https://bugs.debian.org/806583
>>  - http://openbsc.osmocom.org/trac/wiki/OpenBSC
>>
>> You can either download the package with:
>>  - dget -x 
>> http://mentors.debian.net/debian/pool/main/o/openbsc/openbsc_0.15.0-1.dsc
>>
>> or clone the repo with:
>>  - gbp clone 
>> https://anonscm.debian.org/git/debian-science/packages/openbsc.git
>>
>>
>> Best regards,
>> Ruben
>>
>




signature.asc
Description: OpenPGP digital signature

Re: RFS: openbsc/0.15.0-1 [ITP]

[Steffen Möller]

Hello,

Ruben's packages are typically just ready to upload. And the OpenBSC is
a mind-boggling Open Source movement with consequences that we do not
yet grasp, really. It is about running your own mobile phone
infrastructure. To help Ruben's network in the community to develop I
happily delay my sponsoring and hope someone to jump in  or it will
be next Monday.

Best,

Steffen

On 20/02/16 18:34, Ruben Undheim wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors and Debian Science fellows,
>
> I am looking for a sponsor for the new package "openbsc":
>
>  Package name:  openbsc
>  Version:   0.15.0-1
>  Upstream author:   Osmocom
>  License:   Mainly AGPL-3+
>
>
> Andreas Tille and Steffen Möller have helped me sponsoring all the libraries
> needed by OpenBSC, and now the time has come to actually get OpenBSC itself
> uploaded!
>
> Is there anyone else who would like to help me out this time? The maintainer
> for the package is "Debian Science Maintainers" and I am currently the only
> listed uploader. I am a DM, so strictly only one upload is necessary.
>
>
> It builds these binary packages:
>
>   osmocom-bsc
>   osmocom-nitb
>   osmocom-ipaccess-utils
>   osmocom-bs11-utils
>   osmocom-sgsn
>   osmocom-gbproxy
>   osmocom-bsc-nat
>   openbsc-dev
>
> For further information about OpenBSC, please see:
>  - https://bugs.debian.org/806583
>  - http://openbsc.osmocom.org/trac/wiki/OpenBSC
>
> You can either download the package with:
>  - dget -x 
> http://mentors.debian.net/debian/pool/main/o/openbsc/openbsc_0.15.0-1.dsc
>
> or clone the repo with:
>  - gbp clone 
> https://anonscm.debian.org/git/debian-science/packages/openbsc.git
>
>
> Best regards,
> Ruben
>




signature.asc
Description: OpenPGP digital signature

Aw: Re: debian-science sprint?

[Steffen Möller]

I can only support Christian - get it off. The downside is that "Seaside during Winter" is a Debian Med theme already :)

Could we possibly have "Mountains and Spring", instead? Andreas? Ole may know such venues with a large telescope that possibly even have Internet.

 

Best,

 

Steffen

 

Gesendet: Donnerstag, 10. September 2015 um 16:46 Uhr
Von: "Anton Gladky" 
An: "Debian Science List" 
Betreff: Re: debian-science sprint?




Hi all,
 
I could probably also come, but just for 2 days.
 
Best regards







Anton

 

2015-09-08 16:41 GMT+02:00 Christian T. Steigies :

Hi,
a few of us met in Heidelberg where Andreas kindly organized a BoF for us
scientists:

https://summit.debconf.org/debconf15/meeting/214/debian-science-bof/

I think this was the first time that I met some Debian scientists (that I
did not already know before from other topics).  We briefly discussed a
debian-science sprint, we could have our own, participate in a (highly
recommended!) debian-med sprint, or have monthly virtual sprints as somebody
suggested.  I think in-person meetings are much more effective, at least to
form a "group" of debian scientists, later virtual sprints may also work
well.  I remember at least two suggestions for sprints, but there was not a
lot of feedback, so I repeat my offer to host a sprint in Kiel here.  It is
fairly easy for me to get rooms (with good internet connection and a decent
coffee maker nearby) during the weekends (debian-med typically runs from
friday afternoon to sunday afternoon) or during the spring break.  There is
a hostel nearby where we can get single rooms for about 100EUR per week
(30min walking or 10-20min by bus), there are hotels further away but with
direct bus connection to the University.  For some detailed information I
have put the localinfo website that we had for a summerschool a few years
back online again (prices may have changed):

http://www.ieap.uni-kiel.de/et/people/steigies/summerschool/localinfo.html

If people are interested, I would prefer a date next year in the spring
break (late February or March) or Pfingsten (Pentecost?  16-22.  May) if we
want to meet during (for the whole) the week.  Other weekends should be
possible also for a shorter meeting (in February it may still be dark, cold
and wet, ask Andreas or Michael, but starting in May the weather starts to
become nice, not as warm as HD, though).  But before we talk about dates, I
would like to know if there is some interest at all in a debian-science
sprint.  As Andreas mentioned, there may be some support by Debian, so
perhaps we could even support Dirk to fly in to discuss issues with
maintainership of R packages face to face.

So what do you think?
Christian
 

Aw: Re: Re: Location for CWL tool descriptions

[Steffen Möller]

Hello Michael,



by all means, /usr/local/share/cwl sounds like right, too, just let me attemt to quickly serialise all the input my mind gives me:



* In my perception these CWL instructions are mostly independent of the installed software. As such I do not feel the urge to connect those too much with the installation directory of any particular software

* CWL by itself is in /usr/share but that directory is not meant to be touched by anyone/anything. Extra bits that the

 end users changes or configures should be in /etc/appname.conf or /etc/appname.d/*

* /usr/local is not used much, with the exception of locally compiled/installed software that is not packaged.

 scenario: that locally installed package is CWL-aware, then yes, /usr/local/share/cwl sounds like right

 scenario: that locally installed package has never heard of the CWL and the system administrator aims at adding respective instructions, then I would still prefer /etc/cwl.d but am happy to be corrected if that is unappropriate for some reason

* scenario: average Joe Linux user aims at integrating a command line application that ships with his distro and is already installed on the machine he is working with

 - that application will be installed in /usr/{bin,lib,share}

 - any extra config should not go in /usr/local and not into anything below /usr but /etc/cwl.d




Have you discussed man pages for the individual workflow descriptions?



Best,



Steffen






Gesendet:Dienstag, 07. Juli 2015 um 18:07 Uhr
Von:Michael Crusoe michael.cru...@gmail.com
An:Debian Med Project List debian-...@lists.debian.org
Cc:Debian Science List debian-science@lists.debian.org
Betreff:Re: Re: Location for CWL tool descriptions


Hello Steffen,


Thank you for your support. I would recommend that local users can use /usr/local/share/cwl for site-wide non-Debian installed software and {XDG_DATA_HOME}/cwl/{binary-name}.cwl for per-user installed apps.



On Mon, Jul 6, 2015 at 11:17 AM Steffen Mller steffen_moel...@gmx.de wrote:

Hello,

I am happy to see this. I tend to agree that /usr/share/cwl sounds like the right place for everything coming through upstream.

To accomodate for local user (or Debian package maintainer) additions, I suggest to also allow for /etc/cwl.d/ . Some
/etc/cwl.conf may have an option to support any additional set of folders.

Best,

Steffen


 Gesendet: Sonntag, 05. Juli 2015 um 19:03 Uhr
 Von: Andreas Tille andr...@an3as.eu
 An: debian-...@lists.debian.org, Debian Science List debian-science@lists.debian.org
 Betreff: Re: Location for CWL tool descriptions

 Hi,

 I think Michaels proposal is sensible but I think Debian Science
 should be informed as well - so forwarding to this list.

 Kind regards

Andreas.

 On Sun, Jul 05, 2015 at 03:34:34PM +, Michael Crusoe wrote:
  Hello Debian Med team,
 
  The Common Workflow Language [CWL] working group has created a portable
  method to describe the command line interface of non-interactive
  (scientific) computing tools.
 
  Ideally tool authors would write and ship such descriptions with their
  tools. In suggesting that they do so we need to provide advice as to where
  to install said files.
 
  I propose that such descriptors be installed into
  /usr/share/cwl/{binary-name}.cwl
 
  For applications not installed site-wide I propose that all CWL tool
  descriptions should go to XDG_DATA_HOME/cwl/{binary-name}.cwl
  XDF_DATA_HOME is from the XDG Base Directory Specification [XDGBDS]; as
  per that standard it should be interpreted as HOME/.local/share if not
  defined.
 
  What do people think? By my reading this is compliant with the Debian
  Policy Manual but I am happy to hear other suggestions or corrections.
 
  [CWL] http://common-workflow-language.github.io
  [XDGBDS] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
 
  Cheers,
 
  --
  Michael R. Crusoe
  --
  Michael R. Crusoe: Programmer  Bioinformatician cru...@ucdavis.edu
  The lab for Data Intensive Biology; University of California, Davis
  https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe

 --
 http://fam-tille.de


 --
 To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/20150705170308.gb5...@an3as.eu




--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/trinity-54451669-8713-4c71-9729-307484147e46-1436177814539@3capp-gmx-bs37




--

Michael R. Crusoe: Programmer  Bioinformatician cru...@ucdavis.edu
The lab for Data Intensive Biology; University of California, Davis
https://impactstory.org/MichaelRCrusoehttp://twitter.com/biocrusoe






-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 

Aw: Re: Location for CWL tool descriptions

[Steffen Möller]

Hello,

I am happy to see this. I tend to agree that /usr/share/cwl sounds like the 
right place for everything coming through upstream. 

To accomodate for local user (or Debian package maintainer) additions,  I 
suggest to also allow for /etc/cwl.d/ .  Some
/etc/cwl.conf may have an option to support any additional set of folders.

Best,

Steffen


 Gesendet: Sonntag, 05. Juli 2015 um 19:03 Uhr
 Von: Andreas Tille andr...@an3as.eu
 An: debian-...@lists.debian.org, Debian Science List 
 debian-science@lists.debian.org
 Betreff: Re: Location for CWL tool descriptions

 Hi,
 
 I think Michael's proposal is sensible but I think Debian Science
 should be informed as well - so forwarding to this list.
 
 Kind regards
 
Andreas.
 
 On Sun, Jul 05, 2015 at 03:34:34PM +, Michael Crusoe wrote:
  Hello Debian Med team,
  
  The Common Workflow Language [CWL] working group has created a portable
  method to describe the command line interface of non-interactive
  (scientific) computing tools.
  
  Ideally tool authors would write and ship such descriptions with their
  tools. In suggesting that they do so we need to provide advice as to where
  to install said files.
  
  I propose that such descriptors be installed into
  /usr/share/cwl/${binary-name}.cwl
  
  For applications not installed site-wide I propose that all CWL tool
  descriptions should go to $XDG_DATA_HOME/cwl/${binary-name}.cwl
  $XDF_DATA_HOME is from the XDG Base Directory Specification [XDGBDS]; as
  per that standard it should be interpreted as $HOME/.local/share if not
  defined.
  
  What do people think? By my reading this is compliant with the Debian
  Policy Manual but I am happy to hear other suggestions or corrections.
  
  [CWL] http://common-workflow-language.github.io
  [XDGBDS] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
  
  Cheers,
  
  -- 
  Michael R. Crusoe
  -- 
  Michael R. Crusoe: Programmer  Bioinformatician cru...@ucdavis.edu
  The lab for Data Intensive Biology; University of California, Davis
  https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe
 
 -- 
 http://fam-tille.de
 
 
 -- 
 To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/20150705170308.gb5...@an3as.eu
 
 


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-54451669-8713-4c71-9729-307484147e46-1436177814539@3capp-gmx-bs37

Aw: Re: healpix-cxx: stuck in testing due to slow unit tests on mips builder

[Steffen Möller]

Hi Leo,

 On May 8, 2014, at 4:18 AM, Steffen Möller steffen_moel...@gmx.de wrote:
 
  I noticed that healpix-cxx hasn't been able to migrate into testing 
  because of a build failure on mips. It looks like the build timed out 
  during unit tests. See build log:
  
  https://buildd.debian.org/status/logs.php?arch=mipspkg=healpix-cxx
  
  However, I just built it successfully using 'apt-get --build source 
  healpix-cxx' on qemu using aurel32's instructions and images:
  
  http://people.debian.org/~aurel32/qemu/mips/
  
  I used the 64-bit mips kernel and a wheezy image that I upgraded to sid. m
  
  I did have to let the build run overnight inside the emulator overnight on 
  my 2.3 GHz Intel Core i7. Is it possible to request the package to be 
  resubmitted to another mips builder?
  
  I am not sure, but could we not just perform a binary upload of that MIPS 
  package? Prepending to be a build demon ourselves? The emulated builds 
  violate some policy, I presume.
 
 I don't know. There are extensive instructions about binNMU uploads 
 (https://wiki.debian.org/binNMU), but this would be different: a binary 
 upload by the maintainer.
 
 The main disadvantage of my own build is that it wasn't done in pbuilder; I 
 just booted the emulator, upgraded to sid, then did 'apt-get build-dep 
 healpix-cxx; apt-get source --build healpix-cxx'.

To me, what you did sounds like fine. Please somehow render a signed binary 
package available for me somewhere and I will see what happens when I sponsor 
that. When I oversee things right then we do not do much harm and I learn how 
to play build daemon.

 Do you know how long it should take for someone to reply to the give-back 
 request? I have not heard back yet, and the rebuild has not been attempted 
 yet:
 https://buildd.debian.org/status/logs.php?pkg=healpix-cxxarch=mipssuite=sid

No idea.

  Also, you could decide not to run the unit tests if dpkg-architecture 
  -qDEB_BUILD_ARCH indicates the MIPS architecture. Other ideas?
 
 Well, the only major change from 3.11.2-4 to 3.11.2-5 was that we added the 
 debug package. It's hard to see why that would suddenly make the build and 
 unit tests take days.
 
 It really looks like builder lucatelli is just very slow. If we put in a 
 special case for MIPS, it might succeed only because it lands luckily on a 
 different builder.

Agreed.

Steffen


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-a1339351-2b68-4a35-87a5-084e8b53c001-141979639@3capp-gmx-bs06

Aw: healpix-cxx: stuck in testing due to slow unit tests on mips builder

[Steffen Möller]

Hello,

 I noticed that healpix-cxx hasn't been able to migrate into testing because 
 of a build failure on mips. It looks like the build timed out during unit 
 tests. See build log:
 
 https://buildd.debian.org/status/logs.php?arch=mipspkg=healpix-cxx
 
 However, I just built it successfully using 'apt-get --build source 
 healpix-cxx' on qemu using aurel32's instructions and images:
 
 http://people.debian.org/~aurel32/qemu/mips/
 
 I used the 64-bit mips kernel and a wheezy image that I upgraded to sid.
 
 I did have to let the build run overnight inside the emulator overnight on my 
 2.3 GHz Intel Core i7. Is it possible to request the package to be 
 resubmitted to another mips builder?

I am not sure, but could we not just perform a binary upload of that MIPS 
package? Prepending to be a build demon ourselves? The emulated builds violate 
some policy, I presume. Also, you could decide not to run the unit tests if 
dpkg-architecture -qDEB_BUILD_ARCH indicates the MIPS architecture. Other ideas?

Cheers,

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-1ac9e6bc-9600-4a3b-a909-35dc6c899db5-1399547888606@3capp-gmx-bs59

Preparing packages Freifunk (WLAN mesh) gateways for Debian

[Steffen Möller]

Hello,

local students and resident geeks have collected a series of
technologies on top of OpenWRT to establish an IPv6 mesh of
Wifi routers. A subset of machines of a mesh island links to
the InterNet and all nodes together form a private network.
More on http://www.freifunk.net (German).

There are tons of ideas about it all. Mine, which links it to
Debian Science a bit, is the support of sensors to those routers
(decent enough models with USB ports start at $15) so we get a 
sensor net. Others see solar devices to have emergency internet
set up in a mostly brainless way.

Some brain power remains to be required for the setup of gateways
to the Internet. Every community needs a few of those, commonly
with different providers / hosters. I am now helping with the 
packaging of that gateway software infrastructure for Debian,
hoping to further smoothen the overall experience with such
community networks.

I'll keep this list informed about respective progress and will
eventually point to an apt-get based recipe to set things up.
I would like to hear about similar efforts at other corners of
the world. Also, if there are corners in the world with an
interest to employ this technology, I would do my best to find
local mentors and/or to help out myself. My upcoming corner
is our Internet-free institute cellar with freezers to
cheapishly monitor their temperature.

Many greeting

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-340cbe11-c94b-4a16-a55c-dfa41284a56b-1395834383529@3capp-gmx-bs30

Aw: Re: Looking for sponsorship: libfann, pyevolve (updates)

[Steffen Möller]

Hi Christian,

 On 2014-03-04 15:31, Christian Kastner wrote:
  I've secured sponsorship for some packages already, but would still
  require sponsorship for the two packages libfann and pyevolve.
  
  Both packages had the DM-Upload-Allowed field set. That field has been
  obsoleted by the new dak approach, but rather than asking that the
  permissions be carried over, I'd prefer a sponsor the verify/upload my
  packages first, as it's been a while since my last work.

This is noble, but as long as it is working and you have something lintian
clean - you'd have my blessing.

  For those interested, source packages and git repositories can be found
  below.
 
  libfann:

  http://www.kvr.at/debian/pool/main/libf/libfann/libfann_2.1.0~beta~dfsg-9.dsc
git://scm.kvr.at/git/pkg-libfann.git
  
  pyevolve:

  http://www.kvr.at/debian/pool/main/p/pyevolve/pyevolve_0.6~rc1+svn398+dfsg-3.dsc
git://scm.kvr.at/git/pkg-pyevolve.git
 
 I'm still looking for a sponsor, so I thought I'll just ping the list again.

For the package review you aimed at above, I suggest you inject your packaging
to the Debian Science repository - Debian folder only. The additional eyeballs
may contribute to the review and should also help avoid overly detrimental
effects in case of neglect. Sponsors you do not need unless
there are additional packages. 

Cheers,

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-89b2c494-bcff-4c9e-9497-6225248359fe-1394702687436@3capp-gmx-bs60

Aw: Re: Request for Ideas - Astronomy working group

[Steffen Möller]

Hallo,

 Andreas Tille andr...@an3as.eu writes:
  On Thu, Mar 13, 2014 at 11:32:50AM +0100, Оlе Ѕtrеісhеr wrote:
  I'd prefer debian-astronomy or -astrophysics. Otherwise we will have
  discussions about the inclusion of astrology
  software. debian-astrophysics may soound too professional and prevent
  amateurs from joining. Probably the name is open for voting ;-)
 
  If you want to go the naive route about voting please be prepared to
  spend a lot of time with bike-shedders who *never* has done *any*
 
 I just meant: let's discuss it here, and we take what most of the people
 who want to contribute prefer.
 
 In the moment it looks like astro.

wx_Astro_Capture was just uploaded :) ... and I personally even would not mind
to tolerate the one or other astrology package ... just imagine some Debian
Astrology people (an oxymoron?) would start Debian-Astro, instead of us.
 
   A developer mailing-list such as debian-astro-devel@alioth would be very
   nice so we can all be in copy when each of us discuss something with
   upstream, for instance.
  
  debian-astron...@alioth.debian.org?
 
  do you mean
 s/alioth/lists/
  or
 s/alioth/lists./
  ??
 
 I didn't get this. -v please.

Lists are at lists.debian.org, not at alioth.

 Once we get the name decided, I will request a new mailing list on 
 lists.debian.org.
 
  In the moment, I would not differ between users and developers, just
  like debian-science (which also has no -devel).
 
  Just make sure you have a user oriented list (as debian-science) and
  a list that serves as the maintainer of the packages.  I do not think
  that mixing up these two is a good idea.
 
 Yes, I think the best way is as it is done for debian-science.

Sounds all fine with me.

Steffen


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-d0f74500-3b9c-46ba-868f-3134fa380714-1394722966635@3capp-gmx-bs60

Aw: Re: Re: wxAstroCapture / Astronomy working group

[Steffen Möller]

Hi Ole,

 Steffen Möller steffen_moel...@gmx.de writes:
  I have just come up with some initial packaging for cbp2make and placed
  it on Debian-Science. It should possibly at some point move elsewhere, but
  since there is nothing outside Debian-Science using this at the moment,
  it may not be the worst of all possible locations.
 
 I fixed the tinyxml problem there (tinyxml and tinyxml2 are API
 incompatible); now the lintian error is gone. However, I would not like
 to maintian this package since it has no use for myself.

Nice! Many thanks!

I volunteer to sponsor and will cross-check with Peter about who does
what towards keeping wxAstroCapture in pristine shape.

Best,

Steffen


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/trinity-e1b6be9e-a234-48bd-92c2-ea571a2f9a1f-1392646821431@3capp-gmx-bs46

Aw: Re: Re: wxAstroCapture / Astronomy working group

[Steffen Möller]

Hello again,

 Von: Steffen Möller steffen_moel...@gmx.de
  Steffen Möller steffen_moel...@gmx.de writes:
   I have just come up with some initial packaging for cbp2make and placed
   it on Debian-Science. It should possibly at some point move elsewhere, but
   since there is nothing outside Debian-Science using this at the moment,
   it may not be the worst of all possible locations.
  
  I fixed the tinyxml problem there (tinyxml and tinyxml2 are API
  incompatible); now the lintian error is gone. However, I would not like
  to maintian this package since it has no use for myself.
 
 Nice! Many thanks!
 
 I volunteer to sponsor and will cross-check with Peter about who does
 what towards keeping wxAstroCapture in pristine shape.

Update: have done more on it, will upload tonight.

Steffen


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/trinity-a83dfde0-f148-435c-8f81-3168219ee139-1392658686797@3capp-gmx-bs46

Aw: Re: wxAstroCapture / Astronomy working group

[Steffen Möller]

Hi Peter, hi Ole,

 Von: Оlе Ѕtrеісhеr debian-de...@liska.ath.cx

 Peter Cock p.j.a.c...@googlemail.com writes:
  (b) Bundle the generated Makefile with the Debian
  (c) Include the generated Makefile in the upstream repository
 
  This is not possible since then you dont build the package from the
  sources, but from some pre-generated file. It would sooner or later lead
  to a bug report about this fact.
 
  This is comparable to the requirement to rebuild the configure file
  from the configure.ac  Co. sources [1]
 
  Neither of these options seemed ideal, although I can imagine
  the upstream project could automate updating the Makefile to
  avoid this (e.g. as part of a release script, a git hook, or similar).
 
 The point here is that Debian requires to compile the code from the
 source. If the Makefile is generated, it is not source, even if it is
 part of the source distribution.

I have just come up with some initial packaging for cbp2make and placed
it on Debian-Science. It should possibly at some point move elsewhere, but
since there is nothing outside Debian-Science using this at the moment,
it may not be the worst of all possible locations.

I suggest to go ahead with cbp2make as a build dependency and we see to 
get both packages matured over time.

Cheers,

Steffen


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/trinity-92a07fbc-deef-40ad-926b-611dae8fa555-1392592550729@3capp-gmx-bs42

team building Aw: Re: Request for Ideas - Astronomy working group

[Steffen Möller]

Hello,

I have already met Christian (professionally close to space),
Andreas (physically close to space - as in living withing a
mountainous area) and I (envious) have already met. The focus
should be on those who do not know each other, yet, and give
those this extra opportunity to increase their productivity
and ease their future communication.

Very much I would like to see Bamm from the Phillipines attend
the Sprint, who made a good impression on me and does not have
too many other opportunities to get his GPG key signed. To
attach to a conference is a very reasonable idea. An alternative
concept could be to meet at various observatories and occupy
their meeting rooms. Or do both.

Cheers,

Steffen






-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/trinity-5607d361-24fd-461d-926d-5979f796a59c-1389865643839@3capp-gmx-bs11

Aw: Re: Request for Ideas - Astronomy working group

[Steffen Möller]

Hello,

  at first thanks for all your great work on astronomy packages.
  
  On Thu, Jan 09, 2014 at 10:41:42PM +0100, Ole Streicher wrote:
  Dear all (astrophysicists, amateurs, scientists, other),
 
  there are now quite some people around that are interested in using
  Debian for astronomy related tasks. It may be a good idea if we could
  somehow bring us together and see where we can coordinate our efforts.
  
  +1
 
 I would very much support the creation of an Astronomy working group,
 but I am not quite sure how we would actually use an Alioth project and
 mailing list, especially if the packaging remains under debian-science
 umbrella which seems the right thing to me.
 
 Well, perhaps we should just give it a try :-)

How about a Sprint in Potsdam?

Is there a way to team up with some scientific projects? Einstein@Home 
for instance is close to Debian, much around the globe, really.

There are the KDE people doing kstars. Maybe one get some folks from
the indi telescope control library? Some hardware people would be nice.
Anybody building telescopes, still?

Image stackers for videoastronomy?

Astronometry?

Can we tie up with itelescopes.net somehow?

IOTA?

We^H^HYou should investigate how much there is to share between all those
contributing to the community. Maybe it is not too much, still, it would
be a very social meeting and rewarding, I am sure. To define usable workflows
with Debian alone would be very helpful.

Please go for it all. I'll join you in a couple of decades when I have time
for star gazing  I know, Astronomers do not have time for that, either :o)

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/trinity-629cb4f1-5115-4660-bd53-38d8428de400-1389625160186@3capp-gmx-bs33

Aw: Xeon Phi

[Steffen Möller]

Hello,

 I was wondering if there is a motivation to package the driver  its 
 software suite for the Xeon Phi:

This would be nice, indeed. I am using the NVidia packages of Debian a lot
and like them. And the Phi is long on my wishlist.
 ...
 
 This represents more or less 1GB of source code, more than 200MB of
 rpms, which are often installed using alien (according to what I found
 on the web)
 
 I think it would be interesting to have this in Debian, I will build
 something that can be installed on debian (probably 7) but if other
 are interested, we could envisage to make the MPSS (Manycore Platform
 Software Stack) available offically for debian which would be a bit
 like the SPE of the playstation3/cell processor.

The mean thing about it: it means tons of work and I do not see that much
of it can be shared between us as a community. Is there a way to have
folks at Intel interested in Debian packaging?

What also came to mind was to have a Debian-run machine equipped with
a Phi that a packaging team could possibly share. This would then save
possibly save us from many redundant builds of that GB of source code 
you outlined above.

If we could do such a shared-machine [cloud-like] packaging for Phi, then
I would be curious if such a model would also be beneficial for other large
source trees like e.g. KDE or LibreOffice.

In a back-to-the-roots-mode

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/trinity-8d5fa4a0-0392-4eee-9230-8cfd051e0a14-1386579053251@3capp-gmx-bs17

Aw: Re: DebConf 13: Call for Papers

[Steffen Möller]

  ¹ http://debconf13.debconf.org/

 Has somebody volunteered to organize a science track yet?  In general, I
 would volunteer if nobody else steps up, but I am not sure it makes
 sense as the deadline for abstract submission is nearby and I don't know
 if we have any science related submissions yet.

Please go for it.

I volunteer to craft abstracts on AutoDock, BOINC, and sadly my effort to 
bringt the two together is continuously delayednext year.

Best,

Steffen


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/trinity-63cb55bf-fb4a-4fd1-be98-5b59f1e2233a-1370004272850@3capp-gmx-bs51

Re: Kudos to High Energy Physics packagers (Re: r3479 - /projects/science/trunk/debian-science/tasks/highenergy-physics)

[Steffen Möller]

Hello,

On 07/13/2012 06:48 PM, Lifeng Sun wrote:

 Unfortunately, Herwig++ is also missed and failed to enter Wheezy,
 although I filed RFS more than one month ago.

Args. I presume the answer to Herwig and to all those tools seeing
new important versions will be backports.debian.org.

We have not addressed b.d.o much over the past releases, but with
more and more packages in our distribution there are  more
and more package that just do not fit into the Debian release schedule.
The official answer to that is backports and I see its importance
to increase also for us.

My personal answer, but that is not for everyone, has been for a
while to run servers with testing, not with stable, and this works
amazingly well. Updates are tested on my laptop first, but that's about it.

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5003c911.8090...@gmx.de

Re: Debian at ESRF

[Steffen Möller]

On 04/18/2012 10:14 PM, Andreas Tille wrote:
 On Wed, Apr 18, 2012 at 09:39:30AM +0200, Sylvestre Ledru wrote:
 Following Yaroslav's message, I would like to advertize the migration
 of the European Synchrotoron (http://www.esrf.eu) at Grenoble to
 Debian6; succeeding to RedHat4 and Centos5. For the moment, the
 migration is ongoing: only the computer controlling the particle
 accelerator, a few data analysis servers and part of the computing
 cluster has been migrated but most of the computing infrastructure
 will migrate this year.
 Bravo!
 Bravissimo!
praise / Beyond that Debian employment thingy, what is more to stress
is the circle with the community. You administrative and scientific
Debian full-timers can fall back to the Debian infrastructure for
package management, inter-institutional communication/collaboration ...
and extend that for your own benefit.

What I have not seen discussed much, yet, is the cross-architectural
benefit for monitoring of scientific (or any) processes. You easily get
whatever you need for some interactive low-bandwith communication on
your ARM-run mobile.

 ESRF aims at organizing a workshop around debian, introducing the new
 operating system for the scientists and explain to IT staff how to
 distribute and backport software. We would like to invite some
 representatives of Debian-science to join this workshop. For the moment,
 neither the date neither the program is fixed. We should have some
 budget for travel reimbursement.
 Depending on the date, I would interested to come!
 I presume the way you are doing it is the only way that I presume the way you 
 are doing it is the only way that 
 Same for me.
Here, too. The Debian Med sprints are less sprints of Debian-insiders
than mini-conferences/workshops of Science-insiders with some affinity
to us or already contributing. We asked delegates from various upstream
groups, and colleagues from Ubuntu / Bio-Linux to come and learn / think
about how to contribute. And they came on their own expense.
 I'd volunteer to give talk (did so in the past several
 times, last slides are here[1]) or a Debian packaging introduction
 workshop - whatever you are interested in.  May be we could widen the
 MoM[2] effort also to Debian Science.
Yes, this is a good idea. A perpetual season of code across all
disciplines of science.

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8fc52b.1070...@gmx.de

Re: ROOT 5.32/00 for Debian Squeeze

[Steffen Möller]

On 01/10/2012 03:06 AM, Sylvestre Ledru wrote:
 Hello Ricardo,


 Le mercredi 04 janvier 2012 à 09:20 -0800, Ricardo Yanez a écrit :
 Hi everyone,

 I have created a repository with the latest ROOT pro version (5.32.00)
 for Squeeze (i386, powerpc64 upcoming). The packages are built by me by
 applying various patches to the ROOT distributed Debian build scripts.

 I have made this effort due to an increase demand by me and students to
 be able to have the latest ROOT on our computers.

 I do really hope and prefer ROOT could find its way back to Debian.
 Until that glorious day, I will strive keep a stable repository with
 whatever version of ROOT happens to be in production mode at the time of
 the next Debian freeze.
 Is it a sponsoring request for an upload of ROOT in Debian ?

 If yes, could you commit it into the Debian Science repository ?
http://lcg-heppkg.web.cern.ch/lcg-heppkg/debian/ Thanks Sylvestre
There have been quite a few efforts to package/upload/maintain ROOT.

The last was by Yngve in the context of
http://wiki.debian.org/DebianScience/Geant4 from what I understood.
Everyone is too busy with too many things, though.

Best,

Steffen




-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0c48c3.4060...@gmx.de

Re: ROOT 5.32/00 for Debian Squeeze

[Steffen Möller]

On 01/10/2012 05:44 PM, Ricardo Yanez wrote:
 Hello Ricardo,


 Le mercredi 04 janvier 2012 à 09:20 -0800, Ricardo Yanez a écrit :
 Hi everyone,

 I have created a repository with the latest ROOT pro version (5.32.00)
 for Squeeze (i386, powerpc64 upcoming). The packages are built by me
 by
 applying various patches to the ROOT distributed Debian build scripts.

 I have made this effort due to an increase demand by me and students
 to
 be able to have the latest ROOT on our computers.

 I do really hope and prefer ROOT could find its way back to Debian.
 Until that glorious day, I will strive keep a stable repository with
 whatever version of ROOT happens to be in production mode at the time
 of
 the next Debian freeze.
 Is it a sponsoring request for an upload of ROOT in Debian ?
 No, I cannot commit the time to be an active maintainer. At most I could
 commit to maintain a version for Debian stable.
This would go to backports.debian.org, but for that it would need to
unstable/testing first.
Cheers,
Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0c6e27.4030...@gmx.de

Re: Proposal: Debian Science mailing lists

[Steffen Möller]

On 06/22/2011 02:36 PM, Brett Viren wrote:
 Andreas Tille andr...@an3as.eu writes:
 While I *personally* do not have a problem with the current situation I
 agree with Sylvestre that currently debian-science@l.d.o is not kind of
 missing link between developers and users.  Because I think we should
 establish such a place and this list seems to be a good candidate it
 might be reasonable to move pure packaging related questions to the
 Alioth list.

 However, I do not see a practical way to force this policy on list members.
 So writing it explicitely down in the Debian Science policy document and
 kindly directing people to the other list might be a good idea but there
 is no way to forbid packaging questions here.
 Hopefully not muddying the waters, but a new debian-science-users list
 could be created and debian-science left for package concerns (or
 package/user overlap?).  The new list would have the advantage of being
 explicitly user-centric in name.  It would also be a fresh place to
 intice back any users that may have left this list due to the increased
 focus on packaging.

 The downsides are having yet-another-list, and that purely user-oriented
 folks that are still here would need to move.
I very much feel with Andreas and Bret. If the list is just a mere subset
of what we see today, then we don't need it. But, from what I udnerstad,
the list is about the very contrary. So, I suggest that if the list is
going to
be created then to go a step further and call the new list plainly
science,
not debian-science-user.

The professional side of mine does not care much about such Debian
lists. When Debian is useful, then it will just be mentioned no matter
by whom the list may be run.  Where I see the list to have the potential
for some invaluable tremendous use is in communication of whatever
scientific aspect in a hackish proof at home kind of spirit. So, we'd
not only bring the software scientists run to every hobbyist, but also
spread some sparkling glimpse on how to use it.

Just to see how it goes - go with it.

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e01e757.3070...@gmx.de

Re: Scientific software packaging

[Steffen Möller]

Hello,

On 05/23/2011 01:30 PM, Yngve Inntjore Levinsen wrote:
 On Monday 23 May 2011 12.29.15 Gürkan Sengün wrote:
 That sounds fantastic, do you already have ready packages that I could test?
 You can test the ROOT packages which we distribute from CERN (unofficially) 
 here:

 http://cern.ch/lcg-heppkg/debian/

 I assume Lifeng have used similar packaging scripts (and his efforts to get 
 them into proper Debian channels are highly appreciated!).
I just read through those pages. You mention source and binary packages,
packaging for sid,
explained backports, reprepro, reads all very nice.

Have you considered sharing your 'debian' folders with the Debian science
repository? There is no need to upload all the program code. And you do not
even need to have anything ready to be uploaded. This way you would share
you insights on how to compile on the various platforms through sharing the
build instructions. This should also allow to work with Lifeng together
on those
packages and everyone would feel exceptionally well about those, even
though your support would remain not to be official. You can e.g. use
README.Debian for a disclaimer.

Best regards,

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dda50e0.9010...@gmx.de

Re: Scientific software packaging

[Steffen Möller]

Hello Yngve,

On 05/23/2011 04:42 PM, Yngve Inntjore Levinsen wrote:
 On Monday 23 May 2011 14.19.44 Steffen Möller wrote:
 Hello,

 On 05/23/2011 01:30 PM, Yngve Inntjore Levinsen wrote:
 On Monday 23 May 2011 12.29.15 Gürkan Sengün wrote:
 That sounds fantastic, do you already have ready packages that I could 
 test?
 You can test the ROOT packages which we distribute from CERN (unofficially) 
 here:

 http://cern.ch/lcg-heppkg/debian/

 I assume Lifeng have used similar packaging scripts (and his efforts to get 
 them into proper Debian channels are highly appreciated!).
 I just read through those pages. You mention source and binary packages,
 packaging for sid,
 explained backports, reprepro, reads all very nice.

 Have you considered sharing your 'debian' folders with the Debian science
 repository? There is no need to upload all the program code. And you do not
 even need to have anything ready to be uploaded. This way you would share
 you insights on how to compile on the various platforms through sharing the
 build instructions. This should also allow to work with Lifeng together
 on those
 packages and everyone would feel exceptionally well about those, even
 though your support would remain not to be official. You can e.g. use
 README.Debian for a disclaimer.

 Best regards,

 Steffen
 Hi Steffen,

 I did not start this project, Axel Naumann and Kevin B. McCarty did. Since 
 Kevin left the game I took over the Geant4 packaging (according to best 
 efforts of course, I cannot give guarantees on the quality of my packaging 
 from my level of expertise). People are more than welcome to download 
 packaging scripts and suggest improvements/report bugs of course. The reason 
 we keep it internally at CERN is, as explained, because of licensing problems 
 and similar.

 I have not considered sharing the debian folders with Debian Science. I 
 currently do not have much time on my hand to work on this, and I would 
 expect that some quality control would have to be done etc (actually the 
 latest Geant4 patch does not compile at the moment and I did not have time to 
 fix). You are all free to download the sources using apt-get source of 
 course, and I will be happy to try to explain what I have done. I am unsure 
 if I understand your question though, you mean to give you the link of the 
 folders from the server, or is there some formal way to publish the 
 packaging scripts without the source code? I have no objection to 
 distributing the packaging scripts (the respective authors would have to 
 agree first), but the sources like CLHEP and Geant4 have difficult licensing 
 so from what I understand we cannot distribute the sources outside CERN. 

 Cheers,
 Yngve

my field is computational biology but once helped to get Christian's
ROOT packages into the distribution when I was visiting Copenhagen more
frequently. In the subversion repositories it is considered good style
to only publish the debian folder, no source code. That should be
retrieved via the instructions in the debian/watch file or the
get-orig-source target in debian/rules or from the information in the
debian/copyright file. That debian folder is commonly GPLed and easily
comaintained, though this may differ if CERN has some policy I am not
aware of when you started it.  With git, there is no technical
requirement but there it is common practice to indeed upload the source
code in a separate branch. I dislike that immensely, but nobody seems to
care about my aversion, so there are just a limited number of packages
that I co-maintain with git.

I would not mind apt-get sourcing and uploading the debian folders from
there. But this would make sense only when you also use them. The
quality does not matter for a start. Just say that it does not
build/run. If the community cares then it will be fixed with or for you.
If not, then not. I could talk you through the process of manually
building with the debian folder in subversion and/or on how to use
svn-buildpackage for some package that you feel more comfortable with. 
The redistribution of the binaries is a very different issue from the
sharing of packaging/build instructions. And to have only the latter for
some packages will still be helpful as an open invite to the community
to contribute. I blogged about this at
http://debianmed.blogspot.com/2011/04/debian-med-individuals-expertize-and.html

Many greetings

Steffen






-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dda8680.7050...@gmx.de

Re: Removal requests submitted for CERNLIB packages

[Steffen Möller]

On 03/05/2011 02:57 AM, Lifeng Sun wrote:
 Hi Kevin,
 
 The FTBFS bug of CERNLIB is actually an issue of diffutils, when I
 built it after squeeze released last month, the bug disappeared, so I
 think this bug could be closed now.
 
 I would like to adopt the CERNLIB-related packages if allowed.
 
 
 BTW: I am preparing to package ROOT.
You are aware of http://wiki.debian.org/DebianScience/ROOT, I suppose.

Kevin, Christian et al have all long proven that the CERNLIB and friends
do work with Debian. The question is if we find a sufficiently high number
of users also at work. A few days ago came Scientific Linux 6.0 [1], which
means: not too soon, probably.

It would certainly help Debian and Ubuntu with it if that Scientific Linux
was based on either of the two distros since that distro would come with
quite some extra of brains and eyeballs for us. And if I am allowed to
dream about a contribution of more and more of CERN's and Fermilab's
Free software to Debian, i.e. having some their sysadmins and scientists
as members of our Debian Society, this would be of enormous value to
the IT landscape because of all the education and routine that is
spread with it. Just feel reminded what alone Yahoo's MapReduce did to
(many of) us.

We may rest assured that the folks at CERN and Fermilab do know about
Debian and the advantages that a community-run distribution brings for
them. At least on some lower levels. And also some higher ups I know to
have observed that Debian was the first distro (mostly thanks to the
NorduGrid folks in Uppsala around DM Mattias) that brought grid computing
(a core infrastructure for those international groups gathering at CERN
and Fermilab) into a regular Linux distribution with its Globus (used by
about every grid middleware) and ARC packages (used by the NorduGrid).

My hunch is that eventually we will see the efforts behind Scientific
Linux merge with some major Linux distribution. And the reason most likely
will be to prove to their funding parties of their impetus to give back to the
world as much they can - independent from their hunt after some quark.
This may be Fedora or Debian, but they will come, I am sure. That they
have Scientific Linux and are Open Source already is per se already quite
remarkable.

What may be helping to speed up that process could be
 * identify a series of industries that should have some interest in the
   technologies maintained through CERN (car industry for crash tests
   maybe?, geologists?, astronomers? ..) and a blog about it
 * more personal contacts between our distro and CERN-affiliated scientists
   via conferences maybe?
 * some larger research group that decides to use Debian rather than
   scientific linux
 * maybe that group could also get some industry/research money to
   describe the CERNLIB and friends for regular industries
 * ...?

Many greetings

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d721f15.3080...@gmx.de

Re: Debian and Scientific Linux

[Steffen Möller]

On 03/05/2011 05:34 PM, Juergen Salk wrote:
 * Juergen Salk juergen.s...@gmx.de [110305 15:46]:
 
 That they have Scientific Linux and are Open Source already
 is per se already quite remarkable.
 
 [...] The main goal of Scientific Linux is *not* to be as
 scientific as possible, e.g. in terms of the number of
 scientific software packages included in the distribution. (As
 a matter of fact, Debian comes with much, much more scientific
 software packages than SL does).  
 
 Just as an addendum in case someone is interested. This is a complete (!) 
 list of scientific packages that come with Scientific Linux 6:
 
 jsalk@wattwurm:~ cat /etc/redhat-release
 Scientific Linux release 6.0 (Carbon)
 jsalk@wattwurm:~ yum groupinfo 'Scientific support'
 Loaded plugins: refresh-packagekit
 Setting up Group Process
 
 Group: Scientific support
  Description: Tools for mathematical and scientific computations, and 
 parallel computing.
  Default Packages:
gnuplot
units
  Optional Packages:
atlas
lapack
mpich2
mpitests-mvapich
mpitests-mvapich2
mpitests-openmpi
mvapich
mvapich2
numpy
openmpi
 jsalk@wattwurm:~ 
 
 That's it. It's simply what comes with RHEL6 anyway. They don't even
 have R in SL6 any more. So it is really a myth that Scientific Linux
 provides much extras for scientists. It's simply not their goal. It's
 all about compatibility with RHEL which makes SL so attractive as a
 common platform for huge computing environments. 

Right. Little is added:

https://www.scientificlinux.org/distributions/6x/features/added
https://www.scientificlinux.org/distributions/6x/features/differences

And all the CERN physics environments are indeed not a part of it as
it seems. And there is yet no ROOT or CERNLIB binary package for it
but only for older versions :)

http://root.cern.ch/drupal/content/production-version-528
http://cernlib.web.cern.ch/cernlib/version.html

Thank you for pointing this out!

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d7289b6.9030...@gmx.de

Re: Qt3 removal rational

[Steffen Möller]

On 02/10/2011 09:10 PM, Michael Banck wrote:
  If qt3 is really popular with scientific apps, which presumably are slow 
  moving targets which are not esaily /quickly ported to qt4, it should be 
  enough motivation for the people who need qt3 to take on the maintenance, 
  so 
  no need to burden the QA team. You need a piece of software, you do the 
  necessary packaging work - it's that simple, at least in theory.
 Reposting on -science as maybe somebody hadn't seen it.
 
 Anybody still maintaining Qt3 apps? 

QtDMM and it will die with the Qt4-only transition.
There is QtDMM2 using Qt4, which I yet did not have
a closer look at.

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d569acd.3040...@gmx.de

backports

[Steffen Möller]

Hello,

how do you feel towards the idea that with the advent of backports as an 
official service of the distribution, we should use that
in routine for the more frequently updated tools? In science, there is rarely 
(i.e. except for comparisons or for continuity) the
need to use an older version, and then snapshot.debian.org comes to a rescue. 
And then there are these annoying cases when a new
upstream release just fails to miss the freeze.

Prime candidates IMHO are the autodocktools, gromacs, ... well ... almost 
anything in debian-science and debian-med, really. I
would then even opt to take the autodocktools out of the main distribution 
towards an appearance in backports and testing only.

Comments welcome.

Best,

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8d2548.2080...@gmx.de

while sponsoring, patch against qcad - don't have permissions

[Steffen Möller]

Hello,

I thought I could commit everywhere as a DD, but apparently not.
Someone please fix this for me.

Howard, the upload is coming

Steffen


$ cat 0001-typo.patch
From 8b9b6acc2d0eb05542c3d91a88bc4c018e770d14 Mon Sep 17 00:00:00 2001
From: Steffen Moeller moel...@debian.org
Date: Sun, 18 Jul 2010 17:05:07 +0200
Subject: [PATCH] typo

---
 debian/changelog |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 781fa38..d93eace 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,6 @@
 qcad (2.0.5.0-1+090318-4) unstable; urgency=low

-  * Adopted by deian-science (Closes: #588854)
+  * Adopted by debian-science (Closes: #588854)
 - Scott Howard added to uploaders
   * DM-Upload-Allowed per debian-science policy
   * Typos in previous changelog (Closes: #564275, Closes: #572984)
-- 
1.7.1

de


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c431940.7020...@gmx.de

Re: packaging jmol, was Re: I want to contribute

[Steffen Möller]

On 07/16/2010 11:31 AM, Michael Banck wrote:
 Hi,

 On Wed, Jul 14, 2010 at 10:14:05PM +0200, Andreas Tille wrote:
   
 On Wed, Jul 14, 2010 at 11:04:15PM +0800, Alex John wrote:
 
 I'm Alex and I'd like to help package jmol if anyone is willing to 
 introduce me to the procedure (first time with packaging). 
   
 In case you want to contribute you should probably create an account on
 alioth.debian.org and apply for becoming a member of Debian Science
 project to be able to commit to the SVN.

 Feel free to ask further questions in case something remains unclear
 
 We wouldn't mind having it in the debichem repository, either.  I'd be
 willing to co-maintain it.
   
This sounds all ultimately lovely. Please check out if a checkout of my
previous attempt in the pkg-escience repository is helpful - I have no
recollection about that effort, but at least as a start for Alex is
should be somewhat interesting to look at.

I once gave it status yellow which is a rather good sign, the comment
I left for a missing of a compatibility check with the free Java
compilers and machine are now mute.
http://svn.debian.org/wsvn/pkg-escience/jmol/trunk/

Good luck!

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c40478a.7040...@gmx.de

packaging jmol, was Re: I want to contribute

[Steffen Möller]

Hello,

On 07/14/2010 02:44 PM, Andreas Tille wrote:
 On Wed, Jul 14, 2010 at 11:53:10AM +0200, Egon Willighagen wrote:
   
 I am
 sure you would make many Debian users happy if you would package Jmol
 (http://jmol.org/) for Debian. (I am/was lead developer for both, and
 reside in Uppsala).
 
 I can confirm that Jmol would be quite interesting.  Here is some information
 about the packaging status of Jmol:
   
yes, jmol is indeed overdue. As it happens I know that Eric from the CC
line is also interested in packaging jmol. Eric, how far have you got?
The vicinity of upstream-Egon to sph k2 who drafted the original
request, would somehow suggests to spare you the effort, Eric, and
rather proceed directly to Jalview.
http://debian-med.alioth.debian.org/tasks/bio#jmol

 However, I would strongly recommend contacting the issuer of the ITP
 and suggest moving SVN from pkg-escience to debian-science SVN.
   
:) any move is fine with me. This 2006 effort of mine at
http://svn.debian.org/wsvn/pkg-escience/jmol/trunk/debian/?rev=0sc=0
was sufficiently frustrating.


Many greetings

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c3dc725.3000...@gmx.de

Re: Big problems with scientifc use of amd64

[Steffen Möller]

On 06/17/2010 06:00 PM, Yaroslav Halchenko wrote:
 just as a sidenote I would like to echo Gudjon's reply: we use lenny on our
 little cluster, with backports (backports.org and neuro.debian.net) whenever
 feasable. 

And in addition to all that has been said I wish to mention that backports.org
is open for contributions. Once can have packages of one's own need added to it.
And there is also the possibility to have a repository of one's own.

And finally, we should really think about calling our testing stable now :)

Steffen


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c1a6ded.90...@gmx.de

Re: NARVAL ENX : two potential new packages

[Steffen Möller]

Hi Andreas,

Andreas Tille wrote:
 On Mon, Mar 22, 2010 at 01:28:30PM +0100, Xavier Grave wrote:
 My idea to have NARVAL related to debian-science was to ease promote Debian
 in science area where for the moment we have Scientific Linux.

SL has the backing of some large (!) and prominent (!) research
institutions worldwide. One cannot exclude the possibility for them to
move from Fedora towards Debian, but one should not expect that in any
way. And it is IMHO not the right motivation to work on Debian packages
in the first place.

I very much encourage NARVAL and ENX for Debian because of the knowledge
transfer that is intrinsic to it. Many smaller groups, say in molecular
biology labs, will have similar problems, if on a smaller scale, and to
then have a more hardware oriented stack available is helpful. So,
please grant Frederic-Emmanuel the commit rights to the
repository and then let's find a sponsor/mentor for his work.

 Quoting their homepage[1]: 
 
   SL is a Linux release put together by Fermilab, CERN, and various
   other labs and universities around the world. Its primary purpose is to
   reduce duplicated effort of the labs, and to have a common install base
   for the various experimenters.
 
   The base SL distribution is basically Enterprise Linux, recompiled
   from source.
 
 If it is about reducing duplicated effort on the labs I'd consider a
 Debian Science Blend (perhaps with some preconfiguration sugar as Debian
 Edu is doing) a very reasonable way to go.  At least exacly this is
 the intention of Debian Science.

Well, yes, this is something that the nuclear physicists behind SL might
well think about. For us, the aim should less be to substitute their
current effort but to have some partial compatibility with them so
researchers can more easily test things at home or for
less-production-oriented/more-experimental institute desktops and
consequently profit more from the knowledge transfer.

We have a few SL users as Debian-Maintainers and as applicants, hoping
to soon count Frédéric-Emmanuel to it. Many SL users like and use
Debian. So, we don't need too much of promotional activity, really,
except for our openness and curiosity, possibly, and that is indeed
something that blends help with. But with large international
collaborations you just need to agree on something - and that is SL for
... the last decade?  I personally don't mind to see an improved
compatibility between Debian and SL as a service to the scientific aims
that SL supports. Conversely we profit from nice new packages like
NARVAL and ENX.

Enjoying the science

Steffen

 
 [1] http://www.scientificlinux.org/ 
 


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bab39c5.4010...@gmx.de

Re: Torque in Debian?

[Steffen Möller]

Hi Jordi,

Jordi Mallach wrote:
 On Sat, Dec 19, 2009 at 07:58:29PM +0100, Steffen Moeller wrote:
 Now 2.4 is out and there should only be a single 2.4 branch left.
 
 I understand 2.4 is now stable and the packaging is what can be found
 in trunk. However, I don't see any recent changes to trunk, and the
 changelog is prepared for 2.4.0b1, last modified in December 2008.
 Is this correct, or is there another place where we I should look for a
 newer tree?

Hm. I did something for 2.3.7 which you may want to compare against the
trunk.

 On another topic, some people asked why not move this package to the
 debian-science repo. I tend to agree with them, and it would be fairly
 trivial to do.

given the silence that Morten and I produce, I can only follow you in
your suggestion. I cannot tell if I have commit rights for
debian-science. If you continue caring for torque on Debian, then I
presume to speak for Morten when I now suggest to please adopt the
package and you are free to move it to whereever you want.

The major challenge from my perspective is to remain compatible with the
users of torque under Ubuntu, i.e. the package Morten is maintaining for
years. Sombody may cry foul here, but I am deeply convinced that the
stream of packages from Debian to Ubuntu is something extremely valuable
and we should care about it.

What Daniel once nicely seeded was the separation of the builds for the
command line binaries vs the ones with X GUI. I am uncertain for the
moment if this is in the trunk. If not then please merge it from the
debian branch.

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: Debian for Systems Biology

[Steffen Möller]

Ciao Luca,

 Is there anybody interested to packaging software for systems biology?
you mean in already packaged software :-)

 I'm a bioinformatics student, and I noticed nobody within Debian is
 packaging systems biology-related tools (there is only an old ITP for
 libsbml).
It is mine. I have a quite ok package for a while but have never addressed
the soname issue. If you are actively using SBML then please take over.

 Wouldn't be useful to create a webpage like those
 at http://www.debian.org/devel/debian-med/?
 
 Of course, actually systems biology inherit science more than medicine.
 debian-science should have its own webpage, shouldn't it?
Andreas Tille does a very good and reliable job that takes more time than
you might anticipate. In short, No!.

 A chaotic list with a few interesting tools for the main Debian
 distribution with their licenses follows. Anyone could surely look
 better.
I experienced the Java bits as tricky. Please go for the packaging of any of
these tools that you actively use yourself. 

Many saluti

Steffen

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]