Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #8490 > unrolled thread

does Debian help detect gravitational waves?

Back to article view | Back to linux.debian.project

Contents

  does Debian help detect gravitational waves? Daniel Pocock <daniel@pocock.pro> - 2016-02-12 09:30 +0100
    Re: does Debian help detect gravitational waves? Yves-Alexis Perez <corsac@debian.org> - 2016-02-12 10:30 +0100
    Re: does Debian help detect gravitational waves? Paul Wise <pabs@debian.org> - 2016-02-13 22:30 +0100
    Re: does Debian help detect gravitational waves? Michael Hanke <michael.hanke@gmail.com> - 2016-02-13 22:30 +0100
    Re: does Debian help detect gravitational waves? Aurelien Jarno <aurelien@aurel32.net> - 2016-02-14 01:30 +0100
      Re: does Debian help detect gravitational waves? Yaroslav Halchenko <debian@onerussian.com> - 2016-02-14 02:00 +0100
        Re: does Debian help detect gravitational waves? Daniel Pocock <daniel@pocock.pro> - 2016-02-14 12:10 +0100
        Re: does Debian help detect gravitational waves? Aurelien Jarno <aurelien@aurel32.net> - 2016-02-14 13:50 +0100
        Re: does Debian help detect gravitational waves? Ole Streicher <olebole@debian.org> - 2016-02-14 14:50 +0100
          Re: does Debian help detect gravitational waves? Adam Borowski <kilobyte@angband.pl> - 2016-02-14 15:40 +0100
            Re: does Debian help detect gravitational waves? Ole Streicher <olebole@debian.org> - 2016-02-14 16:20 +0100
              Re: does Debian help detect gravitational waves? Yaroslav Halchenko <debian@onerussian.com> - 2016-02-14 16:30 +0100
                Re: does Debian help detect gravitational waves? Michael Hanke <michael.hanke@gmail.com> - 2016-02-16 09:30 +0100
                Re: does Debian help detect gravitational waves? Ole Streicher <olebole@debian.org> - 2016-02-16 09:30 +0100
                  Re: does Debian help detect gravitational waves? Yaroslav Halchenko <debian@onerussian.com> - 2016-02-16 14:50 +0100
                    Re: does Debian help detect gravitational waves? Andreas Tille <andreas@an3as.eu> - 2016-02-16 19:50 +0100
                      Re: does Debian help detect gravitational waves? Yaroslav Halchenko <debian@onerussian.com> - 2016-02-16 20:10 +0100
                        Re: does Debian help detect gravitational waves? Ole Streicher <olebole@debian.org> - 2016-02-16 22:10 +0100
                          Re: does Debian help detect gravitational waves? Andreas Tille <andreas@an3as.eu> - 2016-02-17 12:00 +0100
                            Re: does Debian help detect gravitational waves? Yaroslav Halchenko <debian@onerussian.com> - 2016-02-22 01:00 +0100
                              Re: does Debian help detect gravitational waves? Paul Wise <pabs@debian.org> - 2016-02-22 08:30 +0100
                                Re: does Debian help detect gravitational waves? Andreas Tille <andreas@an3as.eu> - 2016-02-23 15:00 +0100
                              Re: does Debian help detect gravitational waves? Ole Streicher <olebole@debian.org> - 2016-02-22 09:10 +0100
                                Re: does Debian help detect gravitational waves? Andreas Tille <andreas@an3as.eu> - 2016-02-23 15:00 +0100
                                  Re: does Debian help detect gravitational waves? Yaroslav Halchenko <debian@onerussian.com> - 2016-02-23 15:50 +0100
                                    Re: does Debian help detect gravitational waves? Paul Wise <pabs@debian.org> - 2016-02-24 05:50 +0100
                              Re: does Debian help detect gravitational waves? Andreas Tille <andreas@an3as.eu> - 2016-02-23 15:10 +0100
                          Re: does Debian help detect gravitational waves? Yaroslav Halchenko <debian@onerussian.com> - 2016-02-20 22:30 +0100
            Re: does Debian help detect gravitational waves? Andreas Tille <andreas@an3as.eu> - 2016-02-15 09:50 +0100
    Re: does Debian help detect gravitational waves? Ana Guerrero Lopez <ana@debian.org> - 2016-03-05 01:00 +0100

