Re: Feedback from JRES in Dijon

Hi Bengt, >> [1] >> https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible >> https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf >> > > Is [1] available as a libre video download?

Re: Feedback from JRES in Dijon

Hi Simon, > If I might, one the best presentation [1] -- that I am aware of -- on > this. Sorry in French. Thanks for the marketing :-) > [1] > https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible >

Re: Feedback from JRES in Dijon

Hi Julien and Pierre, > So they are doing physical simulation (fluid dynamics), so they don't > (can't) get the same result when running the same experiment > twice. They wart replicability, that is, even if the results are > different, they are close enough to each other that you have to draw >

Re: On DSLs

Hi Ludo, >> For better illustration, I'll try to rewrite my own manifests in the >> way I'd like to be able to write them. That's probably more useful >> than theory (a tough statement to make for a theoretician ;-) > > Agreed! Just to be clear: I actually intend to implement some infrastructure

Re: On DSLs

Hi Julien, > Could this discussion be saved in the cookbook for instance? I'd like > to have this kind of discussion on the approach of guix and ideas > behind it somewhere more accessible than the ML archive. Does it make > sense? I think it makes sense to archive summaries of such discussions.

Re: Python 2 end-of-life?

Hi Bengt and Simon, Nice discussion, please go on. With Simon taking the pragmatic point of view ("what can we do right now?") and Bengt the long-term idealist perspective ("where should Guix be going?"), we might end up getting both ends right. Bengt Richter writes: > The first step is

Re: Python 2 end-of-life?

Konrad Hinsen writes: > I'd say the very first thing we should do is look at all non-Python > packages that depend indirectly on Python 2. Here comes an update of my Python-2-in-Guix analysis. Sorted output, distinction between likely libraries and likely application packages. Plus th

Re: Python 2 end-of-life?

