Reproducible Research Hackathon: Friday, July 3rd

Reproducible Research Hackathon: Friday, July 3rd

[simon tournier]

Hello,

We are pleased to announce a Hackathon about Reproducible Science.

We propose to collectively tackle some issues on *Friday, July 3rd*:

 - identify stumbling blocks in using Guix to write end-to-end
pipelines,
 - document how to achieve this,
 - feed the Guix-Past channel by other old packages,
 - provide guix.scm for some of the ReScience C submissions.

Feel free to contact us at guix-hpc@gnu.org if you would like to hack
with us.

We will meet at *9:30 CEST* on the #guix-hpc channel of
irc.freenode.net.  You can use this web client to reach us:

  http://guix.gnu.org/contact/irc/

(tweaking the channel name).

Read more details at:

  https://hpc.guix.info/blog/2020/06/reproducible-research-hackathon

Hope to see you on Friday.

Re: Reproducible Research Hackathon: Friday, July 3rd

[Pjotr Prins]

We at UTHSC are game. We are struggling with an old version of the
GeneNetwork web service 1.x which is now running on a 10 year old
CentOS.  The backup time machine server died recently.

GenNetwork1 depends on Python 2.4(!) with modules that have not been
updated this century, and an older version of Apache with mod_python,
amongst other things. We would like to use the guix time-machine
feature to run older versions on demand in containers, also for the
recent GeneNetwork2 version which runs on a modern Guix stack. When we
get it to work I would like to push the older packages in Guix-Past.

Bit much for one day, but let's see where it ends.

There is no point in updating the older GeneNetwork1 instances, I mean
the code. The point really is that it is a reproducible version tied
to older scientific publications that people still can explore. 

Note that GeneNetwork requires a largisch MySQL/MariaDB (170GB)
which is also a snapshot in time. We have 5+ snapshots of that
database that go with 5+ versions of the code. We want to run them all
under Guix so we no longer have to care about the underlying Linux
distro. 

With the newer GeneNetwork2 stack we are thinking of making use of
Guix timemachine to run snapshots, firing containers up on demand.
These will have to be tied with a certain version of the database, so
we have to force time points maintained outside the package Guix git
repo. The databases can be ready to run - listening on a different
port for each version. Nice challenge and it will make a great story
when it works.

Pj.

On Tue, Jun 30, 2020 at 02:40:12PM +0200, simon tournier wrote:
> Hello,
> 
> We are pleased to announce a Hackathon about Reproducible Science.
> 
> We propose to collectively tackle some issues on *Friday, July 3rd*:
> 
>  - identify stumbling blocks in using Guix to write end-to-end
> pipelines,
>  - document how to achieve this,
>  - feed the Guix-Past channel by other old packages,
>  - provide guix.scm for some of the ReScience C submissions.
> 
> Feel free to contact us at guix-hpc@gnu.org if you would like to hack
> with us.
> 
> We will meet at *9:30 CEST* on the #guix-hpc channel of
> irc.freenode.net.  You can use this web client to reach us:
> 
>   http://guix.gnu.org/contact/irc/
> 
> (tweaking the channel name).
> 
> Read more details at:
> 
>   https://hpc.guix.info/blog/2020/06/reproducible-research-hackathon
> 
> Hope to see you on Friday.

Re: Reproducible Research Hackathon: Friday, July 3rd

[zimoun]

Hi Pjotr,

Thank you for sharing your plans.

On Tue, 30 Jun 2020 at 23:57, Pjotr Prins <pjotr.public12@thebird.nl> wrote:

> GenNetwork1 depends on Python 2.4(!) with modules that have not been
> updated this century, and an older version of Apache with mod_python,
> amongst other things. We would like to use the guix time-machine
> feature to run older versions on demand in containers, also for the
> recent GeneNetwork2 version which runs on a modern Guix stack. When we
> get it to work I would like to push the older packages in Guix-Past.

I guess that the recent commit [1] by Efraim is part of this effort. :-)

By container, what do you have in mind:
    guix time-machine --channels=file.scm \

 -- environment --container
or 
 -- pack -f 
or
 -- system *-image

?

1: https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/f9fe4d8ac2706834fcff477db8f5421de537d78e


> Note that GeneNetwork requires a largisch MySQL/MariaDB (170GB)
> which is also a snapshot in time. We have 5+ snapshots of that
> database that go with 5+ versions of the code. We want to run them all
> under Guix so we no longer have to care about the underlying Linux
> distro.

I agree that Guix does not have (yet!) good management of large data
set.  The /gnu/store is not designed for that, if I have correctly
understood.  Even we have already discussed Content-Addressable Storage
(CAS) on gwl-devel@gnu.org, AFAIR, we have not ended up with a good
plan.  Well, it will not be fixed on Friday. :-)