Page 1 of 2  [1] 2  Next page →

#8490 — does Debian help detect gravitational waves?

https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html

The Ganglia graph (top right corner of the page) appears to be generated
on a Debian host using the official packages (it has ganglia-webfrontend
in the URL)

Drill down into the Ganglia reports and we can even see things like
kernel package version

http://silkspectre.cgca.uwm.edu/ganglia/?r=hour&cs=&ce=&m=os_release&s=by+name&c=NEMO&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4

os_release: 3.16.0-0.bpo.4-amd64

[toc] | [next] | [standalone]

#8491

[Multipart message — attachments visible in raw view] — view raw

On ven., 2016-02-12 at 09:21 +0100, Daniel Pocock wrote:
> https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
> 
> The Ganglia graph (top right corner of the page) appears to be generated
> on a Debian host using the official packages (it has ganglia-webfrontend
> in the URL)

On that page:

Reference Operating Systems
Scientific Linux 6.1
Debian 6.0 Squeeze
CentOS 5.3 (to be deprecated)
Debian 5.0, Lenny (to be deprecated)
-- 
Yves-Alexis

[toc] | [prev] | [next] | [standalone]

#8492

On Fri, Feb 12, 2016 at 7:21 PM, Daniel Pocock wrote:

> https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
>
> The Ganglia graph (top right corner of the page) appears to be generated
> on a Debian host using the official packages (it has ganglia-webfrontend
> in the URL)

In case you are able to contact them, please ask if they would like to
be listed as Debian users.

https://www.debian.org/users/

A guest post on the Debian blog (bits.d.o) about this might also be interesting.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#8493

[Multipart message — attachments visible in raw view] — view raw

Hi,

few years back when packaging htcondor I was in touch with the people
running the IT of the German observatory. Their Condor pool ran on Debian.
As far as I know it still does.

Michael


On Feb 12, 2016 09:21, "Daniel Pocock" <daniel@pocock.pro> wrote:
>
>
>
> https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
>
> The Ganglia graph (top right corner of the page) appears to be generated
> on a Debian host using the official packages (it has ganglia-webfrontend
> in the URL)
>
> Drill down into the Ganglia reports and we can even see things like
> kernel package version
>
>
http://silkspectre.cgca.uwm.edu/ganglia/?r=hour&cs=&ce=&m=os_release&s=by+name&c=NEMO&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4
>
> os_release: 3.16.0-0.bpo.4-amd64
>
>

[toc] | [prev] | [next] | [standalone]

#8494

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 2016-02-12 09:21, Daniel Pocock wrote:
> 
> 
> https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
> 
> The Ganglia graph (top right corner of the page) appears to be generated
> on a Debian host using the official packages (it has ganglia-webfrontend
> in the URL)
> 
> Drill down into the Ganglia reports and we can even see things like
> kernel package version
> 
> http://silkspectre.cgca.uwm.edu/ganglia/?r=hour&cs=&ce=&m=os_release&s=by+name&c=NEMO&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4
> 
> os_release: 3.16.0-0.bpo.4-amd64
> 

Please have a look at the article (BTW released under CC license):

  https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.116.061102

The article itself has one thousand of authors from 133 different
institutes member of the LIGO and VIRGO cooperation. It is a result of
a huge amount of work by thousands of persons in the last 15 years to
design, build, improve, operate the instrument, but also to work on the
theory or simulation.

For sure Debian has been used somewhere, just like Slackware, MS-DOS,
HP-UX or any other system have helped at some moment. Just looking at
one random website from one small subpart of the whole project to
conclude about the Debian implication in the whole project just doesn't
make sense. It is just like deducing that pelican helps the Debian
project because it is used on the Debian blog.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[toc] | [prev] | [next] | [standalone]