Hi Hartmut, > I assume many of these package can be updated. (Indeed I just updated > pdfposter, which I'm maintaining.) Great. That's the kind of response I was hoping for! > bypthon2 and ptpython2 are REPLs for python2 - bypthon and ptpython are > the resp. packages for python3. There are a

Re: Python 2 end-of-life?

Hi Bengt, > IOW, a bunch just differ by version -- I wonder how many of the > packages that drew in old versions could run fine with respective > latest versions of what they are dependent on? That's a very good question! > It would be really interesting if you could tweak your

Re: Store channel specification in profile

Pierre Neidhardt writes: > In this case, how would you intend to use guix time-machine to reproduce > these profiles? "guix time-machine" and inferiors are different ways to access specific Guix versions. "guix time-machine" simply runs a different Guix version. You can then use it to access

Re: Python 2 end-of-life?

Konrad Hinsen writes: > I'd say the very first thing we should do is look at all non-Python > packages that depend indirectly on Python 2. Here is an attempt at identifying them: ;; (use-modules (guix packages) (gnu pa

Re: Store channel specification in profile

Hi Pierre, > One question arises though: channel specifications only make sense for > profiles generated with manifests. Not even for those, if the manifest uses inferior-packages. I'd go for per-package channel specifications. They could be optimized (more compact, more efficiently usable) by

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, I'll start from the end: > What do we disagree on, actually? :-) This: >> 2. Power users will always write code in powerful languages that exceed >>what less advanced users can deal with. And since power users are not >>necessarily benevolent, this creates a trust issue for

An occasion to demonstrate Guix for reproducible research

Hi Guix, For those of you working in scientific research, here's an occasion to show the utility of Guix to the world: the ten-year reproducibility challenge run by the journal ReScience. You can find the announcement below. The main role I see for Guix in this challenge is to ensure

Re: Python 2 end-of-life?

Hi Simon, > What do you do? Well, me, personally, I continue to do most of my research using Python 2 because I cannot afford to port everything to Python 3. And since I do only number crunching, meaning nothing with security implications, I am not particularly worried. > Do we deprecate the

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, > So, you propose to "enrich" the DSL describing the manifest files, right? Perhaps. I suppose there are several possible approaches, and I don't claim to know what works best before actually trying. One way is to "harden" manifest files, providing richer constructs for defining and

Re: guix pull failed after 8 hours

Hi Ludo and Chris, > Could it be that those old systems were talking to hydra.gnu.org and > thus not getting any substitutes? > > https://lists.gnu.org/archive/html/info-guix/2019-06/msg1.html That's what happened to me on my oldest Guix installation (hosted on Ubuntu). I had done regular

Re: Profiles/manifests-related command line interface enhancements

Ludovic Courtès writes: > To me it’s not entirely clear that a unified command would be easier to > use for newcomers. For example, I’m not fond of “guix profile” as a Indeed. It's also not clear to me if a single command line package for beginners and power users is the best way to go. Maybe

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I’d like to think that writing Guile declarations for the OS config, > manifest, etc. is not just for “power users”. After all people, or > rather “computer-savvy” people in a broad sense, write JSON, YAML, > custom config files etc. routinely, and I don’t think the typical config >

Re: A better XML, config is code (was Re: Profiles/manifests-related command line...)

Hi Giovanni, > The real question is: a configure file is code or data? IMHO is code, Code is data with execution semantics, so "code" is a subset of "data". I'd reformulate the question as: should configuration data be literal data, or the result of a computation? The second opton is more

Re: Profiles/manifests-related command line interface enhancements

Hi Andy, > I wrote this for that purpose: > > > https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html Right, I had found this when searching for something. It seems to solve a couple of problems that I don't quite understand, but not so much those I do (file/network

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > Of course, using a general-purpose language upfront also comes at a > price, as you note. But I think that what it has to offer to users > outweighs the costs, and that’s a lesson learned from Emacs. Just to > say I’m not willing to replace ‘config.scm’ with ‘config.yaml’, if >

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I agree this is an important use case. It seems to me that the problem > here is being able to aggregate more than just packages. Yes, it's a bit more than that. We'd probably have to look at a couple of use cases to see what the most general content would be. > The Web application

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, >> I can of course share a manifest file by putting it in a public >> repository. But that isn't necessarily the best way. > > From my opinion, it is not the problem of Guix. Guix should not force > a practise, as good it should be. The way the users share manifests is > the problem of

Re: Profiles/manifests-related command line interface enhancements

Pierre Neidhardt writes: > By the way, the same should be possible from the installer: > > - Specify which channels you want to use. > - Specify which config.scm you want to use. Indeed, the config.scm > might rely on channels. > > This way, the Guix installation process would boil down to

Re: Profiles/manifests-related command line interface enhancements

Hi Ludo, > I think having ephemeral + persistent and declarative + imperative is > cool—I’d call that “flexible” rather than “messy”. :-) I agree. What's messy is how the concepts map to commands. How many Guix users understand that profiles are persistent environments, or environments

Re: Profiles/manifests-related command line interface enhancements

Hi Simon, > I am not sure to see which feature is missing. My main point is that the future evolution of functionality (and user interfaces) in this space should take into account usage scenarii, rather than adding features in an ad-hoc fashion. I can of course share a manifest file by putting

Re: Profiles/manifests-related command line interface enhancements

Hi Hartmut, > This becomes even messier if we would implement a "guix develop" > command, which is yet just another version of environment/profile. Yes, I worry also about making more of a mess by implementing special-purpose variants. > And adding another dimension: spawning a sub-shell

Re: Profiles/manifests-related command line interface enhancements

Pierre Neidhardt writes: > I'm actually surprised you find it surprising! :) > I can think of Simon, maybe Konrad(?) and myself who mentioned it > before. Yes, me too. I could add to Pierre's list of use cases, but I prefer to shift the discussion to a higher level. What we have been

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Konrad Hinsen writes: >> Looking forward to a patch! :-) > > If all goes well, next week ! Done: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37978 Cheers, Konrad.

Re: “Guix Profiles in Practice”

Hi Pierre, >> Jumping to symbol definitions, for example, or access to documentation. > > I can jump to definition with no problem. Is your load path set > properly? After inspection... no. At least not in all my Guix installations. It does work fine with the right path. > Access to the manual

Re: “Guix Profiles in Practice”

