Re: Which build system for running a script?

Noé Lopez writes: I would use copy-build-system for this purpose. Zhu Zihao writes: As a hack, you may try `copy-build-system`. Rutherther writes: > There is copy-build-system. Thanks to all of you for this suggestion! Both the name and the documentation of copy-build-system suggest that

Which build system for running a script?

Hi everyone, I am working on package whose build step is basically "run this script in an environment with packages x, y, ...". In Guix terms: guix shell -C package1 package2 – ./script/build With gnu-build-system, I have to remove most steps, and I get lots of unnecessary build dependencies.

Re: Package with multiple source repositories

Hi Noé and Jake, Thanks, that looks like just what I need, and with the examples from GNOME I should be able to figure out how to use this mechanism in practice! Cheers, Konrad

Package with multiple source repositories

Hi everyone, A package I am working on has the unusual property of having its source split into two repositories, for historical reasons. Building it requires a checkout of both these repositories. Is this possible in a Guix package? E.g. having two source repositories? Or downloading one separate

Re: Per-user Guix installations

venient. It might be OK for a purely pedagogical installation, but really inconvenient for daily use. Cheers, Konrad. -- --------- Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences S

Re: “Build daemon drops its privileges” 👈 blog post

Ludovic Courtès writes: > But yes, providing a script for those who want to migrate would be nice. Is there any good reason for migrating, other than for testing the new setup? Konrad -- ----- Konrad Hinsen Centre de Biophysi

Re: “Build daemon drops its privileges” 👈 blog post

would make Guix a realistic alternative to Conda for many people. Cheers, Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: konrad DOT hinsen

Working with SBCL and ASDF (Common Lisp)

Hi everyone, Overall I have been happily using SBCL from Guix for Common Lisp development. But from time to time I run into a weird problem, and today it has hit a package I definitely need. The problem is documented in https://issues.guix.gnu.org/68764 for sbcl-clx-truetype, but it can happen fo

Re: Common Lisp packaging conventions

Hi Guillaume, > Usually we make a single package and declare which ASDF systems to > compile with the 'asd-systems' keyword in the arguments field (so the > option 1 in your list). Thanks for your input! Since that's the easiest solution for me as a packager, I won't complain :-) > However if an

Common Lisp packaging conventions

Hi everyone, I have packaged but not yet submitted CommonDoc (https://github.com/CommonDoc/common-doc) for Guix. What has kept me so far from submitting it is an uncertainty about conventions for packaging Common Lisp code. The repository cited above contains multiple Lisp systems: a core system

Re: Rebuilding a package after removing a build step

Hi Ludo, >> Unfortunately, when there are several packages with identical name and >> version number in two channels, Guix silently chooses one of them. >> It would probably be more useful to emit a warning. > > I believe that’s already the case. We already had some discussion, the conclusion bei

Re: Rebuilding a package after removing a build step

Hi Vagrant, > Rather than picking an arbitrary incremental number, I have in the past > used something based on the results from git describe... e.g. in my > current checkout of guix: > > $ git describe --match=v1.4'*' > v1.4.0-142685-gfc059c66cf > > e.g. 142685 commits past v1.4.0, with the c

Re: Rebuilding a package after removing a build step

Hi Andreas, >> It looks like Guix picked the larger one by >> alphanumeric order, which is not a reasonable choice in a development >> context. > > This is exactly the role of the number "-0." in front of the git commit; > one needs to specify by hand the order of the (non-)releases, as coming Go

Re: Rebuilding a package after removing a build step

Hi Kaelyn, > Whether it does or doesn't depends on the versions of the duplicate > packages in question. If both packages have the same version, then the > command line tools will warn about the ambiguous package > specification. If the version numbers are different, then the tools > will quietly

Re: Rebuilding a package after removing a build step

Hi Simon, >> Unfortunately, when there are several packages with identical name and >> version number in two channels, Guix silently chooses one of them. > > Choose when doing what? :-) Building, installing, ... whatever you can do with a package. > When running “guix shell” or “guix package”, i

Re: Rebuilding a package after removing a build step