#8495

On Sun, 14 Feb 2016, Aurelien Jarno wrote:
> > https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html

> > The Ganglia graph (top right corner of the page) appears to be generated
> > on a Debian host using the official packages (it has ganglia-webfrontend
> > in the URL)

> > Drill down into the Ganglia reports and we can even see things like
> > kernel package version

> > http://silkspectre.cgca.uwm.edu/ganglia/?r=hour&cs=&ce=&m=os_release&s=by+name&c=NEMO&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4

> > os_release: 3.16.0-0.bpo.4-amd64


> Please have a look at the article (BTW released under CC license):

>   https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.116.061102

> The article itself has one thousand of authors from 133 different
> institutes member of the LIGO and VIRGO cooperation. It is a result of
> a huge amount of work by thousands of persons in the last 15 years to
> design, build, improve, operate the instrument, but also to work on the
> theory or simulation.

> For sure Debian has been used somewhere, just like Slackware, MS-DOS,
> HP-UX or any other system have helped at some moment. Just looking at
> one random website from one small subpart of the whole project to
> conclude about the Debian implication in the whole project just doesn't
> make sense. It is just like deducing that pelican helps the Debian
> project because it is used on the Debian blog.

FWIW that link
https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
at least now has already explicit listing

Reference Operating Systems

    Scientific Linux 6.1
    Debian 6.0 Squeeze
    CentOS 5.3 (to be deprecated)
    Debian 5.0, Lenny (to be deprecated)

So I guess Debian was of some notable help, and I am really glad that our work
at least tiny bit contributed to this event.  But that is it.  Somewhat
twisting while overall agreeing with the point of Aurelien's reply --
Debian was probably used somewhere along the way of any recent sizeable
research endeavor simply because it is used in so many scenarios and places.

Was Debian indispensable? probably not,  was it facilitating? hopefully yes.

If all pieces involved were to be attributed in some publication -- that would
have been cool, but now it would simply be not possible to do so adequately at
such a scale.  Shameless plug:  have a look at the http://duecredit.org/
which is intended to help in such endeavors at least for Python world atm.

Cheers
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[toc] | [prev] | [next] | [standalone]

#8496

On 14/02/16 01:56, Yaroslav Halchenko wrote:
> 
> On Sun, 14 Feb 2016, Aurelien Jarno wrote:
>>> https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
> 
>>> The Ganglia graph (top right corner of the page) appears to be generated
>>> on a Debian host using the official packages (it has ganglia-webfrontend
>>> in the URL)
> 
>>> Drill down into the Ganglia reports and we can even see things like
>>> kernel package version
> 
>>> http://silkspectre.cgca.uwm.edu/ganglia/?r=hour&cs=&ce=&m=os_release&s=by+name&c=NEMO&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4
> 
>>> os_release: 3.16.0-0.bpo.4-amd64
> 
> 
>> Please have a look at the article (BTW released under CC license):
> 
>>   https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.116.061102
> 
>> The article itself has one thousand of authors from 133 different
>> institutes member of the LIGO and VIRGO cooperation. It is a result of
>> a huge amount of work by thousands of persons in the last 15 years to
>> design, build, improve, operate the instrument, but also to work on the
>> theory or simulation.
> 
>> For sure Debian has been used somewhere, just like Slackware, MS-DOS,
>> HP-UX or any other system have helped at some moment. Just looking at
>> one random website from one small subpart of the whole project to
>> conclude about the Debian implication in the whole project just doesn't
>> make sense. It is just like deducing that pelican helps the Debian
>> project because it is used on the Debian blog.
> 
> FWIW that link
> https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
> at least now has already explicit listing
> 
> Reference Operating Systems
> 
>     Scientific Linux 6.1
>     Debian 6.0 Squeeze
>     CentOS 5.3 (to be deprecated)
>     Debian 5.0, Lenny (to be deprecated)
> 
> So I guess Debian was of some notable help, and I am really glad that our work
> at least tiny bit contributed to this event.  But that is it.  Somewhat
> twisting while overall agreeing with the point of Aurelien's reply --
> Debian was probably used somewhere along the way of any recent sizeable
> research endeavor simply because it is used in so many scenarios and places.
> 
> Was Debian indispensable? probably not,  was it facilitating? hopefully yes.
> 