On 27/10/2019 12:30, Pierre Neidhardt wrote: Another talk could be about programming Guix from the REPL. Guix as a DSL if you will. Anyone interested in doing a talk about that? I would be very interested if someone could explain how they hack with Geiser: I'm still frustrated with it on a

Re: “Guix Profiles in Practice”

Pierre Neidhardt writes: > "Thompson, David" writes: > >> if it's a good idea. Probably not. So, I wonder if maybe a new >> subcommand, say 'guix develop', could address this common development >> use-case while allowing 'guix environment' to continue being the swiss >> army knife that it is.

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Pierre, > In the meantime I've played with Guix + Emacs and wrapped Guix CLI in > hopefully a more convenient way that makes it easy to track the channel > specifications for various manifests, to reproduce them, etc. > > See https://gitlab.com/emacs-guix/emacs-guix/issues/13, maybe that'll >

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Ludo, > I see. In a way one could argue that it’s not Guix’ problem, but OTOH > it’s clearly a problem that Guix doesn’t make it more convenient. I don't know much about Guix' problem, not being a software psychologist, but in the meantime I am trying to solve a problem that some Guix users

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

zimoun writes: >> No, at least not explicitly. My goal is reproducing computations from >> the past, so I need to re-animate old manifest files. These could of >> course contain references to inferior-packages, so they could be >> multi-commit, but this is not my focus. > > But does it fit with

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Simon, > I am not sure to understand everything, so my questions are: > > - Do you consider binaries coming from multiple commits and/or > multiple channels? No, at least not explicitly. My goal is reproducing computations from the past, so I need to re-animate old manifest files. These

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Ludo, > Did you define an environment along the lines of the example at > ? > > If so, this should behave in exactly the same way as a “regular” ‘guix > environment’, so I’m not sure where the issues regarding access to the > tty

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Ludo, > Did you define an environment along the lines of the example at > ? No. I did look at this approach briefly, but it looks difficult at least, if not impossible. The situation I need to address is re-creating an

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Ludo, >>> At the API level, there’s ‘inferior-for-channels’ which does that + >>> registers a GC root + maintains a cache so that the second time you use >>> a given instance of Guix it’s immediately available. >> >> Just what I need... > > Awesome, let us know how it goes! Not so well... If

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Ludo, > (Though printing addresses in a REPL isn’t “bad practice” IMO, it’s just > that it doesn’t mesh well with the intended use of notebooks.) And that's exactly the difference between a REPL and a reproducible document. Unfortunately, Jupyter tries to be both and thus never explains the

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Ludo, > That reminds me of an interesting issue regarding > bitwise-reproducibility that was raised on the Reproducible Builds > mailing list: > > > https://lists.reproducible-builds.org/pipermail/rb-general/2019-September/001657.html We ran into this problem as well in the Reproducible

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

Hi Ludo and Simon, Ludovic Courtès writes: > I’m happy to announce the first release of Guix-Jupyter! This looks very good, even though I will probably have to rework my reproducible-research-tutorial-with-guix tutorial now ;-) I haven't looked at this yet in any detail, but I wonder how you

Re: GNU Guix maintainer collective expands

Am 05.10.19 um 14:46 schrieb Ludovic Courtès: Ricardo Wurmus and I are thrilled to announce that Marius Bakke, Maxim Cournoyer, and Tobias Geerinckx-Rice are joining us in maintaining Guix! That's good news and an excellent opportunity to thank everyone working hard on Guix, which means in

Re: Let’s merge ‘core-updates’!

Hi Ludo, Please try to upgrade your system and your user profile to see if anything’s wrong for you (I did that a few days ago and I’m happy!). It mostly works fine for me, except that the build of next-gtk-webkit fails (which works fine on master). The cause is: make[2]: Entering

Re: Updates on the guix home manager

