Re: Setting up on NixOS
Hi, just pitching in to say: I did exactly this (enable guix from NixOS) and can confirm it appears to work. However, it's only on the latest stable channel (23.11). If you're on an old channel, you'll need to upgrade. You can find instructions for how to do so in the NixOS docs, or here: https://unix.stackexchange.com/questions/491727/how-do-i-upgrade-nixos-to-use-a-new-channel-nixos-version Best wishes, Dan On Mon, Mar 25, 2024 at 9:41 PM pukkamustard wrote: > > > Hi! > > I think the problems you are encountering must have something to do with > build-users not being setup properly. > > But maybe a easier way of getting Guix on NixOS is to just enable it! > > Afaik putting > > ``` > services.guix.enable = true > ``` > > in your NixOS system configuration is all you need (see > https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/misc/guix/default.nix). > > -pukkamustard > > Marc Coquand writes: > > > Hi, > > > > I'm having trouble to run Guix on NixOS. I followed the default > > installation binary, and then started the guix-daemon with > > > >> sudo guix-daemon > > > > It seems to run without fail: > > > >> ~ sudo guix-daemon > >> [sudo] password for marc: > >> warning: daemon is running as root, so using `--build-users-group' is > >> highly recommended > >> accepted connection from pid 55185, user marc > > > > Afterward, In a separate terminal I try to run guix pull: > > > >> ~ guix pull Updating channel 'guix' from Git repository at > >> 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel > >> 'guix', commits 9edb3f6 to 929ddec (21 new commits)... Building from > >> this channel: guix https://git.savannah.gnu.org/git/guix.git 929ddec > >> substitute: guix substitute: warning: ACL for archive imports seems to > >> be uninitialized, substitutes may be unavailable substitute: updating > >> substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: > >> updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% > >> substitute: updating substitutes from > >> 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes > >> from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating > >> substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: > >> updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% > >> building > >> /gnu/store/4xrbn6wh5m1rpj03zcxb224yzg7nf708-autoconf-2.69.tar.xz.drv... > >> \builder for > >> `/gnu/store/4xrbn6wh5m1rpj03zcxb224yzg7nf708-autoconf-2.69.tar.xz.drv' > >> failed with exit code 1 build of > >> /gnu/store/4xrbn6wh5m1rpj03zcxb224yzg7nf708-autoconf-2.69.tar.xz.drv > >> failed View build log at > >> '/var/log/guix/drvs/4x/rbn6wh5m1rpj03zcxb224yzg7nf708-autoconf-2.69.tar.xz.drv.gz'. > >> building > >> /gnu/store/br3cg4l213f3frzsynvd8p4qx9v0wxsg-CUnit-2.1-3.tar.bz2.drv... > >> cannot build derivation > >> `/gnu/store/rqpsl8zg5akw61jg82fgl8y01l91s5yp-autoconf-2.69.drv': 1 > >> dependencies couldn't be built cannot build derivation > >> `/gnu/store/mmvk8r4xl3ylq1c44mj4pwk371fnvl0d-autoconf-wrapper-2.69.drv': > > > > > >> 1 dependencies couldn't be built killing process 55220 building > >> /gnu/store/97z4gi6qvqld54c9q5l6bkj33x997c0f-Python-3.5.9.tar.xz.drv... > >> cannot build derivation > >> `/gnu/store/1xh5b299d09nrpgjpwa0wxpz0fs83d7p-guile-gcrypt-0.3.0.drv': 1 > >> dependencies couldn't be built killing process 55221 cannot build > >> derivation > >> `/gnu/store/n3bisdsq2xnkcnmhf972k3gmqpnzv0ng-compute-guix-derivation.drv': > >> 1 dependencies couldn't be built guix pull: error: build of > >> `/gnu/store/n3bisdsq2xnkcnmhf972k3gmqpnzv0ng-compute-guix-derivation.drv' > >> failed > > > > Any clue what I am missing? > > > > Thank you so much in advance, > > Marc > >
Re: You're invited to the first patch review session!
HI, just to clear up the timezone issue a bit - I think the ical file higher up is *not* correct: * I think the meeting is at 18:00 UTC, which is the same as 18:00 GMT, which is the same (on March 7th) as 18:00 London time * I think the libreplanet page says 18:00 BST, which is 17:00 UTC/GMT and is not an inhabited time zone on March 7th (the switch to BST is on 31 March). I think the ical file reflects 17:00 UTC. I'm mostly sending this message to make sure *I'm* not misunderstanding, as I don't want to miss it :-) Meetup also says 18:00 GMT. Dan
Re: Guix Days: Patch flow discussion
Hi! I'm a complete newbie to Guix, which has the dual effects that I'm much more excited about it than I otherwise might be, but the disadvantage that I know nothing and am more likely to cause problems than not at the moment. Nevertheless I thought I might be able to contribute something to the discussion. Something that is not obvious to me when people refer to reviewing patches, is whether this is purely a matter of adding new packages to the main guix channel, or of reviewing changes to the system in general, or both. As a novice, I can imagine becoming comfortable as a package reviewer much more quickly than as a reviewer of core patches to the system. It's also not obvious to me whether you mean exactly "reviewing a backlog of existing patches" or additionally "increasing the amount of patches submitted and applied". I feel like both are probably good things but I can't tell what you're focussing on exactly. If lots of gems were imported from other repos like RubyGems and PyPi, which as I understand it is currently a partly-automatic partly-manual process, would that be considered a win? What about increasing version coverage among those packages that are covered? One point brought up here is about tooling. I wonder whether there is any scope for fully automatic review. In other words, for some classes of package we might be able to say that if it builds in CI, and maybe the built package has a command that's considered enough to say "it's working", then that's all the review that's needed. I guess I'm mostly thinking here of cases where the package is imported, partially or entirely automatically, from another repo (as with `guix import`). So one could argue that as long as it looks like "the rubygems import is working" then the guix package thus imported can be assumed to be working too. I guess when I say this I am still mostly thinking of importing entire histories of a package (lots of versions simultaneously) without multiplying out the work involved to a huge degree. One of the points brought up earlier is whether it would be better to have interactive "review parties" or comprehensive documentation about what constitutes a good review. Obviously these are not mutually exclusive. But for my part, I think documentation gives you more "bang for your buck", for a few reasons: 1. Documentation is online all the time, whereas interactive sessions are subject to people's work schedules, time zones, personal commitments, etc. 2. Documentation is more likely to be complete, and to become more likely to be complete over time, whereas in meetings (or when doing your first solo review following the meeting) it is easy to forget some steps or criteria to check. 3. Reading docs can be done by anyone, with no commitment to follow up. I think some people are just scared off socially by the idea of having to join a meeting in order to learn how to do reviews well. Obviously this is a personal thing and varies - some people find a welcoming atmosphere in a virtual meeting much better than a faceless documentation screen. For my part I think I would prefer to read until I know the basics, and then might prefer to do it alongside other people. A "patch party" would not convert me from non-contributor to contributor, but it might convert me from a seldom-contributor to an active one. Again, there is obviously variation here among people. In case it is not obvious, I have only recently joined guix-devel, but would be keen to help out if I can. If there are things I can read to get "up to speed" that would be really helpful! All the best, Dan
Turning Gemfile.lock into a guix environment
Hi everyone, I'm trying to figure out how to convert a Ruby project
from using bundler to using guix directly, so I can sidestep
rvm/rbenv/bundle.
I found two articles about this, but neither seems to go into the
detail of pinning versions to get a really reproducible environment.
They just provide ideas.
1. RUBY.org guix notes by pjotr:
https://github.com/pjotrp/guix-notes/blob/master/RUBY.org
2. Ruby on Guix article by David Thompson:
https://dthompson.us/posts/ruby-on-guix.html
Anyway, I wanted to share a small ruby script I wrote which will parse
your Gemfile.lock file and shell out to call `guix import gem` with
the version specified in your lockfile. I'm actually stuck here,
because I don't know how to build a guix package definition out of
these snippets.
```ruby
#!/usr/bin/env ruby
require 'bundler'
parser = Bundler::LockfileParser.new(File.read(ARGV[0]))
ruby_gems = parser.specs.select { |s| spec.is_a?(Bundler::Source::Rubygems) }
ruby_gems.each { |g| puts %x(guix import gem #{g.name}@#{g.version}) }
```
Usage: ./gemfile_import.rb Gemfile.lock
this worked for me with a gemfile.lock of a few hundred specs.
Obviously the resulting package definition will be pretty big, but I
assume that's okay. I'm particularly hoping to script the import so
that I can use guix at work in parallel with my colleagues on other
systems who prefer to use bundler. I don't know how updating gems
would work yet in this setup.
I wonder a) whether anybody else cares about this problem and b)
whether anybody has any advice for building the final package
definition? I will keep looking through the docs, but I am quite new
to guix and haven't built my own package definition before.
All the best,
Dan
Re: share guix and its store between distributions
Hi Emmanuel, Do you expect to share exactly the same packages in Debian vs guix, or just an overlapping subset? I assume that if the packages are the same, and they're building the same versions, then the hash identifying them should be the same, and guix should refrain from rebuilding the package (and simply set up the link to the store). If they aren't the same, then you have to make sure the system A does not clean up any packages used by system B and not system A. I guess this is why you mention GC roots. My gut feeling is that that will be a lot more complicated, because you have to trick guix into getting its garbage collection "wrong". Perhaps you could keep the two stores separate, but mount them as a union file system? So system A would mount system B's store into its own, read-only. System B would be able to build additional packages not found in A, but could not clean up system A's packages. I don't know how guix would react to such a permission error. I think it expects to be the only master of the store. All the best, Dan On Thu, Oct 5, 2023 at 4:04 PM Emmanuel Beffara wrote: > > Hello Guix, > > Is there a way to share Guix and its store between several distributions? > > My situation is that I have a Guix system installed as my main system, but I > would like to install another distribution on the same machine (a current > Debian, specifically) and use Guix as a package manager there, in order to > benefit from its ability to create reproducible environments. > > Of course, it works to have the other distribution completely independent, > with its own Guix store. The only thing is to handle Grub correctly to give > access to both distros. But it feels like a significant waste of resources, > since I will end up having many things in both stores. > > Moreover, ideally I would like to share home directories between the two > distributions, by mounting the same partition as /home, and still be able to > use `guix home` and `guix shell` in both distributions. By some minimal > tuning, I can make it so that users have the same UIDs and GIDs in both > distributions. But I imagine that using Guix in both distributions can become > problematic if they don't share the store and the state in `/var/guix`, for > instance if they don't share GC roots. > > Is there a proper way to make that work? Or is it a bad idea? > > -- > Emmanuel >
Re: Development shell for diffutils does not appear to work - what am I doing wrong?
Hi wolf, I have now tried that, and I was able to build from the tarball and test my local changes. Indeed, I was confused previously - I always assumed that the release tarball was a binary; I had no idea there was a distinction between "building from VCS" and "building from the archive". Thank you for explaining! I think that's fixed now, thanks everyone. Dan On Wed, Sep 27, 2023 at 5:25 PM wolf wrote: > > On 2023-09-27 11:58:32 +0100, Daniel Littlewood wrote: > > Hi Ekaitz, thanks for you reply! > > > > Reading the docs a second time, I think I did misunderstand the > > --development argument. The docs say > > > Cause guix shell to include in the environment the dependencies of the > > > following package rather than the package itself. > > and I took "dependencies" to mean "build dependencies". But perhaps it > > just means the runtime ones? > > So as you say, you could download the release tarball of diffutils and > > be able to run it, but not necessarily to build it from the source. > > I wonder why the flag is called "development" when it doesn't allow > > you to develop the package. > > I think your confusion here stems from not understanding how (not only, not > all) > GNU project in general operate as far as release management goes. Most GNU > project do provide something called release tarball, which is an archive > intended for consumption by distributions/end-users. This archive is (for > autotools projects) created by running `make dist'. This is the archive > distributions (including Guix) use for building the package. > > The advantage of the archive is that it contains some already generated files. > For example, when building the archive, you usually start by running > `./configure', since that file is provided as part of the archive. When > building from VCS, you usually start with some variant of `./bootstrap'. > > The implication (and source of your problem) is that less software is required > for the build from the archive compared to the VCS. And that is a good thing! > For example autotools can be sensitive quite a bit to the version (you need to > have the correct one). However the generated configure script is insanely > portable, so you can (for example) build the project even on distributions > that > do not package autotools 2.69 anymore. > > So if you download the archive, and use the -D, you will be able to build it. > However, for VCS checkout you need to provide the additional packages yourself > (as you already figured out). > > Hope this sheds some light on the cause. > > > Perhaps it refers to developing guix? > > > > I did exactly as you suggest yesterday and did manage to find all the > > dependencies (although I didn't manage to build it in the end, but I > > don't know the root cause yet). In fact the very next documented > > config option looks like it may be able to build autotools. They give > > an example for including the base packages: > > guix shell -e '(@ (gnu) %base-packages)' > > Perhaps there is a similar expression for importing everything in a > > specific build system? > > > > Since I was mixed up between building and installing, I also wonder > > whether this is what `guix build` is for. Or, equally, if I copy the > > definition of diffutils in base.scm and then do `guix shell -f > > my-diffutils.scm` maybe it will build itself? It certainly seems to > > have all the necessary information to do so. > > > > I'll test those options later, thanks! > > Dan > > > > On Wed, Sep 27, 2023 at 11:08 AM Ekaitz Zarraga wrote: > > > > > > > > > > > > > > > > > > ElenQ Technology > > > > > > > > > --- Original Message --- > > > On Tuesday, September 26th, 2023 at 08:08, Daniel Littlewood > > > wrote: > > > > > > > > > > Hi guix help, > > > > > > > > I want to try out making a simple change to the program `diff`, which > > > > is part of GNU diffutils: > > > > https://packages.guix.gnu.org/packages/diffutils/3.8/ > > > > I'd like to set up a dev environment, patch diff.c, rebuild it and try > > > > out the new binary. Maybe install it globally later, but I'm not there > > > > yet. > > > > I cloned the diffutils repo from > > > > https://git.savannah.gnu.org/git/diffutils.git, and in that directory > > > > ran > > > > `guix shell git vim nnn -D diffutils` (but I think it's just the -D > > > > diffutils I'm having trouble with).
Re: Development shell for diffutils does not appear to work - what am I doing wrong?
Hi Ekaitz, thanks for you reply! Reading the docs a second time, I think I did misunderstand the --development argument. The docs say > Cause guix shell to include in the environment the dependencies of the > following package rather than the package itself. and I took "dependencies" to mean "build dependencies". But perhaps it just means the runtime ones? So as you say, you could download the release tarball of diffutils and be able to run it, but not necessarily to build it from the source. I wonder why the flag is called "development" when it doesn't allow you to develop the package. Perhaps it refers to developing guix? I did exactly as you suggest yesterday and did manage to find all the dependencies (although I didn't manage to build it in the end, but I don't know the root cause yet). In fact the very next documented config option looks like it may be able to build autotools. They give an example for including the base packages: guix shell -e '(@ (gnu) %base-packages)' Perhaps there is a similar expression for importing everything in a specific build system? Since I was mixed up between building and installing, I also wonder whether this is what `guix build` is for. Or, equally, if I copy the definition of diffutils in base.scm and then do `guix shell -f my-diffutils.scm` maybe it will build itself? It certainly seems to have all the necessary information to do so. I'll test those options later, thanks! Dan On Wed, Sep 27, 2023 at 11:08 AM Ekaitz Zarraga wrote: > > > > > > ElenQ Technology > > > --- Original Message --- > On Tuesday, September 26th, 2023 at 08:08, Daniel Littlewood > wrote: > > > > Hi guix help, > > > > I want to try out making a simple change to the program `diff`, which > > is part of GNU diffutils: > > https://packages.guix.gnu.org/packages/diffutils/3.8/ > > I'd like to set up a dev environment, patch diff.c, rebuild it and try > > out the new binary. Maybe install it globally later, but I'm not there > > yet. > > I cloned the diffutils repo from > > https://git.savannah.gnu.org/git/diffutils.git, and in that directory > > ran > > `guix shell git vim nnn -D diffutils` (but I think it's just the -D > > diffutils I'm having trouble with). I believe that the > > -D/--development argument should produce a shell within which I can > > build `diff`. > > The README says that the first step is to run `./bootstrap`, but that > > fails because of several missing packages. I don't have the full list > > right now, but I think autoconf was one, and texi2pdf was another. > > > > The packaging for diffutils clearly works (since I can install it), so > > I wonder if it does something different from what I'm attempting? I > > couldn't find the scheme file that defines diffutils, but I'm not sure > > I'd be able to read it anyway (I'm really trying out guix for the > > first time). > > > > Thanks for reading, please let me know if I can provide more info. > > Dan > > > > Dan, > > I don't think you are doing anything wrong. I don't know why but > when doing `-D package` guix is often not adding all the development > dependencies as it doesn't load autotools and related things to > the shell. > > You have to add them by hand. > > Also, diffutils downloads a tar.xz which probably has the bootstrap > step already done because it is considered a release source code. > > You are working from development code I expect, which probably needs > some extra tools. > > What I would do: go adding them to the shell one by one as the build > system complains until it doesn't complain anymore. They will > probably be `texinfo`, `automake`, `autoconf`, `libtool` and maybe > I'm missing something... If you add them as you go you shouldn't > leave anything out. > > Also, this is an interesting call. It might be cool to have a way to > add those directly... I don't know what is best but probably with > some kind of flag we should add all the deps from the build-system > too. > And also, have all the `autotools` in just one package because I > always forget some of them. > > I may start another thread with that... > > Thanks for your question, it is a very valid one! It happened to me > before, too, and it's pretty annoying. > > Hope this helps, > Ekaitz
Development shell for diffutils does not appear to work - what am I doing wrong?
Hi guix help, I want to try out making a simple change to the program `diff`, which is part of GNU diffutils: https://packages.guix.gnu.org/packages/diffutils/3.8/ I'd like to set up a dev environment, patch diff.c, rebuild it and try out the new binary. Maybe install it globally later, but I'm not there yet. I cloned the diffutils repo from https://git.savannah.gnu.org/git/diffutils.git, and in that directory ran `guix shell git vim nnn -D diffutils` (but I think it's just the -D diffutils I'm having trouble with). I believe that the -D/--development argument should produce a shell within which I can build `diff`. The README says that the first step is to run `./bootstrap`, but that fails because of several missing packages. I don't have the full list right now, but I think autoconf was one, and texi2pdf was another. The packaging for diffutils clearly works (since I can install it), so I wonder if it does something different from what I'm attempting? I couldn't find the scheme file that defines diffutils, but I'm not sure I'd be able to read it anyway (I'm really trying out guix for the first time). Thanks for reading, please let me know if I can provide more info. Dan