I don't think anybody was suggesting it was indispensable.

Nonetheless, Debian appears to have been chosen over other alternatives
and mentioned in a few places

It would be interesting to ask the more general question if free
software is indispensable for such efforts though

[toc] | [prev] | [next] | [standalone]

#8497

[Multipart message — attachments visible in raw view] — view raw

On 2016-02-13 19:56, Yaroslav Halchenko wrote:
> 
> On Sun, 14 Feb 2016, Aurelien Jarno wrote:
> > > https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
> 
> > > The Ganglia graph (top right corner of the page) appears to be generated
> > > on a Debian host using the official packages (it has ganglia-webfrontend
> > > in the URL)
> 
> > > Drill down into the Ganglia reports and we can even see things like
> > > kernel package version
> 
> > > http://silkspectre.cgca.uwm.edu/ganglia/?r=hour&cs=&ce=&m=os_release&s=by+name&c=NEMO&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4
> 
> > > os_release: 3.16.0-0.bpo.4-amd64
> 
> 
> > Please have a look at the article (BTW released under CC license):
> 
> >   https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.116.061102
> 
> > The article itself has one thousand of authors from 133 different
> > institutes member of the LIGO and VIRGO cooperation. It is a result of
> > a huge amount of work by thousands of persons in the last 15 years to
> > design, build, improve, operate the instrument, but also to work on the
> > theory or simulation.
> 
> > For sure Debian has been used somewhere, just like Slackware, MS-DOS,
> > HP-UX or any other system have helped at some moment. Just looking at
> > one random website from one small subpart of the whole project to
> > conclude about the Debian implication in the whole project just doesn't
> > make sense. It is just like deducing that pelican helps the Debian
> > project because it is used on the Debian blog.
> 
> FWIW that link
> https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html
> at least now has already explicit listing
> 
> Reference Operating Systems
> 
>     Scientific Linux 6.1
>     Debian 6.0 Squeeze
>     CentOS 5.3 (to be deprecated)
>     Debian 5.0, Lenny (to be deprecated)
> 
> So I guess Debian was of some notable help, and I am really glad that our work
> at least tiny bit contributed to this event.  But that is it.  Somewhat
> twisting while overall agreeing with the point of Aurelien's reply --
> Debian was probably used somewhere along the way of any recent sizeable
> research endeavor simply because it is used in so many scenarios and places.

Look at the acknowledgment section, especially the computing resources
part:

| The authors gratefully acknowledge the support of the NSF, STFC, MPS,
| INFN, CNRS and the State of Niedersachsen, Germany, for provision of
| computational resources. 

Therefore one should look at much more than the above website to even
get an idea about the Debian place in this project.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[toc] | [prev] | [next] | [standalone]

#8498

Yaroslav Halchenko <debian@onerussian.com> writes:
> So I guess Debian was of some notable help, and I am really glad that our work
> at least tiny bit contributed to this event.  But that is it.  Somewhat
> twisting while overall agreeing with the point of Aurelien's reply --
> Debian was probably used somewhere along the way of any recent sizeable
> research endeavor simply because it is used in so many scenarios and places.

In the past I had a bit contact to LIGO people -- BTW, the healpy
package has a LIGO employee as uploader -- in order to convince them to
contribute to Debian Astro.

There are some problems why Debian is not soo widely used in the science
analysis (yet): One is that due to our long freeze many important
packages are already outdated when the stable release comes out. This
may be solved by backporting -- however I still never did that and I am
afraid that I will not have the time to do it on the long run. So, if
anyone wants to volunteer backporting some important astronomy (or
science) packages, go ahead. This will increase our impact in that area.