But for sure, it is something to keep in mind.


So, see you on Friday. :-)

Cheers,
simon

Re: Reproducible Research Hackathon: Friday, July 3rd

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

On Wed, Jul 01, 2020 at 11:10:23AM +0200, zimoun wrote:
> Hi Pjotr,
> 
> Thank you for sharing your plans.
> 
> On Tue, 30 Jun 2020 at 23:57, Pjotr Prins <pjotr.public12@thebird.nl> wrote:
> 
> > GenNetwork1 depends on Python 2.4(!) with modules that have not been
> > updated this century, and an older version of Apache with mod_python,
> > amongst other things. We would like to use the guix time-machine
> > feature to run older versions on demand in containers, also for the
> > recent GeneNetwork2 version which runs on a modern Guix stack. When we
> > get it to work I would like to push the older packages in Guix-Past.
> 
> I guess that the recent commit [1] by Efraim is part of this effort. :-)

Part of the effort :) I have a bunch more older packages that I'll
probably push to guix-past as time goes on. Right now I have a
no-longer-working octave-3.4.3 with some deps, apache-2.2 and possibly
php-5.6. They're possibly ready to push as-is, but I want to make sure
they actually work for some task before adding them.

> 
> By container, what do you have in mind:
>     guix time-machine --channels=file.scm \
> 
>  -- environment --container
> or 
>  -- pack -f 
> or
>  -- system *-image
> 
> ?

I think we're looking at 'guix system container' so it can be a
"standard" guix service using them (as much as custom guix services are
standard).

> 
> 1: https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/f9fe4d8ac2706834fcff477db8f5421de537d78e
> 
> 
> > Note that GeneNetwork requires a largisch MySQL/MariaDB (170GB)
> > which is also a snapshot in time. We have 5+ snapshots of that
> > database that go with 5+ versions of the code. We want to run them all
> > under Guix so we no longer have to care about the underlying Linux
> > distro.
> 
> I agree that Guix does not have (yet!) good management of large data
> set.  The /gnu/store is not designed for that, if I have correctly
> understood.  Even we have already discussed Content-Addressable Storage
> (CAS) on gwl-devel@gnu.org, AFAIR, we have not ended up with a good
> plan.  Well, it will not be fixed on Friday. :-)
> 
> But for sure, it is something to keep in mind.
> 
> 
> So, see you on Friday. :-)
> 
> Cheers,
> simon
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Reproducible Research Hackathon: Friday, July 3rd

[zimoun]

Dear,

Thank you all for joining!


A PAD is still open at:

  https://mensuel.framapad.org/p/guix-hackathon-9hlj?lang=en

Please add whatever you have been up.  Or drop an email.

We are interested to hear your feedback.  Especially about what pass,
what fail and what you have learnt, if you enjoyed the experience, or on
the contrary if you not, what could be improved for the next round.


Personally, I spent the day with the good ol' Fortran and codes using
the norm 77.  And I have enjoyed the flexibility of Guix: navigate
between the versions, running in container, etc..  For example,

  guix time-machine -C channels.scm -- build -L . foo
  guix time-machine -C channels.scm \
      -- environment --container -L . foo --ad-hoc bar@x.y
  [env] ./configure --with-bar=xx && make

And Guix helps a lot to expose "hidden" dependencies, i.e., not always
explicitly mentioned in paper's instructions. Well, something that I
learnt is you need some resource at hand, at least download or build the
substitutes in advance.

The "g77" issue [1] is not tackled but some points have been raised, so
maybe soonish. :-)

1: https://github.com/ReScience/submissions/issues/41

On the Guix side, a missing feature is to search back in history, i.e.,
somehow improves [2] (which starts 2019-01-01) and be able to find the
commit (or range of commits) which provided foo@x.y and bar@a.b

2: https://data.guix.gnu.org/repository/1/branch/master/package/boost


Well, thank you all again!  And hope to see you again on #guix-hpc. :-)

Cheers,
simon

Re: Reproducible Research Hackathon: Friday, July 3rd

[Ricardo Wurmus]

zimoun <zimon.toutoune@gmail.com> writes:

> On the Guix side, a missing feature is to search back in history, i.e.,
> somehow improves [2] (which starts 2019-01-01) and be able to find the
> commit (or range of commits) which provided foo@x.y and bar@a.b
>
> 2: https://data.guix.gnu.org/repository/1/branch/master/package/boost

I have been using things like “git log | grep -B10 "boost: Update"” to
find the commit updating a package, and then “git show
caffebabe…:gnu/packages/boost.scm” to view the file at the time of that
commit.

-- 
Ricardo

Re: Reproducible Research Hackathon: Friday, July 3rd

[Paul Garlick]

Hi Simon,

Thank you for organising the day.