Hi everyone, >> A new "guix home" subcommand, with support for "guix home build" (that >> builds a home configuration), "guix home reconfigure" (that builds and >> ... > > Nice! +1 > Anyway, Guix Home is really cool and it’d be great to provide something > along these lines out-of-the-box with

Re: How to reference external program used in shell-scripts?

Ricardo Wurmus writes: > Hartmut Goebel writes: > >> Anyway: IMHO missing "dynamic binding" is one of the major drawbacks of >> functional deployment, as it requires updating (and esp. downloading) >> much more packages compared to a rpm/deb based system. > > At the same time static binding is

Re: 01/01: services: Add ‘/usr/bin/env’ special file.

Hi Ricardo and everyone else, Using a custom script with a /usr/bin/env shebang is pretty common. You don’t need to be a power user for that, and certainly not a *Guix* power user. I definitely agree with this. In my work environment, it is very common for people to distribute shell or

Re: syslogd can't be started when running Guix in Docker

Ludovic Courtès writes: > Do you observe similar slowness with other Docker images—e.g., Debian > images? No. But I don't observe any slowness with Guix either. Once it's up and running, performance is normal (except for the known problem with access to macOS file systems). It's only the daemon

Re: Increasing the timeout for shepherd services

Hi Ludo, > ‘read-pid-file’ in the Shepherd has a hard-coded default value of 5 > seconds. You can change it for each service, but there’s currently no > way to change the default value globally. That's what I did: change it for each service. > The patch below adds a SRFI-39 parameter in the

Re: syslogd can't be started when running Guix in Docker

Hi Ludo, >> A more fundamental question is whether I will be able to do useful work >> with this setup. It is well known that host file access from Docker on >> macOS is slow, but I didn't realize how slow it is until I compiled Guix >> in... four hours. On the same machine booted to Linux, it's

Re: syslogd can't be started when running Guix in Docker

Maxim Cournoyer writes: > I'm happy to read you could successfully make it work! It's strange > that you had that issue though! By now I have a system that starts all services without failure. I got there by increasing the timeout to 30 s everywhere (compared to the default value of 5). Perhaps

Increasing the timeout for shepherd services

Hi everyone, When running Guix in a docker image, I get systematic failures for starting several services: syslogd, nscd, openssh. It turns out that in all these cases the daemons are started, but so slowly that shepherd declares a failure before they are fully operational. I managed to fix this

Re: syslogd can't be started when running Guix in Docker

On 03/07/2019 10:12, Konrad Hinsen wrote: All this suggests that perhaps the problem is not with syslogd, but with shepherd wrongly concluding that syslogd failed. Looks like I will have to dig a bit more into shepherd :-( My hypothesis turned out to be correct: increasing the timeout

syslogd can't be started when running Guix in Docker

Hi everyone, I am exploring the possibility of running Guix under macOS via Docker. First I ran 'guix system docker-image` on a minimal system configuration, which I then transferred to the Mac and started. Overall it works admirably well. There are however a few services that don't work, in

Re: Down with PYTHONPATH!

Hi Pjotr, > It would be interesting to see how others solve this problem. > Including Nix and Conda. Conda uses the same approach as Python's virtualenv: create a seperate Python installation made up mainly of linke to files shared with other such installations. We could probably do something

Re: Down with PYTHONPATH!

Hi Ludo, > How does virtualenv work, if not by setting PYTHONPATH? It creates a new filetree corresponding to a complete new Python installation, and the uses soft links to share most of the actual files with the parent installation. > Setting up an environment all about augmenting the search

Re: Lightning talk at IPFS camp

Ludovic Courtès writes: > (They could have chosen Guile instead of a custom Lisp, but that’s an > “implementation detail”. :-)) >From my reading of the whitepaper, no. They have pretty strict constraints on their language because they send live code updates to running instances and want to be

Re: Lightning talk at IPFS camp

Ludovic Courtès writes: > Hey! > > I stumbled upon this: > > https://github.com/ipfs/package-managers#readme And I just stumbled on this one: https://github.com/ipfs/roadmap Quote: 2019 Priority We will be focusing our efforts into a single (lazer focus) priority.  Package

Re: Lightning talk at IPFS camp

Pierre Neidhardt writes: >> I was thinking of the Guix package definitions. In the long run, >> assuming IPFS turns out to be reliable enough, we could put all source >> into IPFS with a CID reference, rather then today's many ways to >> download source files. > > There would be nothing special

Re: Lightning talk at IPFS camp

Pierre Neidhardt writes: >> - A unified way to refer to stuff (I am thinking of IPLD here) >> No more tarballs, git commits, etc. CIDs everywhere. > > Do you have a concrete use case? I was thinking of the Guix package definitions. In the long run, assuming IPFS turns out to

Re: Lightning talk at IPFS camp

Am 03.06.19 um 18:19 schrieb Pronaip: - All data comes with provenance tracking: - computations are tracked via Guix - human input is logged (interactivity) or version controlled unless you vision of the distant future somehow also includes most social problems having been

Re: Lightning talk at IPFS camp

Hi Pierre, > I'm going to the IPFS camp (https://camp.ipfs.io/) on June 27th and I've > been asked to give a (5 minute) lightning talk about IPFS & Guix. Yaik! :) That sounds like a great opportunity. Guix and IPFS are in my humble opinion two of the most interesting ongoing projects in the