The other problems are not so simple to solve: licensing (not everything
is DFSG compatible), poor software quality, local patches to standard
packages.

However, if we could take the gravitational waves to boost our efforts
in science: that would be great!

Cheers

Ole

[toc] | [prev] | [next] | [standalone]

#8499

On Sun, Feb 14, 2016 at 02:31:34PM +0100, Ole Streicher wrote:
> There are some problems why Debian is not soo widely used in the science
> analysis (yet): One is that due to our long freeze many important
> packages are already outdated when the stable release comes out.

Well, they're using oldoldstable and old^3stable, so it doesn't appears as
if they rely on newest versions of packaged tools.

-- 
A tit a day keeps the vet away.

[toc] | [prev] | [next] | [standalone]

#8500

Adam Borowski <kilobyte@angband.pl> writes:
> On Sun, Feb 14, 2016 at 02:31:34PM +0100, Ole Streicher wrote:
>> There are some problems why Debian is not soo widely used in the science
>> analysis (yet): One is that due to our long freeze many important
>> packages are already outdated when the stable release comes out.
>
> Well, they're using oldoldstable and old^3stable, so it doesn't appears as
> if they rely on newest versions of packaged tools.

It probably varies with the group. I discussed about the inclusion of
the analysis suite, and there the argument was that it would be outdated
in stable already when it comes out.

Data analysis is here probably different from storage clusters or web
servers.

Best regards

Ole

[toc] | [prev] | [next] | [standalone]

#8501

On Sun, 14 Feb 2016, Ole Streicher wrote:
> >> There are some problems why Debian is not soo widely used in the science
> >> analysis (yet): One is that due to our long freeze many important
> >> packages are already outdated when the stable release comes out.

> > Well, they're using oldoldstable and old^3stable, so it doesn't appears as
> > if they rely on newest versions of packaged tools.

> It probably varies with the group. I discussed about the inclusion of
> the analysis suite, and there the argument was that it would be outdated
> in stable already when it comes out.


FWIW, as some might not know, in NeuroDebian project
(http://neuro.debian.net) we are consciously trying to package any of
software we maintain so backport builds can be done automagically
without major additional investment of time with a helper script, see
for that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660208 and
up-to-date version is always available from e.g.
http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/backport-dsc

This way we provide most recent releases of software we maintain at once
not only for Debian sid, but for all compatible older
Debian and Ubuntu releases, see e.g. for our own project:
http://neuro.debian.net/pkgs/python-mvpa2.html

I guess any other blend/team could adopt similar strategy.  And whenever
Debian "PPA" efforts comes out, it could/would be fully automated.

> Data analysis is here probably different from storage clusters or web
> servers.

;)  I would say that "it is easier", since usually those (analysis
suites) are leaf packages and thus there is fewer of dependents, so
providing a new backported version is of lower risk to brake anything.
What I would encourage though is to enable build-time unit-testing.  It
was of paramount importance/help to us at least, since then we
catch possible incompatibilities at build time and never ship a backport
which we know wouldn't work on older system.

</shameless-plug>
Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[toc] | [prev] | [next] | [standalone]

#8506

[Multipart message — attachments visible in raw view] — view raw

Hey,


On Tue, Feb 16, 2016 at 9:07 AM, Ole Streicher <olebole@debian.org> wrote:

> Yaroslav Halchenko <debian@onerussian.com> writes:
> > FWIW, as some might not know, in NeuroDebian project
> > (http://neuro.debian.net) we are consciously trying to package any of
> > software we maintain so backport builds can be done automagically
> > without major additional investment of time with a helper script, see
> > for that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660208 and
> > up-to-date version is always available from e.g.
> >
> http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/backport-dsc
>
> This looks like a useful tool! Wouldn't it make sense to put it into the
> devscripts package?


https://bugs.debian.org/660208

Cheers,

Michael


-- 
Michael Hanke
http://mih.voxindeserto.de

[toc] | [prev] | [next] | [standalone]

#8507

Hi Yaroslav,

thank you for your answer! I has many ideas how to improve things for
Debian-Astro. BTW, is there a reason why NeuroDebian is not a Debian
Pure Blend? Is it part of DebianMed?

Yaroslav Halchenko <debian@onerussian.com> writes:
> FWIW, as some might not know, in NeuroDebian project
> (http://neuro.debian.net) we are consciously trying to package any of
> software we maintain so backport builds can be done automagically
> without major additional investment of time with a helper script, see
> for that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660208 and
> up-to-date version is always available from e.g.
> http://anonscm.debian.org/cgit/pkg-exppsy/neurodebian.git/tree/tools/backport-dsc

This looks like a useful tool! Wouldn't it make sense to put it into the
devscripts package?

>> Data analysis is here probably different from storage clusters or web
>> servers.
>
> ;)  I would say that "it is easier", since usually those (analysis
> suites) are leaf packages and thus there is fewer of dependents, so
> providing a new backported version is of lower risk to brake anything.

Sure. Well, almost. We have some packages which are really basic for
others (cfitsio, wcslib, astropy), and some of them are in a rapid
development.

> What I would encourage though is to enable build-time unit-testing.  It
> was of paramount importance/help to us at least, since then we
> catch possible incompatibilities at build time and never ship a backport
> which we know wouldn't work on older system.

Right. I also find the CI tests important, and it would be great to
extend them to backports, experimental and such.

Best regards

Ole

[toc] | [prev] | [next] | [standalone]

#8509

On Tue, 16 Feb 2016, Ole Streicher wrote:

> thank you for your answer! I has many ideas how to improve things for
> Debian-Astro. BTW, is there a reason why NeuroDebian is not a Debian
> Pure Blend? Is it part of DebianMed?

Because we overlap with / part of / superset of both Med and Science, so
we are part of those blends.  We didn't feel like duplicating anything
from those two blends within yet another blend would be of any benefit
to anyone.  And then we provided on top of what blends do not
provide: repository with backports, VMs etc... may be at some
point things would converge somehow but not yet

> > What I would encourage though is to enable build-time unit-testing.  It
> > was of paramount importance/help to us at least, since then we
> > catch possible incompatibilities at build time and never ship a backport
> > which we know wouldn't work on older system.

> Right. I also find the CI tests important, and it would be great to
> extend them to backports, experimental and such.

yes -- autopkgtest CI is great but doesn't cut it for mass backporting
since we don't even want to upload any package backport to distro X if
we know that it is going to fail there.  Thus package build time
testing is necessary.  and then it would indeed be great to setup a CI
using autopkgtest for all the backports to guarantee that they continue
working as additional backports enter the stage.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[toc] | [prev] | [next] | [standalone]

#8511

Hi,

On Tue, Feb 16, 2016 at 08:47:37AM -0500, Yaroslav Halchenko wrote:
> 
> Because we overlap with / part of / superset of both Med and Science, so
> we are part of those blends.  We didn't feel like duplicating anything
> from those two blends within yet another blend would be of any benefit
> to anyone.

Just for the record: I disagree with this statement. :-)

It would be not duplicated work to arrange sensible tasks for your
workfield.  I'm not sure what other duplication you might have in mind.

I'd really welcome if you would integrate some of your tools into the
general Blends framework (but I we talked about this before).

> And then we provided on top of what blends do not
> provide: repository with backports, VMs etc... may be at some
> point things would converge somehow but not yet

I'd like to point out that Blends do not explicitly exclude these
features - its just that nobody has done the work to generalise simply
methods to do this (but I we talked about this before :-P ).

> > Right. I also find the CI tests important, and it would be great to
> > extend them to backports, experimental and such.
> 
> yes -- autopkgtest CI is great but doesn't cut it for mass backporting
> since we don't even want to upload any package backport to distro X if
> we know that it is going to fail there.  Thus package build time
> testing is necessary.  and then it would indeed be great to setup a CI
> using autopkgtest for all the backports to guarantee that they continue
> working as additional backports enter the stage.

