Re: Investigating a reproducibility failure

[zimoun]

Hi,

On Tue, 15 Feb 2022 at 15:10, Bengt Richter  wrote:

> I suspect what you really want to reproduce is not verbatim
> code, but the abstract computation that it implements,
> typically a digitally simulated experiment?

[...]

> Maybe the above pi computation could be a start on some kind
> of abstract model validation test? It's simple, but it pulls
> on a lot of simulation tool chains. WDYT?

Well, it depends on the community which term they pick for which
concept:

 - same team, same experimental setup
 - different team, same experimental setup
 - different team, different experimental setup

and the terms are repeat, replicate, reproduce.  For details, see [1].

Since Konrad is editor for the ReScience journal, I guess ’reproduce’
means [2]:

Reproduction of a computational study means running the same
computation on the same input data, and then checking if the
results are the same, or at least “close enough” when it comes
to numerical approximations. Reproduction can be considered as
software testing at the level of a complete study.

Where my understanding of your “abstract computation” looks more as [2]:

Replication of a scientific study (computational or other) means
repeating a published protocol, respecting its spirit and
intentions but varying the technical details. For computational
work, this would mean using different software, running a
simulation from different initial conditions, etc. The idea is
to change something that everyone believes shouldn’t matter, and
see if the scientific conclusions are affected or not.


Therefore, again from my understanding, you are somehow proposing what
science should be. :-) It is what the initiative GuixHPC [3] is trying
to tackle.

Transparency and full control of the variability––the roots of the
scientific method––allow to achieve, with more or less success,
’reproduction’.  Here and today, Guix plays a central role for
reproducing because Guix does not cheat with transparency and full
control of variability.

Note that some people are calling for bit-to-bit scientific
reproduction.  I am not.  Because the meaning of “same” or “equal”
depends on the scientific fields.  However, it is up to any scientific
debate or controversy to draw the line for “same” and argue if the
conclusions hold.  Again, transparency and full control of the
variability are fundamental here.  How to argue if they are not
satisfied?

Then, and out of Guix scope, if the reproduced result matters enough,
people can try to replicate, for confirmation, for performance
improvements, or as a step targeting another results.  This replication
can use Guix to control the variability and also help the reproduction
of the replication; but Guix does not take a central role here.

Last, it is in this second and other steps that the “abstract model”
could play role, and it is out of Guix scope, IMHO.


1: 
2: 
3: 


Cheers,
simon

Re: emacs tramp in remote guix

[Max Brieiev]

Also in latest master, Emacs exposed new user options
connection-local-profile-alist and connection-local-criteria-alist.

On guix machine dired complained, when I used /sudo:: about missing ls command,
and the following fixed it for me:

(add-to-list 'connection-local-profile-alist
 '(tramp-guix-connection-local (tramp-remote-path 
tramp-own-remote-path)))