> We are interested to hear your feedback.  Especially about what pass,
> what fail and what you have learnt, if you enjoyed the experience, or on
> the contrary if you not, what could be improved for the next round.

One outstanding puzzle for me is to figure out how to test a package
definition in a new channel.  For example, I have cloned the guix-past
repository and started to add a new package.  However, what is the best
workflow to attempt a build from the channel?  Do you add the channel
to the git checkout of guix?

Best regards,

Paul.

Re: Reproducible Research Hackathon: Friday, July 3rd

[zimoun]

Dear Pauk,

On Fri, 03 Jul 2020 at 18:56, Paul Garlick <pgarlick@tourbillion-technology.com> wrote:

> One outstanding puzzle for me is to figure out how to test a package
> definition in a new channel.  For example, I have cloned the guix-past
> repository and started to add a new package.  However, what is the best
> workflow to attempt a build from the channel?  Do you add the channel
> to the git checkout of guix?

I do not know if it is the best but I do:

  guix build -L path/to/clone the-package
  guix install -L path/to/clone the-package -p /tmp/test
  /tmp/test/bin/the-package


Otherwise, I put in a channels.scm file something like:

--8<---------------cut here---------------start------------->8---
(list
 (channel
    (name 'kikoo)
    (url "file:////home/simon/path/to/clone")
    (branch "master"))
 (channel
  (name 'guix) ; avoid to recompute heavy derivations and build modules
  (url "https://git.savannah.gnu.org/git/guix.git")
  (commit "000c7a0f70248ccf9dc774ef23da3e26d142c610"))
--8<---------------cut here---------------end--------------->8---

where commit is something I already have in /gnu/store, then:

  guix pull -C channels.scm -p /tmp/loc
  /tmp/loc/bin/guix install foo -p /tmp/test

but it is less convenient.


All the best,
simon

Re: Reproducible Research Hackathon: Friday, July 3rd

[Ricardo Wurmus]

Paul Garlick <pgarlick@tourbillion-technology.com> writes:

> One outstanding puzzle for me is to figure out how to test a package
> definition in a new channel.  For example, I have cloned the guix-past
> repository and started to add a new package.  However, what is the best
> workflow to attempt a build from the channel?  Do you add the channel
> to the git checkout of guix?

I did this from the checkout of “guix-past”:

    GUIX_PACKAGE_PATH=$PWD guix build my-package

-- 
Ricardo

Re: Reproducible Research Hackathon: Friday, July 3rd

[Konrad Hinsen]

Hi Simon et al.,

> We are interested to hear your feedback.  Especially about what pass,
> what fail and what you have learnt, if you enjoyed the experience, or on
> the contrary if you not, what could be improved for the next round.

For me this was the occasion to finally start playing with a channel
(guix-past), which has been on my agenda for a while. It was much easier
with people around to answer practical questions that would take a long
time to resolve by going through the documentation.

It was also a good occasion for thinking about how to package artifacts
of historical interest (i.e. recording release dates as metadata).

In terms of packaging techniques, there wasn't much new in it for me.
Python 2.4 is handled very much like Python 2.7, and since I installed
all this stuff by hand many times back in 2008, it felt almost familiar.

There is an interesting issue left for me to explore, which is why
Python 2.4 compiled with today's gcc has a bug that it definitely didn't
have back then. It's probably related to the many intentional
ambiguities in the C language standard, check out John Regehr's blog
(https://blog.regehr.org/) for interesting examples. That could become a
selling point for Guix because we have the option of compiling old
software with old compilers, which is hard with other infrastructures.

Cheers,
  Konrad

Re: Reproducible Research Hackathon: Friday, July 3rd

[Paul Garlick]

Hi Ricardo,

Many thanks for this tip.

> I did this from the checkout of “guix-past”:
> 
>     GUIX_PACKAGE_PATH=$PWD guix build my-package
> 

First, I changed directory to the 'modules' directory in the guix-past
checkout.  Then   the 'guix build' command can follow the
subdirectories and find the package definitions.

Best regards,

Paul.

Re: Reproducible Research Hackathon: Friday, July 3rd

[Paul Garlick]

Hi Simon,

On Fri, 2020-07-03 at 20:19 +0200, zimoun wrote:
> 
> I do not know if it is the best but I do:
> 
>   guix build -L path/to/clone the-package
>   guix install -L path/to/clone the-package -p /tmp/test
>   /tmp/test/bin/the-package

This works for me if I use the command:

$guix build -L /path/to/guix-past-checkout/modules the-package

Many thanks for the tip.

Best regards,

Paul.

Re: Reproducible Research Hackathon: Friday, July 3rd

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> There is an interesting issue left for me to explore, which is why
> Python 2.4 compiled with today's gcc has a bug that it definitely didn't
> have back then. It's probably related to the many intentional
> ambiguities in the C language standard, check out John Regehr's blog
> (https://blog.regehr.org/) for interesting examples. That could become a
> selling point for Guix because we have the option of compiling old
> software with old compilers, which is hard with other infrastructures.

Apologies for the delay.  What was this bug exactly?

I know Bonface addressed an issue related to how the Python 2.4 build
system would capture the kernel version via ‘uname’ a build time:

  https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7

But presumably you’re referring to something else, right?

Thanks,
Ludo’.

Re: Reproducible Research Hackathon: Friday, July 3rd

[Konrad Hinsen]

Hi Ludo,

> Apologies for the delay.  What was this bug exactly?
>
> I know Bonface addressed an issue related to how the Python 2.4 build
> system would capture the kernel version via ‘uname’ a build time:
>
>   https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7
>
> But presumably you’re referring to something else, right?

Indeed. The details are here:

  https://gitlab.inria.fr/guix-hpc/guix-past/-/issues/1

Since I won't be able to look into this before my summer vacations,
I opened an issue as a reminder.

Cheers,
  Konrad

Re: Reproducible Research Hackathon: Friday, July 3rd

[Bonface M. K.]

Konrad Hinsen <konrad.hinsen@fastmail.net> writes:

> Hi Ludo,
>
>> Apologies for the delay.  What was this bug exactly?
>>
>> I know Bonface addressed an issue related to how the Python 2.4 build
>> system would capture the kernel version via ‘uname’ a build time:
>>
>>   https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7
>>
>> But presumably you’re referring to something else, right?
>
> Indeed. The details are here:
>
>   https://gitlab.inria.fr/guix-hpc/guix-past/-/issues/1
>
> Since I won't be able to look into this before my summer vacations,
> I opened an issue as a reminder.
>
> Cheers,
>   Konrad
>
That's strange. To get the right results, you'd have to do a `2L ** 64`.
When I tried `2 ** 63` I got `-9223372036854775808`. There's also an
overflow error. Here's a snippet of what fails from
Python-2.4.6/Lib/test:

```
    # If this fails, probably using a strict IEEE-754 conforming libm, and x
    # is +Inf afterwards.  But Python wants overflows detected by default.
    try:
        x = math.exp(1000000000)
    except OverflowError:
        pass
    else:
        raise TestFailed("overflowing exp() didn't trigger OverflowError")
```

Maybe there's an overflow somewhere and we'd have to tweak libm? I'm
speculating though. I'd have to investigate this later.

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
One Divine Emacs To Rule Them All
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F

Re: Reproducible Research Hackathon: Friday, July 3rd

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Indeed. The details are here:
>
>   https://gitlab.inria.fr/guix-hpc/guix-past/-/issues/1

Oooh, thank you!  It looks like an “interesting” bug, one of those that
can help make the case for precise software environment control.  :-)

bonfacemunyoki@gmail.com (Bonface M. K.) skribis:

> That's strange. To get the right results, you'd have to do a `2L ** 64`.
> When I tried `2 ** 63` I got `-9223372036854775808`. There's also an
> overflow error. Here's a snippet of what fails from
> Python-2.4.6/Lib/test:
>
> ```
>     # If this fails, probably using a strict IEEE-754 conforming libm, and x
>     # is +Inf afterwards.  But Python wants overflows detected by default.
>     try:
>         x = math.exp(1000000000)
>     except OverflowError:
>         pass
>     else:
>         raise TestFailed("overflowing exp() didn't trigger OverflowError")
> ```
>
> Maybe there's an overflow somewhere and we'd have to tweak libm? I'm
> speculating though. I'd have to investigate this later.

Uh, weird!  We could check whether building Python with ‘-fwrapv’ helps.
See also <https://lwn.net/Articles/511259/>.

Ludo’.

Re: Reproducible Research Hackathon: Friday, July 3rd

[Konrad Hinsen]

Hi Bonface and Ludo,

> That's strange. To get the right results, you'd have to do a `2L ** 64`.

Exactly. The long integer arithmetic works fine, it's the detection
of the overflow of 64-bit ints that fails.

> When I tried `2 ** 63` I got `-9223372036854775808`. There's also an

Good catch, I hadn't tried that one!

> Oooh, thank you!  It looks like an “interesting” bug, one of those
> that can help make the case for precise software environment control.
> :-)

Exactly. Most people have understood by now that Python and libraries
higher up on the stack suffer from breaking changes, but C and
libc/libm, that's still the unshakable ground on which software can
safely be built.

> Uh, weird!  We could check whether building Python with ‘-fwrapv’ helps.
> See also <https://lwn.net/Articles/511259/>.

Interesting. I am finding out that I don't know most of the possible
suspects in this crime story ;-)

Cheers,
  Konrad