+1

Kind regards

      Andreas. 

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#8512

On Tue, 16 Feb 2016, Andreas Tille wrote:

> Hi,

> On Tue, Feb 16, 2016 at 08:47:37AM -0500, Yaroslav Halchenko wrote:

> > Because we overlap with / part of / superset of both Med and Science, so
> > we are part of those blends.  We didn't feel like duplicating anything
> > from those two blends within yet another blend would be of any benefit
> > to anyone.

> Just for the record: I disagree with this statement. :-)

> It would be not duplicated work to arrange sensible tasks for your
> workfield.  I'm not sure what other duplication you might have in mind.

we arranged them within debian med and debian science.  Should have we
arranged them as well within yet another blend?  or our tasks do not
belong to Science/Med?

Anyways -- those were rhetoric questions, not intended for an answer ;)

> I'd really welcome if you would integrate some of your tools into the
> general Blends framework (but I we talked about this before).

yeap

> > And then we provided on top of what blends do not
> > provide: repository with backports, VMs etc... may be at some
> > point things would converge somehow but not yet

> I'd like to point out that Blends do not explicitly exclude these
> features - its just that nobody has done the work to generalise simply
> methods to do this (but I we talked about this before :-P ).

yeap

> > > Right. I also find the CI tests important, and it would be great to
> > > extend them to backports, experimental and such.

> > yes -- autopkgtest CI is great but doesn't cut it for mass backporting
> > since we don't even want to upload any package backport to distro X if
> > we know that it is going to fail there.  Thus package build time
> > testing is necessary.  and then it would indeed be great to setup a CI
> > using autopkgtest for all the backports to guarantee that they continue
> > working as additional backports enter the stage.

> +1

yeap ;)
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[toc] | [prev] | [next] | [standalone]

#8513

Yaroslav Halchenko <debian@onerussian.com> writes:
>> It would be not duplicated work to arrange sensible tasks for your
>> workfield.  I'm not sure what other duplication you might have in mind.
>
> we arranged them within debian med and debian science.  Should have we
> arranged them as well within yet another blend?  or our tasks do not
> belong to Science/Med?
>
> Anyways -- those were rhetoric questions, not intended for an answer ;)

Are they? I (being new to this) would be not sure: There are always
tasks (tasks? or packages?) that do not really belong to exactly one
blend -- many of "astro-publication" is not really astronomy related but
taken from science-publication. And astronomy-education is essentially
identical to education-astronomy ... A potential
high-energy-astrophysics task would share much with a common high energy
physics task. And so on.

In my opinion (this was, however, advocated so by Andreas :-) ) it is
about visibility: I didn't really realize that there is a neuro-debian
what-ever until this thread. And I am at the end curious why this is the
case. Even if it shares much with d-science and d-med, it would be IMO
useful to have a "NeuroDebian" entry in the blends list; just for the
case that someone like me want to know for what fields we have "special
editions". And the backports problem *is* IMO a common interest, at
least.

>> > > Right. I also find the CI tests important, and it would be great to
>> > > extend them to backports, experimental and such.
>
>> > yes -- autopkgtest CI is great but doesn't cut it for mass backporting
>> > since we don't even want to upload any package backport to distro X if
>> > we know that it is going to fail there.  Thus package build time
>> > testing is necessary.  and then it would indeed be great to setup a CI
>> > using autopkgtest for all the backports to guarantee that they continue
>> > working as additional backports enter the stage.
>
>> +1
>
> yeap ;)

While this is in principle correct, it misses a bit my point: Sure,
build time tests are essential for backports. However, if you backport
package A which is a dependency of B, then the build time test of A will
not test the function of B with the backported A. There is always the
danger that backported packages break installed ones. That's why I would
opt for CI tests wherever possible -- usually the build time tests are
easily rewritten to run on the installed package as well. And for Python
(which today is a large part of analysis packages), this is really
trivial.