(add-to-list 'connection-local-criteria-alist
 `((:application tramp :protocol "sudo" :machine ,(system-name))
   tramp-guix-connection-local))

Re: Investigating a reproducibility failure

[Konrad Hinsen]

Hi Bengt and Simon,

zimoun  writes:

> Note that some people are calling for bit-to-bit scientific
> reproduction.  I am not.  Because the meaning of “same” or “equal”

I am. Not as a goal in itself, because in the larger scientific context
it's robust replicability that matters, not bit-for-bit re-execution.
And yet, the latter matters for two reasons :

 - It's verifiable automatically, making it cheap and fast to check.
   No need to bother an expert for a qualified opinion.

 - If you hit a case of non-replicability (scientifically relevant
   differences in two computations that everybody expects to yield
   equivalent results), then it is nearly impossible to investigate
   if the individual computations are not bit-for-bit reproducible.

Making scientific computations bit-for-bit reproducible is the moral
equivalent of keeping a detailed lab notebook: doing your best to tell
others exactly what you did.

> conclusions hold.  Again, transparency and full control of the
> variability are fundamental here.  How to argue if they are not
> satisfied?

Exactly, that's very similar to my second point.

Or, in Bengt's formulation:

> The details of Fortran version or Julia/Clang or guile
> pedigree only really come into play for forensics looking
> for where the abstract was implemented differently.

When the forensics are called in, then...

> Thus far, "show me the code" is the usual way to ask someone
> what they did, and guix makes is possible to answer in great
> detail.

... "show me the code" is not sufficient. You must also be sure that the
code you look at is really the code that was run. And that's the role of
bit-for-bit reproducibility.

Cheers,
  Konrad.

Re: Changing permissions of files created with simple-service etc-service-type

[Josua Stingelin]

> > I'm using the etc-service-type of the simple-service to copy the file. Which
> > works great. But sadly grants read-access to everyone. I'd prefer it only be
> > readable by root.
> >
> > How can I achieve that?
> 
> Currently ‘etc-service-type’ does not let you specify permissions.  All
> the files that end up in /etc first go through the store though, so
> changing the permission of those files once copied under /etc wouldn’t
> buy you much in terms of confidentiality.  For example, there’s a copy
> of ‘wpa_supplicant.conf’ above in your store.  For that reason, files
> containing secrets must be handled “out of band”, without Guix support.
> 
> I guess changing permissions for /etc could still be useful for those
> programs that verify permission bits and refuse to start if the config
> file is readable by all.  However, those programs may have a good reason
> to verify that, so…
> 
> Thoughts?

I see. Thanks for the clarification! I will try that approach.

Re: seatd-service-type

[Josua Stingelin]

On Mon, Feb 14, 2022 at 05:08:14PM +0800, Declan wrote:
> 
> I am running patch-set from that link on my machine and it's working
> without any modifications. I'd like to see it got merged.
> 
> FYI, I just switch to Guix recently. Also I am not very familar this
> email workflow yet.
> 
> > There already exists a patch-set to add seatd and greetd to Guix [1],
> > maybe you could try testing the patch-set and see if it works for you?
> >
> > [1] https://issues.guix.gnu.org/49969
> >
> > Best,

Somehow I missed the mail above. Must have deleted it accidentally. I'm willing
to test the patches.

Is there a way to download the entire patch set at once or will I have to
download them one-by-one?

Thanks,

Re: Unable to bootstrap Guix without substitutes

[Greg Hogan]

On Thu, Feb 10, 2022 at 8:39 PM Timothy Sample  wrote:

> I can perform the build successfully using
>
> $ guix build --check \
> -e '(@@ (gnu packages commencement) bash-masboot0)'
>
> That scary backtrace happens even for the successful build, so I’m
> pretty sure it is not the issue.  (Note that the configure test succeeds
> in the end with a “yes”.)
>
> Is there anything else suspicious in the logs?
>

Timothy,

Thank you for checking this on your own system, it was quite helpful to
know that the failure was not universal.

I found a solution to building bash-mesboot0 in bug #49985 in mounting /tmp
as tmpfs, as noted by Ludo'.

I then saw the error building binutils-mesboot0 as in bug #41264, for which
Mathieu proposed an idea for fixing Mes, still awaiting implementation.

As a temporary fix the same tmpfs trick works when bind mounting /gnu and
/var/guix onto the /tmp tmpfs. This should work for my workflow, and I am
glad to see that others have continued to attempt to bootstrap from source
without substitutes.

Greg

Re: Missing dependency for emacs-magit

[Zelphir Kaltstahl]

Hello,

On 2/15/22 20:54, Liliana Marie Prikler wrote:

Hi Zelphir,

Am Dienstag, dem 15.02.2022 um 09:45 + schrieb Zelphir Kaltstahl:

Hello Liliana,

On 2/14/22 20:33, Liliana Marie Prikler wrote:

Hi Zelphir,

Am Montag, dem 14.02.2022 um 18:41 + schrieb Zelphir Kaltstahl:

[...]

I think we need some multi-level printf debugging here.

First, after  `source "${GUIX_PROFILE}/etc/profile"`, is
EMACSLOADPATH
correctly pointing to the share/emacs/site-lisp of
${GUIX_EXTRA_PROFILES}/emacs-test-profile?

Second, before and after executing your init.el snippet, what are
the
contents of load-path?
Do they contain /gnu/store/SOME_LONG_HASH-magit-MAGIT_VERSION?

Cheers

To simplify things, I created a shell script, which does the calls:


#!/usr/bin/env bash

set -Eeuxo pipefail

# source the environment
GUIX_PROFILE="${GUIX_EXTRA_PROFILES}/emacs-test-profile"
. "${GUIX_PROFILE}/etc/profile"
printf "emacs load path: %s\n" "${EMACSLOADPATH}"

# run emacs
env XMODIFIERS='' emacs


This outputs the following:


[...]


Magit line is:


"/gnu/store/f0461m96rhnpkmhjlj06yz058pqyj02d-emacs-magit-
3.3.0/share/emacs/site-lisp/magit-3.3.0"


Okay, this means that subdirs.el is correctly expanded.  The next
question regards autoloads.  Is (featurep 'magit-autoloads) t or nil?


It is t. That is after loading `init.el` and all it contains, but there is no 
magit configuration happening inside this `init.el` yet.


[...]

Best regards,
Zelphir

--
repositories:https://notabug.org/ZelphirKaltstahl

Re: seatd-service-type

[Declan Qian]

Josua Stingelin  writes:

> On Mon, Feb 14, 2022 at 05:08:14PM +0800, Declan wrote:
>>
>> I am running patch-set from that link on my machine and it's working
>> without any modifications. I'd like to see it got merged.
>>
>> FYI, I just switch to Guix recently. Also I am not very familar this
>> email workflow yet.
>>
>> > There already exists a patch-set to add seatd and greetd to Guix [1],
>> > maybe you could try testing the patch-set and see if it works for you?
>> >
>> > [1] https://issues.guix.gnu.org/49969
>> >
>> > Best,
>
> Somehow I missed the mail above. Must have deleted it accidentally. I'm 
> willing
> to test the patches.
>
> Is there a way to download the entire patch set at once or will I have to
> download them one-by-one?
>
> Thanks,
>
>

Hmm... I am reading guix.patches from news.gmane.io using Gnus.
Patch-set can be easily downloaded by selecting them and then invoked
gnus keybinding O m. Gnus can save them all in one file if you choose
the same filename while saving. For https://issues.guix.gnu.org/49969. I
downloaded the latest v8 [1/7 -- 7/7] (https://i.imgur.com/TSRZOtx.png)

Currently I pushed the those applied changes to this url
https://gitlab.com/declanqian/guix/-/commits/test_greetd/
so it can be easily rebased on master later.

Here is my unpolished Guix system config running seatd/greetd
https://gist.github.com/declanqian/79873926d3db23230b11cd9997a8c6f8

However, I didn't see the error from here
https://issues.guix.gnu.org/49969#89. Quite the contrary, `./bootstrap
./configure ./make` worked just fine on my machine. No idea whether I
did something wrong.

I am using `guix shell -D guix --pure` from guix info manul.
Also build greetd using `./pre-inst-env guix build greetd` to be sure.
Here's the output:
 /gnu/store/fdjk9mmif1038g9qjxachfmdmhs8p0rr-greetd-0.8.0

Let me know if you want further information.

-- 
~/path2signature


signature.asc
Description: PGP signature