Re: Greetings
Brett, Brett Gilio wrote: My name is Brett Gilio, I am a research scientist and hobbyist developer coming from Parabola. Welcome! I am trying out GuixSD, and will probably be around in the IRC group and mailing list a bit more. I look forward to engaging with you all. You've probably noticed that #guix operates mostly on European time, although that might be slowly changing. Kind regards, T G-R
Re: Greetings
Welcome! :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: cabal-install fail
Hi Brett, Brett Gilio writes: > Hi, all. I am attempting to install cabal-install to my guix > profile. I > am getting a build error. > > build of > /gnu/store/4rh26abgx8k0vkwsf57n4igp1mcrsfqg-cabal-install-1.22.6.0.drv > failed > > I tried to look at the build log indicated in the error, but it is not > parsing any unicode characters. > > Thoughts? Unfortunately, the package definition for cabal-install is currently non-functional. We are just finishing updating our Haskell packages to build with GHC 8.4.3. These updates fix cabal-install as well. They should be available tomorrow (Monday). (Note that it will be version 2.2 of cabal-install then.) -- Tim
cabal-install fail
Hi, all. I am attempting to install cabal-install to my guix profile. I am getting a build error. build of /gnu/store/4rh26abgx8k0vkwsf57n4igp1mcrsfqg-cabal-install-1.22.6.0.drv failed I tried to look at the build log indicated in the error, but it is not parsing any unicode characters. Thoughts? -- Brett M. Gilio Free Software Foundation, Member https://parabola.nu | https://emacs.org
Greetings
Hi all, My name is Brett Gilio, I am a research scientist and hobbyist developer coming from Parabola. I am trying out GuixSD, and will probably be around in the IRC group and mailing list a bit more. I look forward to engaging with you all. Best -- Brett M. Gilio Free Software Foundation, Member https://parabola.nu | https://emacs.org
Re: GHC 8.4.3
宋文武 writes: > Ricardo Wurmus writes: > >> Ricardo Wurmus writes: >> >>> Ricardo Wurmus writes: >>> Timothy Sample writes: > • There are 21 failing packages. They are agda, beast, corrode, > git-annex, ghc-aws, ghc-gnuplot, ghc-haddock-test, > ghc-hashable-bootstrap, ghc-indents, ghc-monadplus, > ghc-nats-bootstrap, ghc-packedstring, ghc-regex, ghc-regex-tdfa-rc, > ghc-statistics, ghc-vector-builder, ghc-wave, ghc-xmonad-contrib, > raincat, rapicorn, and shellcheck. Raincat is now fixed on wip-haskell. >>> >>> git-annex is also fixed now. >> >> agda is also fixed now. >> >> ghc-regex has had its last release in 2017, so this is an upstream >> problem, I think. ghc-regex-tdfa-rc probably fails just because >> ghc-regex cannot be built. >> >> ghc-monadplus was only needed for agda. I found that version 1.3 builds >> fine, but 1.4.x does not. >> >> ghc-nats-bootstrap builds fine. >> >> ghc-hashable-bootstrap builds fine. >> >> ghc-indents now builds fine (after disabling the tests). >> >> ghc-haddock-test is deprecated and should be removed. >> ghc-packedstring is deprecated and should also be removed. >> >> This leaves ghc-aws, ghc-gnuplot, ghc-statistics, ghc-vector-builder, >> ghc-wave, ghc-xmonad-contrib, and shellcheck. >> >> Any takers? > > Fixed 5, leaving ghc-aws and ghc-statistics (I got test fails for > ghc-happy). Thank you! I just fixed ghc-aws and ghc-statistics. I cannot reproduce the test failure for ghc-happy. I think we’re good to merge this. Any objections? If there are none I’ll merge this branch into master tomorrow. Thank you Tim and 宋文武! -- Ricardo
Re: Blog: Guix packaging tutorial
> ‘%build-inputs’ etc. are global variables of package derivation build > scripts; see ‘build-expression->derivation’ in (guix derivations). > > To view the code of one of these scripts, open the file returned by: > > $ guix gc --references $(guix build -d coreutils) | grep builder > /gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder Nice, I had never looked into the builders before. Good to know :) Maybe we keep the concept of derivations out of this tutorial for now. So I think I'll explain this as "variables global to the package definition". Sounds alright? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: GHC 8.4.3
Hi, Ricardo Wurmus writes: > ghc-regex has had its last release in 2017, so this is an upstream > problem, I think. ghc-regex-tdfa-rc probably fails just because > ghc-regex cannot be built. The impression that I got is that ghc-regex-tdfa-rc was a prerelease package for ghc-regex-tdfa, and that the Haskell community has come to prefer ghc-regex-tdfa over ghc-regex. > This leaves ghc-aws, ghc-gnuplot, ghc-statistics, ghc-vector-builder, > ghc-wave, ghc-xmonad-contrib, and shellcheck. Wow! Nice work. -- Tim
Re: 02/02: services: Add Gitolite.
Christopher Baines skribis:
> Mark H Weaver writes:
[...]
>>> +(define-gexp-compiler (gitolite-rc-file-compiler
>>> + (file ) system target)
>>> + (match file
>>> +(($ umask git-config-keys roles enable)
>>> + (apply text-file* "gitolite.rc"
>>> + `("%RC = (\n"
>>> +"UMASK => " ,(format #f "~4,'0o" umask) ",\n"
[...]
>> --8<---cut here---start->8---
>>0 (simple-format #f "~4,'0o" 63)
>>
>> ERROR: In procedure simple-format:
>> In procedure simple-format: FORMAT: Unsupported format option ~4 - use
>> (ice-9 format) instead
>> --8<---cut here---end--->8---
[...]
> It sounds to me like adding #:use-modules (ice-9 format) to (gnu
> services version-control) would fix this, but I'll wait until I can
> reproduce the failure before re-adding the service.
Yes, adding #:use-module (ice-9 format) will fix the problem.
You should be able to reproduce it by running “make hydra-jobs”.
As to why you can’t necessarily reproduce it… It turns out that loading
(ice-9 format) has the effect of set!ting the global ‘format’ binding.
So if some unrelated piece of code loads (ice-9 format), you don’t have
any problems; but if that doesn’t happen, you get the error.
This terrible behavior has been in Guile forever and nobody has dared
changing it so far. :-) The -Wformat warning tries hard to diagnose
the issue though.
HTH!
Ludo’.
Re: SeaGL 2018 Accepts Guix-Themed Talk: "Everyday Use of GNU Guix"
Hi Chris, Chris Marusich skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> I think a title, abstract, and link to the SeaGL web site would be >> enough. It’d be great if you could commit this to guix-artwork.git, and >> then I can take care of putting it on line. > > Sounds good! I've committed an announcement in commit > bfe3af6a197f0f7363f444ea79ea63e5af6f6e39 in guix-artwork.git. Please > check it and, if it looks good to you, publish it. Done! https://www.gnu.org/software/guix/blog/2018/upcoming-talk-everyday-use-of-gnu-guix/ > Thank you for offering to announce my talk on the blog! I hope we can > get more people interested in Guix in the Seattle area. I know some > people who use Nix or NixOS, but so far I haven't met anyone who's heard > of Guix. I aim to change that! Heheh, I wish you success! :-) Ludo’.
Re: Blog: Guix packaging tutorial
Hello, Pierre Neidhardt skribis: > l...@gnu.org (Ludovic Courtès) writes: >> I’m not sure what you mean by “generated in scope”. >> >> The ‘%’ convention is just a convention (and Andy and I realized a while >> back we interpreted the convention differently :-)) so we shouldn’t draw >> too much from that. >> >> Regarding ‘%build-inputs’ and ‘%outputs’, I think it’s enough to say >> that these are global variables. Whether they are in scope depends on >> whether a local variable shadows them. >> >> Does that make sense? > > I borrowed the expression "generated in scope" from Pjotr's > https://gitlab.com/pjotrp/guix-notes/blob/master/HACKING.org. > > Are they really "global" variables? My (quick) understanding from > derivations.scm is that the %-prefixed variables are defined at > derivation-time. I think it's important to make this explicit. What do you > think? ‘%build-inputs’ etc. are global variables of package derivation build scripts; see ‘build-expression->derivation’ in (guix derivations). To view the code of one of these scripts, open the file returned by: $ guix gc --references $(guix build -d coreutils) | grep builder /gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder > l...@gnu.org (Ludovic Courtès) writes: >> When would you like it to be on line? > > Well, as soon as possible :) Monday 1st, maybe? Alright, let’s see how far we go; I’ll be AFK most of the day tomorrow though, so it might have to be on Tuesday. Thanks, Ludo’.
Re: 02/02: services: Add Gitolite.
Hi Christopher,
Christopher Baines writes:
> Mark H Weaver writes:
>
>> m...@cbaines.net (Christopher Baines) writes:
>>
>>> cbaines pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit 258a6d944ed891fa92fa87a16731e5dfe0bac477
>>> Author: Christopher Baines
>>> Date: Fri Jul 13 20:39:46 2018 +0100
>>>
>>> services: Add Gitolite.
>>>
>>> * gnu/services/version-control.scm (,
>>> ): New record types.
>>> (gitolite-accounts, gitolite-activation): New procedures.
>>> (gitolite-service-type): New variables.
>>> * gnu/tests/version-control.scm (%gitolite-test-admin-keypair,
>>> %gitolite-os,
>>> %test-gitolite): New variables.
>>> (run-gitolite-test): New procedure.
>>> * doc/guix.texi (Version Control): Document the gitolite service.
>>
>> This commit has a flaw which broke evaluations on Hydra, so I reverted
>> it for now.
>>
>>> +(define-gexp-compiler (gitolite-rc-file-compiler
>>> + (file ) system target)
>>> + (match file
>>> +(($ umask git-config-keys roles enable)
>>> + (apply text-file* "gitolite.rc"
>>> + `("%RC = (\n"
>>> +"UMASK => " ,(format #f "~4,'0o" umask) ",\n"
>>
>> The problem is here, in the call to 'format'. Guile has two variants of
>> the 'format' procedure: a very simple one which is always available
>> (also known as 'simple-format'), and a much more complex and featureful
>> variant in (ice-9 format). In the code above, you are assuming that
>> (ice-9 format) has been loaded, but you have not arranged for that to
>> happen. During the Hydra evaluation, this led to the following error:
>>
>> --8<---cut here---start->8---
>>0 (simple-format #f "~4,'0o" 63)
>>
>> ERROR: In procedure simple-format:
>> In procedure simple-format: FORMAT: Unsupported format option ~4 - use
>> (ice-9 format) instead
>> --8<---cut here---end--->8---
>
> Thanks for looking at this Mark, do you know where I can find out what
> Hydra is doing when it encounters this error? I tried looking around the
> web interface, but the latest evaluation I could find was from 2017
> apparently.
Hydra's web interface is the wrong place to look for information on
this problem.
I guess the error happens when Hydra tries to create a derivation for
the system test '%test-gitolite'.
The relevant code that Hydra runs to generate an evaluation is in
build-aux/hydra/gnu-system.scm. Specifically, 'system-test-jobs', which
calls (all-system-tests) from gnu/tests.scm, which looks for public
variables bound to 'system-test' records. That includes
'%test-gitolite'.
>> I guess that the fix will involve 'with-imported-modules'. Could you
>> take a look?
>
> Sure. The confusing thing to me here is that this code works when using
> the service, including the system test (at least when I run it
> locally). Also, as far as I understand, even though the code is within a
> gexp-compiler, it doesn't even involve the store, as the call to format
> happens before the g-expression is generated.
>
> It sounds to me like adding #:use-modules (ice-9 format) to (gnu
> services version-control) would fix this, but I'll wait until I can
> reproduce the failure before re-adding the service.
I'm not yet sufficiently familiar with gexp compilation to know where
the call to 'format' is ultimately being executed, and I don't have time
right now to investigate further, so I hoping that Ludovic can chime in
here with a definitive answer on how to fix this properly.
Mark
Re: Blog: Guix packaging tutorial
l...@gnu.org (Ludovic Courtès) writes: > I’m not sure what you mean by “generated in scope”. > > The ‘%’ convention is just a convention (and Andy and I realized a while > back we interpreted the convention differently :-)) so we shouldn’t draw > too much from that. > > Regarding ‘%build-inputs’ and ‘%outputs’, I think it’s enough to say > that these are global variables. Whether they are in scope depends on > whether a local variable shadows them. > > Does that make sense? I borrowed the expression "generated in scope" from Pjotr's https://gitlab.com/pjotrp/guix-notes/blob/master/HACKING.org. Are they really "global" variables? My (quick) understanding from derivations.scm is that the %-prefixed variables are defined at derivation-time. I think it's important to make this explicit. What do you think? l...@gnu.org (Ludovic Courtès) writes: > Another option is to skip propagated inputs altogether. I think it's important to highlight the distinction between the three kinds of inputs. When I got started, I was tempted to use propagated-inputs all the way. The distinction is very Guix-specific (Nix?) and is one of the lesser known strength of Guix in my opinion. l...@gnu.org (Ludovic Courtès) writes: > When would you like it to be on line? Well, as soon as possible :) Monday 1st, maybe? Ricardo Wurmus writes: > I wonder if a complicated example like that really has a place in a > tutorial. To me it seems a bit scary. I image people who are used to > Conda to browse the tutorial and recoil in horror at seeing a > complicated example with all sorts of customizations. In my opinion the "my-mg" example is not so long, although I could probably remove some phase code because they don't add much to the tutorial. But for the rest of it, it's rather widespread, idiomatic code. I don't think we can afford to remove much of it lest we make this tutorial useless for any serious work. Is there any specific element you'd like to cut off? Also consider that the first part of this tutorial focuses on a hello-world example that puts emphasis and getting an example up and running as soon as possible. What about splitting this tutorial in two separate blog entries and leaving the advanced example for the second one? Ricardo Wurmus writes: > FWIW, I think that maybe we should avoid quasi-quotation in the > tutorial, or at least at this point. It could be a little overwhelming > to be introduced to so many new concepts at once before seeing how they > might be useful. I am not sure about this. On the one hand, it adds some complexity especially to users unfamiliar with Lisp. On the other hand, quasi-quotes are all over the place. Ricardo Wurmus writes: > Maybe this could be interleaved and motivated by packaging features. > For example, at the very beginning we define a package and then evaluate > it at the end so that we can use it with “guix package -f”. Maybe it > would be better to avoid defining things and using the plain “package” > form. It would be more structured (and thus clearer), but it could also make the tutorial a few lines longer... I'll see if I can manage without adding too much. Ricardo Wurmus writes: > (I need to go now, but if you want I can comment on the next sections > tomorrow.) Please do! :) Ludovic, Ricardo, I've taken all your other considerations into account. Thanks a lot for your time reviewing this! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Web interface review 2
Hello Tatiana! I rebased your branch and did the changes I talked about, along with a few minor things like error handling and cosmetic changes. The result is available there: https://cuirass.lassieur.org/ and the code is available there: https://git.lassieur.org/cgit/cuirass.git/. I plan to push everything tomorrow evening (with https://bugs.gnu.org/32879) if nobody objects. Cheers, Clément
Re: GHC 8.4.3
Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> Ricardo Wurmus writes: >> >>> Timothy Sample writes: >>> • There are 21 failing packages. They are agda, beast, corrode, git-annex, ghc-aws, ghc-gnuplot, ghc-haddock-test, ghc-hashable-bootstrap, ghc-indents, ghc-monadplus, ghc-nats-bootstrap, ghc-packedstring, ghc-regex, ghc-regex-tdfa-rc, ghc-statistics, ghc-vector-builder, ghc-wave, ghc-xmonad-contrib, raincat, rapicorn, and shellcheck. >>> >>> Raincat is now fixed on wip-haskell. >> >> git-annex is also fixed now. > > agda is also fixed now. > > ghc-regex has had its last release in 2017, so this is an upstream > problem, I think. ghc-regex-tdfa-rc probably fails just because > ghc-regex cannot be built. > > ghc-monadplus was only needed for agda. I found that version 1.3 builds > fine, but 1.4.x does not. > > ghc-nats-bootstrap builds fine. > > ghc-hashable-bootstrap builds fine. > > ghc-indents now builds fine (after disabling the tests). > > ghc-haddock-test is deprecated and should be removed. > ghc-packedstring is deprecated and should also be removed. > > This leaves ghc-aws, ghc-gnuplot, ghc-statistics, ghc-vector-builder, > ghc-wave, ghc-xmonad-contrib, and shellcheck. > > Any takers? Fixed 5, leaving ghc-aws and ghc-statistics (I got test fails for ghc-happy).
Re: GHC 8.4.3
Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> Timothy Sample writes: >> >>> • There are 21 failing packages. They are agda, beast, corrode, >>> git-annex, ghc-aws, ghc-gnuplot, ghc-haddock-test, >>> ghc-hashable-bootstrap, ghc-indents, ghc-monadplus, >>> ghc-nats-bootstrap, ghc-packedstring, ghc-regex, ghc-regex-tdfa-rc, >>> ghc-statistics, ghc-vector-builder, ghc-wave, ghc-xmonad-contrib, >>> raincat, rapicorn, and shellcheck. >> >> Raincat is now fixed on wip-haskell. > > git-annex is also fixed now. agda is also fixed now. ghc-regex has had its last release in 2017, so this is an upstream problem, I think. ghc-regex-tdfa-rc probably fails just because ghc-regex cannot be built. ghc-monadplus was only needed for agda. I found that version 1.3 builds fine, but 1.4.x does not. ghc-nats-bootstrap builds fine. ghc-hashable-bootstrap builds fine. ghc-indents now builds fine (after disabling the tests). ghc-haddock-test is deprecated and should be removed. ghc-packedstring is deprecated and should also be removed. This leaves ghc-aws, ghc-gnuplot, ghc-statistics, ghc-vector-builder, ghc-wave, ghc-xmonad-contrib, and shellcheck. Any takers? -- Ricardo
Re: 02/02: services: Add Gitolite.
Mark H Weaver writes:
> Hi Christopher,
>
> m...@cbaines.net (Christopher Baines) writes:
>
>> cbaines pushed a commit to branch master
>> in repository guix.
>>
>> commit 258a6d944ed891fa92fa87a16731e5dfe0bac477
>> Author: Christopher Baines
>> Date: Fri Jul 13 20:39:46 2018 +0100
>>
>> services: Add Gitolite.
>>
>> * gnu/services/version-control.scm (,
>> ): New record types.
>> (gitolite-accounts, gitolite-activation): New procedures.
>> (gitolite-service-type): New variables.
>> * gnu/tests/version-control.scm (%gitolite-test-admin-keypair,
>> %gitolite-os,
>> %test-gitolite): New variables.
>> (run-gitolite-test): New procedure.
>> * doc/guix.texi (Version Control): Document the gitolite service.
>
> This commit has a flaw which broke evaluations on Hydra, so I reverted
> it for now.
>
>> +(define-gexp-compiler (gitolite-rc-file-compiler
>> + (file ) system target)
>> + (match file
>> +(($ umask git-config-keys roles enable)
>> + (apply text-file* "gitolite.rc"
>> + `("%RC = (\n"
>> +"UMASK => " ,(format #f "~4,'0o" umask) ",\n"
>
> The problem is here, in the call to 'format'. Guile has two variants of
> the 'format' procedure: a very simple one which is always available
> (also known as 'simple-format'), and a much more complex and featureful
> variant in (ice-9 format). In the code above, you are assuming that
> (ice-9 format) has been loaded, but you have not arranged for that to
> happen. During the Hydra evaluation, this led to the following error:
>
> --8<---cut here---start->8---
>0 (simple-format #f "~4,'0o" 63)
>
> ERROR: In procedure simple-format:
> In procedure simple-format: FORMAT: Unsupported format option ~4 - use (ice-9
> format) instead
> --8<---cut here---end--->8---
Thanks for looking at this Mark, do you know where I can find out what
Hydra is doing when it encounters this error? I tried looking around the
web interface, but the latest evaluation I could find was from 2017
apparently.
> I guess that the fix will involve 'with-imported-modules'.
> Could you take a look?
Sure. The confusing thing to me here is that this code works when using
the service, including the system test (at least when I run it
locally). Also, as far as I understand, even though the code is within a
gexp-compiler, it doesn't even involve the store, as the call to format
happens before the g-expression is generated.
It sounds to me like adding #:use-modules (ice-9 format) to (gnu
services version-control) would fix this, but I'll wait until I can
reproduce the failure before re-adding the service.
Thanks,
Chris
signature.asc
Description: PGP signature
Re: GHC 8.4.3
Ricardo Wurmus writes: > Timothy Sample writes: > >> • There are 21 failing packages. They are agda, beast, corrode, >> git-annex, ghc-aws, ghc-gnuplot, ghc-haddock-test, >> ghc-hashable-bootstrap, ghc-indents, ghc-monadplus, >> ghc-nats-bootstrap, ghc-packedstring, ghc-regex, ghc-regex-tdfa-rc, >> ghc-statistics, ghc-vector-builder, ghc-wave, ghc-xmonad-contrib, >> raincat, rapicorn, and shellcheck. > > Raincat is now fixed on wip-haskell. git-annex is also fixed now. -- Ricardo