Re: the upcoming Great Python2 Purge™

Hi Ricardo, >> "My channel" doesn't exist (because I haven't yet found the time to >> figure out how to set up and manage a channel, although it's been on my >> to-do list for a while). > > I’d be happy to assist. Thanks! I might come back to that offer when I find at least enough time to figure

Re: the upcoming Great Python2 Purge™

Hi Ricardo, > Konrad, going forward it might be reasonable to keep copies of required > Python 2 packages in your channel. We aren’t going to remove Python 2 > packages now, but in the future we may not be able to fix unmaintained > packages and may have to remove them. "My channel" doesn't

Re: the upcoming Great Python2 Purge™

Efraim Flashner writes: > I checked 'guix refresh -l python2' and I got a list of the python2-* > packages which are leaf packages. I'm not suggesting that we right now > get rid of them, but it seems to me something worth keeping an eye on. Please be careful with "leaf packages". The leaves of

Re: the upcoming Great Python2 Purge™

On 26/12/2018 10:38, Efraim Flashner wrote: We're now about a year out from the official EOL for python2 (Jan 1, 2020). So far we've been not adding python2 variants of packages that are new unless they're actually needed for something. Do we want to start removing python2 packages when updating

Re: Happy birthday!

On 23/11/2018 14:41, Ludovic Courtès wrote: Today, it’s been six years already! Let's have a party then: (define-public guix-birthday-cake   (package     (name "guix-birthday-cake")     (synopsis "A birthday cake for Guix")     (build-system birthday-cake)     (arguments

Re: Meetup in Paris, Dec. 10th!

Am 11.10.18 um 15:55 schrieb Ludovic Courtès: I’ve booked a room at Inria’s offices in Paris for the Dec. 10 gathering I proposed a while back, see: Great! At what time does it start? A couple of notes: the room capacity is 16 but I’ll look for a larger There's actually plenty of space

Re: Meetup in Paris, Dec. 10th?

Am 27.09.18 um 14:01 schrieb Ludovic Courtès: Some of us will be in Paris, France, for the Reproducible-Build Summit¹, December 11–13. I was wondering if people would be willing to gather, say, the day before the summit (December 10) to discuss Guix things and/or have hack sessions. Who’s in?

Re: Python 2 retirement — what should Guix do?

Leo Famulari writes: > I wonder, what should Guix do? > > Personally, I think our set of Python packages is relatively hard to > maintain. There is a lot of brittle code in there. I'd be happy to drop > our policy that Python libraries have both Python 2 and 3 packages by > default. I expect

Re: “Tarballs, the ultimate container image format”

On 17/05/2018 07:53, Chris Marusich wrote: Great article! Thank you for sharing it. The manual is nice, but I have to admit, I enjoy reading these blog posts quite a bit, too. It's nice to read a brief article that's focused on introducing a specific aspect of Guix, with cross-references for

Re: Dealing with language bindings for libraries.

On 09/05/2018 20:00, Julien Lepiller wrote: We already have such a case: capstone and python-capstone. There is no redundancy since python-capstone knows how to load the shared library created in the capstone package. So we have two packages, with the same My situation is a bit different. The