Best

Ole

[toc] | [prev] | [next] | [standalone]

#8514

On Tue, Feb 16, 2016 at 09:49:59PM +0100, Ole Streicher wrote:
> > Anyways -- those were rhetoric questions, not intended for an answer ;)
> 
> Are they? I (being new to this) would be not sure: There are always
> tasks (tasks? or packages?) that do not really belong to exactly one
> blend -- many of "astro-publication" is not really astronomy related but
> taken from science-publication. And astronomy-education is essentially
> identical to education-astronomy ... A potential
> high-energy-astrophysics task would share much with a common high energy
> physics task. And so on.

Good to know that somebody fully agrees with the opinion I raised
frequently before. ;-)
 
> In my opinion (this was, however, advocated so by Andreas :-) ) it is
> about visibility: I didn't really realize that there is a neuro-debian
> what-ever until this thread.

I know since some of the parts are in Debian Med - but this is "by
chance" since we share a common interest.  If I would like to promote
NeuroDebian I would not ignore the chance to be mentioned at the Blends
entry page[1].  From a promotion point of view NeuroDebian looks rather
like a derivative than a Blend.  As far as I understood Yaroslav and
Michael they somehow promote NeuroDebian also under this name in their
scientific community.  I personally consider this dangerous since if the
two main propagators might change their jobs in a different direction
the stuff they invented will be orphaned. (I have seen this happen in
other derivatives frequently.)

>From a Debian centric point of view NeuroDebian is a Blend that fully
ignores existing Blends tools but rather invents their own and don't
give it the name Blend. :-)

> And I am at the end curious why this is the
> case. Even if it shares much with d-science and d-med, it would be IMO
> useful to have a "NeuroDebian" entry in the blends list; just for the
> case that someone like me want to know for what fields we have "special
> editions". And the backports problem *is* IMO a common interest, at
> least.

+1
 
> > yeap ;)
> 
> While this is in principle correct, it misses a bit my point: Sure,
> build time tests are essential for backports. However, if you backport
> package A which is a dependency of B, then the build time test of A will
> not test the function of B with the backported A. There is always the
> danger that backported packages break installed ones. That's why I would
> opt for CI tests wherever possible -- usually the build time tests are
> easily rewritten to run on the installed package as well. And for Python
> (which today is a large part of analysis packages), this is really
> trivial.

+1

Kind regards

      Andreas.

[1] https://www.debian.org/blends/

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#8516

On Wed, 17 Feb 2016, Andreas Tille wrote:
> I know since some of the parts are in Debian Med - but this is "by
> chance" since we share a common interest.  If I would like to promote
> NeuroDebian I would not ignore the chance to be mentioned at the Blends
> entry page[1].  From a promotion point of view NeuroDebian looks rather
> like a derivative than a Blend.  As far as I understood Yaroslav and
> Michael they somehow promote NeuroDebian also under this name in their
> scientific community.  I personally consider this dangerous since if the
> two main propagators might change their jobs in a different direction
> the stuff they invented will be orphaned. (I have seen this happen in
> other derivatives frequently.)

We could continue this discussion and my replies would be like
- NeuroDebian is not a derivative, all our work targets stock Debian
  distribution (sooner or later). We are more of an extension ;) (aren't
  blends are as well?)
- Not that I wish that upon ourselves, but rather to accent
  importance/significance/value of some folks... I wonder where Debian
  Science and Med would end up if Andreas changed his job/moved to
  another direction (I have seen many things happened in my lifetime).

  In contrast, NeuroDebian, like a good cuckoo, contributes its
  kiddos to other blends, thus increasing amount of care (damn thing
  that both major blends we contribute to are in large lead by the same
  guy)
...

but I would say -- such disgussion wouldn't be productive, so
let's stop here for now ;)

BTW, while building bigger plans -- who is going to the next Debconf? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.project

csiph-web