Suhail Singh writes: > On a related note, when multiple channels are enabled, is there a way to > specify a specific package from a particular channel? Yes, using the -e option followed by the Guile module name. See https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html Yo

Re: Rebuilding a package after removing a build step

Hi Tobias, Geerinckx-Rice writes: > 'That is not possible.' You must somehow not have measured what you thought > you measured. Thanks for restoring my faith in Guix! You were in fact right, I was not measuring what I thought you measured, but for an unusual reason. > Can you 'reproduce' t

Rebuilding a package after removing a build step

Hi everyone, Until today, I thought that all parts of a package definition that could make a difference to the outputs enter somehow into the package hash, such that any relevant change to a package definition causes a rebuild. Today's experience: I built a package, then removed an "add-after" fo

Re: Search path for patches

Hi Liliana, Thanks for your suggestions! > The search-patch procedure in (gnu packages) – which see – uses the > %patch-path parameter to figure out where patches come from. > Typically, you'd place patches in the root directory, or somewhere > within your GUILE_LOAD_PATH to have them picked up,

Re: Are Guix-generated Docker images reproducible?

Hi Ignas and Suhail, Thanks for your comments! As you may have guessed, the reason for my question was that I encountered a non-reproducible Docker image build. And as both of you point out, the packages entering into the images must be reproducible. That's something I had actually checked for my

Are Guix-generated Docker images reproducible?

Hi everyone, Suppose you do guix time-machine --channels=channels.scm -- \ pack --format=docker --manifest=manifest.scm You keep a copy of channels.scm and manifest.scm, and run the same command a few months (and "guix pull"s) later, can you expect to get the exact same Docker image

Re: Search path for patches

Hi Ekaitz and Nicolas, Thanks for your comments! Ekaitz Zarraga writes: > In your own channel it is the root folder of the channel if I'm not > mistaken. Pretty annoying, honestly. > In Guix it's defaulted to the patches/ directory in packages/ I hadn't considered the possibility that the def

Search path for patches

Hi everyone, I have been searching for a while, without much success, so I am trying to tap into your collective wisdom: What's the search path used by search-patches? More precisely, where do I have to put patches 1. In a channel? 2. In a directory added to GUIX_PACKAGE_PATH/GUILE_LOAD_PATH?

Re: Debugging missing architecture support

Hi Ludo, > This shows an attempt to compile libwebp natively for aarch64-linux, > which fails on your machine. > > To cross compile, you would run: > > guix build python-jupyterlab --target=aarch64-linux-gnu That's already what I did, by giving the same option to "guix pack". I had someone che

Re: Debugging missing architecture support

Hi Saku, > Maybe someone else can give more general or Guix specific advice on > finding out the cause of such problems, but I believe that in this case > the fix would just be packaging GHC for aarch64-linux. It should[1] be > possible but it will require some work. > > [1]: https://gitlab.haskel

Re: Debugging missing architecture support