Re: Dealing with language bindings for libraries.

On 09/05/2018 17:21, Fis Trivial wrote: An ideal scenario would be the one that we can specify multiple outputs for one packages, each output corresponds to one language binding, and we can specify different dependencies and build system for each output. Is there any chance we can do that in

Re: installing python 2 and python 3 in the same profile

Ludovic Courtès writes: > Yes. OTOH we use the “python2-” prefix for 2.x packages and “python-” > for 3.x packages. Indeed. What a mess! >> This does of course raise the question of how this will evolve in the >> long run, but since so many bad decisions were already taken, I am

Re: installing python 2 and python 3 in the same profile

On 14/03/2018 12:39, Hartmut Goebel wrote: Am 13.03.2018 um 22:52 schrieb Ludovic Courtès: 2. Use different package names when we know things can be parallel-installed: “python2” vs. “python” (I’m talking about the package name, not its version string.) That’s what distros

Re: installing python 2 and python 3 in the same profile

Ricardo Wurmus writes: > It is an unnecessary restriction to *prevent* users from installing > Python 2 and 3 interpreters into the same profile. Any errors we see I agree. But the current question is not if we should allow people to shoot themselves into the foot, but how

Re: installing python 2 and python 3 in the same profile

On 10/03/2018 09:34, Pjotr Prins wrote: It still works with ad-hoc environments, but manifests containing both Python versions cannot be instantiated any more. This is too strict, because we know that these two variants don’t cause conflicts. That is not my experience. Any mix is a problem.

Re: Outreachy'18

On 06/03/2018 20:34, Reshu Singh wrote: I am trying to install GUIX for ubuntu using sh script. I have named the script "guix-install.sh".I created the sh file in nano and ran using bash guix-install.sh Encountering an error "guix-install.sh: line 249: /home/reshu/.guix-profile/etc/profile:

Re: Use guix to distribute data & reproducible (data) science

Hi George, myg...@gmail.com writes: >> The three missing pieces are: >> >> - Dealing with measurements, which might involve interacting with >>experimental equipment or databases. Moreover, since data from >>such sources can change, its hash in the store must be computed >>from the

Re: Use guix to distribute data & reproducible (data) science

Hi, > In other words, on the paper, what are the benefits of a management of > some piece of data in the store ? For example for the applications of > weights of a trained neural network; or of the positions of the atoms in > protein structure. Provenance tracking. In a complex data processing

Re: Do you use packages in Guix to run neural networks?

On 14/02/2018 05:43, Fis Trivial wrote: Sorry for bothering with a completely unrelated topic. I'm curious do you train neural network with packages in Guix? Or did you packaged related libraries yourself? My needs are modest, all I use is the multilayer perceptron from scikit-learn, which

Re: Use guix to distribute data & reproducible (data) science

Hi everyone, zimoun writes: > From my point of view, there is 2 kind of datasets: > a- the ones which are part of the software, e.g., used to pass the > tests. Therefore, they are usually small, not always; > b- the ones which are applied to the software and somehow

Why don't "guix pack" and "guix environment" accept manifests?

Hi everyone, Today I tried to convert one of my Guix profiles into a Docker image, and naively tried guix pack -f docker -m my-manifest.scm Now I know it doesn't work, but I wonder if there is a good reason or if this is just not implemented? The same question applies to "guix

Re: Can we speed it up? Prev: compiling guix is too slow?

Pjotr Prins writes: >> I wonder if anyone has analyzed the dependency graphs of software >> packages (not necessarily for Guix, some big distribution like >> Debian would be more interesting), with the goal if identifying good >> splits based on simple criteria. > >

Re: Can we speed it up? Prev: compiling guix is too slow?

On 05/02/2018 08:34, Pjotr Prins wrote: compiled yet). Or generate a meta list for a source tree. Or subcategorize packages so only those packages get included that are asked for (assuming there are no deeper dependencies). For example, few people need the bioinformatics packages. We could have

Re: [RFC] A simple draft for channels