Ricardo Wurmus writes: > You can try this in guix repl: > > --8<---cut here---start->8--- > (import (srfi srfi-1) > (guix packages) > (gnu packages)) > > (define p (specification->package "git-annex")) > (define deps (package-development-inputs

Debugging missing architecture support

Hi Guix experts, in trying to build a Docker image for ARM64 (aarch64-linux), I am hitting errors of the kind "package git-annex@10.20230926 does not support aarch64-linux" There doesn't seem to be anything specifically in the package definitions that precludes building for aarch64-linux, so I

Re: Symlinks in "guix pack" and "guix shell"

Konrad Hinsen writes: > I found a simpler one, using a more recent Guix commit: > >guix time-machine --commit=7b0863f07a113caef26fea13909bd97d250b629e \ >-- pack -S /etc/ssl=etc/ssl --format=squashfs bash nss-certs > > Unfortunately, I have no idea how to debug thi

Re: Symlinks in "guix pack" and "guix shell"

Konrad Hinsen writes: > Here is my most recent experiment: I found a simpler one, using a more recent Guix commit: guix time-machine --commit=7b0863f07a113caef26fea13909bd97d250b629e \ -- pack -S /etc/ssl=etc/ssl --format=squashfs bash nss-certs Unfortunately, I have no idea how

Re: Symlinks in "guix pack" and "guix shell"

Hi Tomas, Thanks for your reply! > I think the relevant part is whether some certificate package is installed > (via > propagated inputs) or not. If I explicitly add nss-certs to the command > above, > it starts to work: Sorry, I forgot to add that I always have nss-certs among my packages wh

Symlinks in "guix pack" and "guix shell"

Dear Guix experts, I am seeing inconsistent behavior with the creation of symbolic links in containers and exports, and I wonder whether this is a bug or missing documentation. According to the documentation, there are no constraints on what I can link to. In practice, some symbolic link requests

Re: What's the difference between a shell environment and a profile?

Hi Simon and Ludo, >> It does not differ. What differs is that “guix shell” raises nothing >> for the collision – maybe “guix shell” does not check the collision, I >> do not remember – when “guix package” raises an error for the same >> collision. > > Indeed, ‘guix shell’ does not check collisio

What's the difference between a shell environment and a profile?

Hi Guix experts, While doing some software archeology, I ran into a behavior that I don't quit understand. First, I tested some Python 2 scripts in a shell environment: guix time-machine -C ./channels.scm \ -- shell --container \ python2 python2-mmtk python2-matplotlib \

Re: Time travel accident

Simon Tournier writes: > I have, > > --8<---cut here---start->8--- > $ guix gc --list-dead | grep 9gfmn1yra7rzavxb9wppqi4lpdvqid8c > finding garbage collector roots... > determining live/dead paths... > /gnu/store/9gfmn1yra7rzavxb9wppqi4lpdvqid8c-inferior-scrip

Re: Time travel accident

Hi Simon, > I get the same thing without doing anything special. Interesting. Before my clock-changing experiment, the same command line got me much further: the old Guix started to work and only failed when building OpenSSL. > Well, v1.0 appears to me as the zero for time-travel – soft limit.

Re: Time travel accident

Konrad Hinsen writes: >building profile with 1 package... >;;; WARNING: loading compiled file > /gnu/store/41zsnwsk02549kqb5njd3fadgnmkzww8-guix-module-union/lib/guile/3.0/site-ccache/guix/ui.go > failed: >;;; In procedure load-thunk-from-memory: incompatible bytecod

Re: Time travel accident

Julien Lepiller writes: > If you're able to find the derivation, you could set your system time > and guix build /gnu/store/that.drv. this should not require network at > all, so guix shouldn't complain. Sounds good. The error message contains the path to the derivation, so... let's just do it!

Re: Time travel accident

Hi Josselin and Julien, Thanks to both of you for your suggestions! Josselin Poiret writes: > We have --without-tests=package already, see --help-transform for all > available package transformations. The one annoying thing is that > disabling tests will change the derivation and you thus will

Time travel accident

Hi everyone, For doing some experiments with Python 3.8.2, I tried to use the commit that introduced that version into Guix; guix time-machine --commit=ce35dc84a10b05dc891bfae03f613b907337945e \ -- shell --pure python \ -- python3 That fails, due to a build failure in OpenSSL: buildi

Re: Using Guix inside a Guix container

Ludovic Courtès writes: > That’s an interesting use case! I guess we have a hard-enough time > getting the message through regarding the environment of tasks that we > didn’t really consider the environment of the “driver”. It takes something messy such as Snakemake to illustrate the importance

Re: Using Guix inside a Guix container

Hi Simon, > Which part of Guix do you need inside the containerized shell that you > cannot do outside? That's not the right question. There's always a way to do what I want to do outside. But that may be very inconvenient. > Considering your use-case with Snakemake, what I am doing is to wrap >

Re: Using Guix inside a Guix container

James Thomas writes: > Makes sense to me, because the guix package definition was only updated > with the new release (see 'guix edit guix'). Maybe you can try: Indeed. That's at least an explanation, though I still don't see *why* it is done this way. In fact, the role of the package "guix" isn

Re: License of “10 years of stories behind Guix”

Dear lawyers of the world, I agree for my contribution to the blog post https://guix.gnu.org/en/blog/2022/10-years-of-stories-behind-guix/ to be published under CC-BY-SA 4.0 and GFDL version 1.3 or later (or whatever other open license the maintainers of the blog might prefer in the future).

Using Guix inside a Guix container

Hi Guix, I have been playing with nested Guix containers recently, with some suprising findings, and I am wondering if what I am doing is considered officially supported or not. First: why? My use case is scientific workflows, for example using snakemake. I want to run my workflows in Guix contai

Re: Creating a container from a container

Konrad Hinsen writes: > In case it matters, I use -N for the outer container (in which I > use wget to fetch files), but not for the inner containers (the ones > whose creation causes the error). It does seem to matter... if I add -N for the inner container as well, the error disappea

Creating a container from a container

Hi everyone, I am trying to run "guix shell -C" inside another container created with "guix shell -C". I figured out that I need to take care of three aspects: - Include the package "guix" in the outer container. - --expose=/gnu/store such that guix-in-the-container can access the store -

Re: A real-life test of long-term reproducibility

Hi Ludo and Simon, > Sorry I replied to quickly; it should have been > ‘--disable-authentication’. > > Why? Because here you’re trying to travel to a commit that’s not part > of the “authenticated history”—that is, it’s not a descendant of the > “introductory commit”, which is the first commit in

Re: A real-life test of long-term reproducibility

Hi Ludo and Simon, > On Fri, 02 Sep 2022 at 15:17, Ludovic Courtès wrote: > >> Here you would need ‘--allow-downgrades’. > > Maybe time-machine could advertise of this option? And explain what it's about. I don't consider myself an absolute beginner with Guix, but I don't understand what's going

Re: A real-life test of long-term reproducibility

Hi Simon, > However, many things can be out of rail. This claim about > reproducibility over the time assumes: > > 1. compatibility of the Linux kernel > 2. availability of all the source code > 3. compatibility of the hardware > > Well, until now, nothing had been reported about #1. But, we

Re: A real-life test of long-term reproducibility

Hi Ludo, > We can go back to 1.0.0, and presumably to 0.15.0, but anything older > than this is unknown territory. Even 1.0.0 isn't obvious: $ guix time-machine --commit=version-1.0.0 -- environment guix guix time-machine: error: Git error: unable to parse OID - contains invalid characters

Re: A real-life test of long-term reproducibility

Hi Ludo and Tim, Thanks for your comments and experiments! Ludovic Courtès writes: > That’s a commit from January 2018, which is a few months before the > release of 0.15.0, the first release with proper ‘guix pull’ support: Ouch. I wasn't aware that even "guix pull" happened later! >> I don

A real-life test of long-term reproducibility

Hi everyone, One of our claims is that Guix can rebuild code identically as long as we have a machine with a Linux kernel and a POSIX filesystem. This week I had an occasion to put this to a real-life test. So far it's a failure. I can guess reasons for my failed attempts, but I don't think they w

Re: Investigating a reproducibility failure

Hi Simon, > We are far from OpenBLAS. :-) That's fine with me. The more distance between me and OpenBLAS, the happier I am ;-) > On Wed, 16 Feb 2022 at 14:04, Konrad Hinsen > wrote: > >> Making scientific computations bit-for-bit reproducible is the moral >> equ

Re: Investigating a reproducibility failure

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 r

Re: Investigating a reproducibility failure

Hi Ludo, > Konrad Hinsen skribis: > >> To see the failure, do >> >>guix time-machine \ >> --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \ >> -- build openblas > > For the record, there’s still a substitute available for this one: ... &

Re: License of your contributions to the blog at guix.gnu.org

Ludovic Courtès writes: > With a few exceptions, these articles do not have a clear license, which > we would like to fix. We propose to dual-license all the articles under > CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections, > no Front-Cover Texts, and no Back-Cover Texts.

Re: Investigating a reproducibility failure

Hi Ricardo and Simon, Ricardo Wurmus writes: > The case of OpenBLAS is an anomaly in that this mechanism seems to > produce different binaries dependent on where it is built. When I first Thanks a lot for those explanations, I hadn't realized how peculiar OpenBLAS is! > Your problem is that t

Re: Investigating a reproducibility failure

Hi Ricardo and Simon, Thanks for your insight! I didn't even know about lscpu. The output for my laptop is shown below. I tried building on a virtual machine, and that works fine. > CPU detection is a bottomless can of worms. That sounds very credible. But what can we do about this? There is ob

Investigating a reproducibility failure

Hi everyone, Two years ago, I published a supposedly reproducible computation, explaining how to re-run it at any time using Guix (it's at https://github.com/khinsen/rescience-ten-year-challenge-paper-3/). Yesterday, I got an e-mail from someone who tried, and failed. I tried myself, and failed as

Re: Investigating a reproducibility failure

Konrad Hinsen writes: > To see the failure, do > >guix time-machine \ > --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \ > -- build openblas > > The build log is attached, the first error is Oops... Two mistakes ! First, I forgot the attachment, so here it co

"guix package" failed with "integer expected from stream"

Hi Guix, Updating my packages after today's "guix pull" fails with the error message guix package: error: integer expected from stream There are two similar-looking bugs, both closed, suggesting that the problem has been fixed. I don't understand all the details, but I can confirm that it's

Re: Any go expert willing to help with updating IPFS?

"Leo Famulari" writes: > It's likely that you need to use a newer version of Go. Thanks, that did it! With go-1.17 it compiles fine. Cheers, Konrad

Re: Any go expert willing to help with updating IPFS?

Konrad Hinsen writes: > My current package definition is attached. Well, now it is: (define-public go-ipfs (package (name "go-ipfs") (version "0.11.0") (source (origin (method url-fetch/tarbomb) (uri (string-append "ht

Any go expert willing to help with updating IPFS?

Hi Guix, the version of IPFS in Guix is 0.8, and in view of the important changes introduced in 0.10, that's obsolete by now. Which is why I am trying to update to 0.11. My current package definition is attached. It fails, but provides no clear hint (to the Go ignorant that I am) about what is ac

Re: [Spam:]Re: “What’s in a package”

Katherine Cox-Buday writes: > As we've seen these past years with COVID-19 and the world's supply > chains, efficiency has some kind of inverse relationship with > robustness. If you go too far down the path of efficiency, you are not > very flexible, and you're building sand castles. That's exa

Re: [Spam:]Re: “What’s in a package”

wished for more than once is the possibility to run the individual build steps of a Guix package under my own account in my home directory, for debugging purposes. Konrad -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orl

Re: Removal of Python 2?

Hi Ryan, > Python 2 is no longer supported, but the Tauthon project [1] is > continuing support and backporting features from Python 3. We should Didn't know about Tauthon, thanks for the pointer! > consider packaging Tauthon in Guix and updating packages to depend on Yes, that sounds like an i

Re: Removal of Python 2?

Hi Ludo and Simon, Ludovic Courtès writes: > What we could do is start removing ‘python2-’ packages, especially those > with a non-negligible maintenance cost (numpy, scipy, matplotlib, etc.). > We can move them to the Guix-Past channel if there’s interest. Yes, that sounds like a good plan. Wi

Re: Removal of Python 2?

Hi Hartmut, > Python 2 is dead, dead, dead like the parrot and end-of-prolonged life > as of more than 1 1/2 years. Anyhow, there might still be quite some > software not ported to Python 3 after 10 years. So I'm afraid we need to > keep Python 2. At this time, more than 2500 packages still de

Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo

Hi Pjotr, > I have a feeling they won't be that interested ;). Depends on who and when. My idea is not to send them a mail saying, "look, we have a great idea, you should us it!". It's rather to open issues on their build systems to suggest features and actually help with the implementations. Goo

Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo

Hi Pjotr, > Maybe this is a crazy idea: Not crazy enough for me ;-) Today's mess with language and platform specific build systems is indeed a problem, and I have been thinking as well about how Guix could help with this beyond what it already does. Guix' big achievement, beyond being a practica

Re: Finding the store path of a package

Hi Ludo, > Why #:graft? #f? Because if you enable graft, you’ll potentially have > to build/download the thing, and that wouldn’t buy you anything because > the set of file names is the same in the grafted package. Four weeks later: this mostly works, but sometimes fails (by downloading/building

Re: Finding the channel in which a package is defined

Hi everyone, thanks for your suggestions. My award for the most useful one (to me) goes to Mathieu : > You can run something like: > > --8<---cut here---start->8--- > ,use (guix describe) (gnu packages) (gnu packages linux) > (%package-module-path) > (package-c

Re: Finding the channel in which a package is defined

Tobias, Thanks for your reply! > Does the ‘location’ field of ‘guix show PACKAGE’ do what you want? Taking coreutils as a test case, it displays: gnu/packages/base.scm:328:2 as a link pointing to: /gnu/store/3qykwxq1mqlin3lrb93s3rzi1ah5xia8-guix-module-union/share/guile/site/3.0/gnu/pa

Finding the channel in which a package is defined

Dear Guix experts, Is there a simple way to find out in which channel a given package was defined? I tried "guix edit" to see the source code, but it shows a file from a "module-union" directory in the store. Cheers, Konrad

Re: Finding the store path of a package

Hi Ludo, > Here’s an example of how to do that: Works fine, thanks! > Why #:graft? #f? Because if you enable graft, you’ll potentially have > to build/download the thing, and that wouldn’t buy you anything because > the set of file names is the same in the grafted package. OK, so that's the se

Re: Finding the store path of a package

Hi Simon, > On a side note, Ricardo did recently some stuff as UI for packages, > > > Looks good! My project has a lot of overlap, except that it is very intentionally not based on Web te

Re: Finding the store path of a package

Hi Ludo, > Yes. In the presence of grafts, run “guix build PKG”. That always > gives you the store file name of PKG, 100% reliable! At the cost of a few hours of CPU time, in the worst case. > I regularly do things like: > > ls $(guix build PKG)/bin > find $(guix build PKG) -name … What I

Re: Finding the store path of a package

Hi Simon, >> does “guix build -n” fit your use-case? > > Checking... yes! I hadn't even considered using "build" when building is > exactly what I do not want to happen. But yes, it works just fine. Not quite: $ guix build -n zziplib substitute: /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash

Re: Finding the store path of a package

Hi Simon, > does “guix build -n” fit your use-case? Checking... yes! I hadn't even considered using "build" when building is exactly what I do not want to happen. But yes, it works just fine. > Well, ’package-output’ in (guix packages) is what you need, I guess. And that works just fine as wel

Finding the store path of a package

Dear Guix experts, I wonder if there is a straightforward way to find the store path corresponding to a package, assuming that the package actually is in the store. I don't care if it's done via the CLI or via Guile code. Use case: Looking at the files inside a package. What I do now is "ls /gnu/

Re: Guix in Debian!

On 24/01/2021 05:04, Vagrant Cascadian wrote: Now on Debian you should be able to: apt install guix guix install dpkg guix environment --ad-hoc dpkg -- dpkg -i ./guix_1.2.0-3_amd64.deb It is almost like symmetry! Wow, that's excellent news. Probably the biggest to improvement to onb

Re: etc/news copyright (was Re: Translating the web site)

Ludovic Courtès writes: >> I attach a patch adding copyright notices, but I guess the authors >> should agree. I put them in Cc. > > If the authors agree, fine with me! Since I am in CC, I must be one of the authors, though I don't really remember what I could have contributed. Anyway, this is

Re: [OUTREACHY] Proposal: substitutes over IPFS

Hi Ludo, > I prefer not to volunteer to mentor it, but I’m happy to contribute to > discussions and code review. > > Who’d be willing to mentor it? I don't know what exactly that implies, so all I say for now is that I'd be happy to participate in this project. I know the IPFS side rather well, b

Re: Improve ASDF build system for Common Lisp libraries

Am 12.09.20 um 11:36 schrieb Guillaume Le Vaillant: I've been working on some changes to the asdf-build-system for Common Lisp libraries and programs: That sounds very promising, thanks for this substantial effort! I can't test this right now, but will do so as soon as possible. Cheers, K

Re: Reproducible Research Hackathon: Friday, July 3rd

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 had

Re: Reproducible Research Hackathon: Friday, July 3rd

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/d1977f5dccd73341f363cfa8d58ae3f

Re: Reproducible Research Hackathon: Friday, July 3rd

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 ch

Re: “Reproducible research articles, from source code to PDF”

Konrad Hinsen writes: > Sounds fine. I am not much of a hackathon expert, so I don't propose > myself for organizing this, but I can make a preselection of suitable > submissions to the ReScience challenge (no proprietary software etc.) > with comments about the specific challe

Re: “Reproducible research articles, from source code to PDF”

on expert, so I don't propose myself for organizing this, but I can make a preselection of suitable submissions to the ReScience challenge (no proprietary software etc.) with comments about the specific challenges. Cheers, Konrad -- -----

Re: “Reproducible research articles, from source code to PDF”

ocker. Or, for local execution, a Docker image containing Guix plus some tooling to do the equivalent of "guix time-machine –commit=xxx – build -f guix.scm" plus copying the contents of the generated package into the user's directory. Cheers, Konrad -- ----

Re: unexpected reproducibility of reproducible blog post?

Hi Ludo, > Grafts are normal derivations, and they’re deterministic: it’s just > about replacing a set of strings by another set of strings. > > On the implementation, see also > . Thanks for the clarification. That post makes i

Re: unexpected reproducibility of reproducible blog post?

Hi Simon, > I will add something overthere for tracking reproduciblity infos in > the future. It would actually be nice to have some external Guix reproducibility surveillance. A few benchmark packages that will be rebuilt regularly, using frozen commits via time-machine, and checked for bit-by-b

Re: unexpected reproducibility of reproducible blog post?

zimoun writes: > Argh! The author should watch the Fun MOOC about computational > reproducibility. ;-) That would probably help. I'll pass on the message ;-) I have also opened an issue for this: https://github.com/khinsen/reproducibility-with-guix/issues/2 > Grafts or maybe Guile 2 -> 3?

Re: unexpected reproducibility of reproducible blog post?

Hi Simon, > Based on the nice blog post [1], instead of really travelling I just > travel in time. :-) > If I read correctly and if I did not do any mistake, the final hash is > not the same now than before. It is not what I was expecting. > > Expected output (blog post): > /gnu/store/iqn9yyvi8im1

Re: TLS certificates for web browsers in guix environment --container

On 21/04/2020 22:50, Pierre Neidhardt wrote: Makes sense, thank you for the details. What about adding the above example to the manual page of `guix environment'?? Good idea. I suppose it's not just Web browsers that will need this. I remember occasional certificate problems when running scr

Re: GNU Guix 1.1.0 released

On 15/04/2020 15:17, Ludovic Courtès wrote: We are pleased to announce the release of GNU Guix 1.1.0. The news has made it to a widely read IT news site in Germany (which I didn't expect): https://www.heise.de/developer/meldung/Linux-GNU-Guix-1-1-ist-auf-dem-Weg-zu-minimalistischem-Bootstra

Re: Hyperlinks!

On 13/04/2020 13:13, Pierre Neidhardt wrote: Ludovic Courtès writes: I’d like to extend it to include references to the Guile manual, so that one could click on, say, ‘append’, but there might be too many false positives at that point. And then we would need DrRacket fanciness to be able to d

RE: good practices in science

bijan ghavami-kia writes: > It’s an interesting prospect, shouldn’t we be working towards this > fantastical goal? We (Guix) are already working towards the abstract goal of this project, because what Guix does is effectively provenance tracking for computations. Guix' package dependency graph i

Re: good practices in science

Hi Bengt, > (I guess I get excited reading prose that shows attention > to the distinction between abstractions and their representations. > Sort of like reading quotes from Plato, and thinking, "Hey, wow, > I've had some of those thoughts." :) There are plenty of good ideas in that project, I am

  1   2   3   >