On 24/01/2018 13:33, n...@n0.is wrote: In my honest opinion: No. We can not prevent this. All we can do is to provide a list of *official* channels. Beyond that I don't think we should try to regulate what's in an unofficial channel and what's allowed. +1 The best option in my opinion is to

Re: Building from a local source code checkout

l...@gnu.org (Ludovic Courtès) writes: > I agree the matching-name constraint can be annoying. The alternative > would be allow the user to (optionally?) specify the name of the package > whose source is being changed, as in: > > guix build python-activepapers \ >

Re: Building from a local source code checkout

Hi Carlo, > On 20 December 2017 9:19:00 pm AEDT, Konrad Hinsen > <konrad.hin...@fastmail.net> wrote: >> > guix build python-activepapers >>--with-source=~/Development/python-activepaper >>guix build: error: lstat: No such file or directory: >>"~/

Re: Building from a local source code checkout

Hi Ludo, >> For debugging package definitions, it would be really nice to be able >> to build a package from a checkout of the original project source >> code, rather than having to make a tarball for each modification of >> that source code. Is this possible somehow? > > You should be able to

Building from a local source code checkout

Hi everyone, For debugging package definitions, it would be really nice to be able to build a package from a checkout of the original project source code, rather than having to make a tarball for each modification of that source code. Is this possible somehow? The manual suggests that a

Re: GNU Guix & GuixSD 0.14.0 released

On 07/12/2017 13:45, Ludovic Courtès wrote: We are pleased to announce the release of GNU Guix & GuixSD 0.14.0, representing 5,192 commits by 88 people over 6 months. Congratulations and thanks to all contributors! The more I use Guix, the more I appreciate its qualities, but also the

Re: Changing HTTP proxy settings in GuixSD

Hi Ludo, > I’ll update the ‘guix’ package soon so that this change is available to > daemon-side code such as ‘guix substitute’. In the meantime you can run > the daemon from a checkout: > > sudo -E ./pre-inst-env guix-daemon … That works fine - thanks! Konrad.

Re: Changing HTTP proxy settings in GuixSD

Hi Chris, > That error looks suspicious. Perhaps you already know this, but it > probably means that the string "mirror.hydra.gnu.org" wound up being > used where a procedure should probably have been used instead. For > example, in your Guile REPL, you can reproduce this kind of error like >

Re: Building Docker images of GuixSD

Hi Chris, I've run GuixSD in a Docker container and returned to tell the tale! Congratulations! And thanks for exploring all this. > Is this helpful? Is it worth polishing up and maintaining? I'm not > entirely sure, and I'd like to know what you think. I think it is useful, mainly for

Re: Changing HTTP proxy settings in GuixSD

Hi Ludo, A quick workaround would be to do something along these lines: # herd stop guix-daemon # http_proxy=… guix-daemon --build-users-group=guixbuild # guix system reconfigure config.scm where config.scm has the relevant proxy configuration of in ‘guix-configuration’. Would that

Re: NFS mounts

l...@gnu.org (Ludovic Courtès) writes: >> Of course, the real problem is that I cannot mount it at all because >> rpc.statd is missing. > > Ooh, got it. Well we could (ab)use the ‘dependencies’ field of > ‘file-system’ to introduce a dependency on the rpc.statd daemon startup. Is there a

Re: NFS mounts

Hi Ludo, > By default, file systems are automatically mounted at boot time. To > avoid that, you must add: > > (mount? #f) That works well indeed. But I actually want that NFS filesystem mounted at boot time, ideally (not strictly required though). Of course, the real problem is that I

Re: NFS mounts

Hi Ludo, > Could you test it in a VM, pass “console=ttyS0” as a kernel argument, > and “-serial stdio” so that we see all the messages on the console? It took a while, but here it is. My config.scm is attached as well. Konrad. config.scm Description: Binary data guixsd-console.log

Re: Hacks to install Guix packages without root

On 26/10/2017 23:46, Ricardo Wurmus wrote: How about an extension of “guix pack” that will rewrite the /gnu/store references to a user-provided directory before bundling things up in a tarball? I’d *really* like to be able to just use the tarball bundle “guix pack” produces by default, but

<    1   2   3   >