bug#38946: guix import fails for cabal-helper

It appears that the guix cabal parser (in guix/import/cabal.scm) isn’t aware of `common` stanzas. https://www.haskell.org/cabal/users-guide/developing-packages.html#pkg-section-common-common Note that there’s quite a few issues with the cabal parser, and the format is pretty baroque, to the

bug#39051: nginx caching headers are broken due to epoch store timestamps

I don’t see anything here: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix;include=subject%3Anginx > On 9. Jan 2020, at 12:00, Gábor Boskovits wrote: > > Hello, > > Robert Vollmert ezt írta (időpont: 2020. jan. 9., Cs, > 11:54): >> >> I’ve been havin

bug#39051: nginx caching headers are broken due to epoch store timestamps

I’ve been having hard-to-debug caching issues serving up static files with nginx. It turns out this is due to nginx computing e-tag headers from file timestamps, which are all epoch in the guix store. I’ve fixed this on my server by applying a patch from Nix:

bug#38471: meta: I don't receive follow-ups to bug reports I submitted

I remarked on this before: https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00315.html It seems that I don’t get follow-up emails to bug reports I submitted unless people explicitly put me in CC (presumably by reply to all in the original email thread). I’ve failed to answer follow-up

bug#38469: guix gc should keep around recent intermediate build

> Have you tried passing the options '--gc-keep-derivations=yes’ and > '--gc-keep-outputs=yes' to guix-daemon? I had not. I added that right now, and first tests seem to indicate that this helps. Thanks! Would it be a bad idea to make this the default? Alternatively, how about some kind of

bug#38469: guix gc should keep around recent intermediate build ingredients by default

[ This is a user/developer friendliness feature request. I’m not arguing that `guix gc` should do anything differently on a technical level, I’m just trying to argue that the default experience should be different. ] Current situation: I use a forked guix repository as my default channel,

bug#38444: sshd / login segmentation faults

I just had to restart my Guix VPS because both ssh as well as console login were failing. Rebooting fixed the issue (for now). I haven’t seen such issues before. The system was pulled and reconfigured from master in the last couple days, and recently added docker-related services. I hadn’t

bug#37237: mcron randomly stops running jobs

This is the third time I’ve seen this, and this time I’m sure that nothing else happened. I have numerous mcron jobs configured, many of which run every 15 minutes, and one which runs once a minute. Just now, at 19:22, I noticed the minutely cron job didn’t seem to run, and saw that one

bug#37071: guix import pypi httpie fails

> On 18. Aug 2019, at 13:49, Robert Vollmert wrote: > > > >> On 18. Aug 2019, at 13:28, Nicolas Goaziou wrote: >> Robert Vollmert writes: >> >>> $ guix import pypi httpie >>> …0.2.tar.gz 83KiB 291KiB/s 00:00 [##

bug#37071: guix import pypi httpie fails

> On 18. Aug 2019, at 13:28, Nicolas Goaziou wrote: > Robert Vollmert writes: > >> $ guix import pypi httpie >> …0.2.tar.gz 83KiB 291KiB/s 00:00 [##] >> 100.0% >> ….py3-none-any.whl 58KiB201KiB/s 00:00 [#

bug#37071: guix import pypi httpie fails

$ guix import pypi httpie …0.2.tar.gz 83KiB 291KiB/s 00:00 [##] 100.0% ….py3-none-any.whl 58KiB201KiB/s 00:00 [##] 100.0% guix import: warning: Failed to extract file: httpie-1.0.2.dist-info/METADATA from wheel. Backtrace:

bug#36855: guix system switch-generation doesn't

On 8. Aug 2019, at 18:40, Chris Marusich wrote: > zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: > >> 'switch-to-system-generation' doesn't call out to >> 'upgrade-shepherd-services'. I'm not sure if this was an intentional >> decision or not > > It is intentional, but only because

bug#36855: guix system switch-generation doesn't

Could we get some input on this bug? Maybe I’m misunderstanding something, but it seems that a core guix feature (atomic rollbacks) doesn’t work… > On 30. Jul 2019, at 12:00, Robert Vollmert wrote: > > What I see: > > 1. edit ~/pzprnode/pzprnode > > rob@garp ~/pzprnode$

bug#36855: guix system switch-generation doesn't

Could we get some input on this bug? Maybe I’m misunderstanding something, but it seems that a core guix feature (atomic rollbacks) doesn’t work… > On 30. Jul 2019, at 12:00, Robert Vollmert wrote: > > What I see: > > 1. edit ~/pzprnode/pzprnode > > rob@garp ~/pzprnode$

bug#36878: guix system reconfigure broken

> On 31. Jul 2019, at 20:16, Jakob L. Kreuze > wrote: > > Hi Robert, > > Robert Vollmert writes: > >> The concrete problem is this: >> >> 1. nginx is running with config file A >> 2. make some change to nginx config >> 3. run guix syste

bug#36878: guix system reconfigure broken

> On 31. Jul 2019, at 18:45, Jakob L. Kreuze > wrote: > Robert Vollmert writes: > >> Hi, >> >> it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012 >> >> guix system: Reimplement 'reconfigure’. >> >> breaks guix

bug#36878: guix system reconfigure broken

Hi, it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012 guix system: Reimplement 'reconfigure’. breaks guix system reconfigure. In particular, after reconfiguring, shepherd doesn’t know about the updated versions of services. The usual output below is missing; after reverting the

bug#36855: guix system switch-generation doesn't

What I see: 1. edit ~/pzprnode/pzprnode rob@garp ~/pzprnode$ git diff diff --git a/pzprnode b/pzprnode index 612e6a8..d8ef0ea 100755 --- a/pzprnode +++ b/pzprnode @@ -190,5 +190,6 @@ const server = http.createServer((req, res) => { }); server.listen(port, hostname, () => { +

bug#36838: mcron leaves zombies around

It seems that mcron doesn’t clean up after itself. I regularly see some zombie processes around, presumably left over by each of my two 15-minute cron jobs: root 21285 0.0 0.3 24124 3248 ?Ss 11:05 0:00 /gnu/store/mamwayq00mqs85kgs6ibww7xw6dy776s-mcron-1.1.1/bin/mcron

bug#36772: feature request: checked variant of "substitute*"

> On 23. Jul 2019, at 15:35, Ricardo Wurmus wrote: > > > Hi Robert, > >> I think it would be great to have the following variant of substitute*: >> >> (substitute*-once filename (pattern vars) body) >> >> which acts like the usual substitute-*, except it also asserts that the >>

bug#36772: feature request: checked variant of "substitute*"

I think it would be great to have the following variant of substitute*: (substitute*-once filename (pattern vars) body) which acts like the usual substitute-*, except it also asserts that the substitution applies to exactly one line in the file, causing a build failure otherwise. In the cases

bug#24076: gnupg [-agent]: when signing [commits], it claims that there is no pinentry - but there is

Just to note that this is still a problem. I just installed gnupg (via guix install gnupg), and gpg --generate-keys fails due to missing pinentry. I had to find this bug report to work around this.

bug#36069: Menu-based installer unusable through noVNC

> On 20. Jul 2019, at 15:47, Ludovic Courtès wrote: > > Hi Mark, > > Mark H Weaver skribis: > >> Ludovic Courtès wrote: >> >>> Robert Vollmert skribis: > > [...] > >>>> Great find! Indeed, lspci lists >&g

bug#36731: shepherd lost track of nginx

> On 20. Jul 2019, at 00:49, Ludovic Courtès wrote: > > Hello, > > Robert Vollmert skribis: > >> Not sure who’s at fault here, but without doing anything weird, >> I ended up with a system where shepherd thought that nginx was >> stopped, while there

bug#36731: shepherd lost track of nginx

Not sure who’s at fault here, but without doing anything weird, I ended up with a system where shepherd thought that nginx was stopped, while there was still an nginx process around. I certainly didn’t start it by hand. The result was this: $ sudo herd restart nginx Service nginx is not running.

bug#36380: related article (Debian)

Just ran across this article about Debian dealing with similar issues. https://daniel-lange.com/archives/152-hello-buster.html One of the suggested work-arounds is to rely on virtio_rng on virtual machines, but it seems Guix already uses that on my machine, so perhaps it doesn’t help: rob@garp

bug#36084: not really fixed?

It seems the two clock packages are still subtly different, apparently due to the tested variant pulling in a dependency on the test libraries. Compare https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36705. Configuring tasty-hspec-1.1.5.1... Warning: This package indirectly depends on multiple

bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken

> On 16. Jul 2019, at 17:08, Timothy Sample wrote: > > Hi Robert, > > After looking at this and your patch at , > I’m wondering if it works as long as we make sure the versions match. > Can we just inherit the current “ghc-clock”, disable its tests, and call > it

bug#36690: guix import hackage fails on key:value

Apparently, it’s valid for a cabal file to have key-value pairs without a space, e.g. benchmark benchmarks type: exitcode-stdio-1.0 main-is:Speed.hs hs-source-dirs:test default-language: Haskell2010 build-depends: base < 5, criterion, diagrams-core, diagrams-lib from

bug#36640: guix pull compile-files failure doesn't identify failed file

Specifically, building guix-packages.drv locally, I got the output below. As far as I can tell, the problematic file’s name is not contained in the output at all. The file is certainly available where we call compile-file — no idea whether it would be better to print the filename while handling

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

> On 9. Jul 2019, at 17:45, Robert Vollmert wrote: > > I’ve applied your patch and am testing it now. At first glance it doesn’t > improve the situation, compare the output below of running `guix build -L .` > similar to before, after having edited check.scm. Things do seem

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

One further data-point, not immediately related to the recompile spam, but to the proposed work-around when working within the guix repository: The suggestion was that the default workflow should be to compile the scheme files using `make`. That does avoid the recompile spam, but: - adding a

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

Hi Ludo’, thanks for looking into this! On 9. Jul 2019, at 00:15, Ludovic Courtès wrote: > Robert Vollmert skribis: >> Here’s another example, while working on a local checkout of a channel. >> Calling `guild compile` just makes things worse. >> >> $ rm -rf ~/.cac

bug#36547: expect an earlier/clearer error when trying to splice(?) a function into a gexp

I tried to use a function in a gexp along the lines of (define* (f x) …) #~(begin (#$f x) …) This resulted in the following error: ERROR: In procedure primitive-load: In procedure scm_lreadr: /gnu/store/wcw0fii855axkiqfz05283rwl7nlrb3i-puzzledb-blogs-job-builder:1:254: Unknown #

bug#36546: herd restart mcron appears to wipe /var/log/mcron.log

It appears that old mcron log output is lost when the service is restarted. That’s not good. See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36510 for another issue related to mcron logging.

bug#36430: mcron would benefit from a better way to test jobs

One related issue that I just ran into, while trying out the gexp approach: mcron jobs take an optional third naming argument, which are again better not used because they replace the store filename in the “schedule” output.

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

> On 8. Jul 2019, at 12:03, Ludovic Courtès wrote: > > Robert Vollmert skribis: > >>> On 5. Jul 2019, at 22:40, Ludovic Courtès wrote: >>> >>> Hi, >>> >>> Robert Vollmert skribis: >>> >>>> rob@garp ~/guix$

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

> On 5. Jul 2019, at 22:40, Ludovic Courtès wrote: > > Hi, > > Robert Vollmert skribis: > >> rob@garp ~/guix$ nano gnu/packages/haskell.scm >> rob@garp ~/guix$ ./pre-inst-env guix build ghc-ansi-wl-pprint > > I’d suggest running “make” once you’ve e

bug#36430: mcron would benefit from a better way to test jobs

> On 7. Jul 2019, at 16:24, Ludovic Courtès wrote: > > Hi Robert, > > Robert Vollmert skribis: > >> Defined a mcron job in config.scm scheduled to run once a day, >> with a scheme expression. How do I test this? >> >> herd schedule mcron lists the

bug#36510: confusing mcron logging

> On 5. Jul 2019, at 22:37, Ludovic Courtès wrote: > Something that can help debugging to some extent (but is definitely no > substitute for what you suggest above!) is ‘sudo herd schedule mcron’. > I use that to manually run jobs that appear not to work as expected. That only works for

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

I’ve just been working on a local guix clone, tried building a package which failed, but not after lots of the usual “newer than compiled” messages, but fine, I pulled a while earlier and hadn’t rebuilt. But then, after editing just a few lines in a single file (gnu/packages/haskell.scm), the

bug#36510: confusing mcron logging

I have two mcron jobs on my system, certbot renewal and a handwritten and currently buggy guile job. This is an excerpt from /var/log/mcron.log: > Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Cert not yet due for renewal

bug#36509: guix pull: too many substitute updates, or bad log messages

When running `guix pull`, output like the following is common for me: $ guix pull Updating channel 'puzzlink' from Git repository at '/home/rob/guix-puzzlink'… […] Building from these channels: guix https://github.com/robx/guix.git11f68b3 […] Computing Guix derivation for

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

> On 4. Jul 2019, at 09:59, Ludovic Courtès wrote: > > Hi, > > “Impossible” is an exaggeration, but when you source the > ‘environment-variables’ file, for example, PWD and other variables will > refer to /tmp/guix-build-….drv, which won’t exist. Likewise, generated > files such as

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

> On 2. Jul 2019, at 15:37, Ludovic Courtès wrote: > >> /* In a sandbox, for determinism, always use the same temporary >>directory. */ >> -tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" >> + drvName + "-0" : tmpDir; >> +tmpDirInSandbox = useChroot

bug#35863: fixed by patch

This was fixed by commit 3149c002644b927e0245d237cdda3a6aeca00e4a Author: Robert Vollmert Date: Sun Jun 16 16:18:29 2019 +0200 utils: canonical-newline-port: Fix handling of carriage return at buffer end.

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

Hi Mark, > On 30. Jun 2019, at 19:43, Mark H Weaver wrote: > > retitle 36443 Canonicalized build directory name in container leads to > confusion > thanks > > Hi Robert, > > Robert Vollmert writes: >> Thanks for clarifying. Do you have an idea how to make

bug#36443: guix build mixes build dirs?

> On 30. Jun 2019, at 19:18, Mark H Weaver wrote: > > Robert Vollmert writes: > >> So this is pretty bizarre, and I haven’t managed to cut it down >> to a smaller example yet, but it seems pretty clear that something >> is broken: >> >> $ guix buil

bug#36443: suspicion

My suspicion right now is that there’s not any real mixup happening, but that guix-daemon runs the build in a different environment in the directory /tmp/derivation-name.drv-0 which gets copied to /tmp/derivation-name.drv-5 in the root filesystem by `guix build -K`, if directories -0, -1, …,

bug#36443: guix build mixes build dirs?

So this is pretty bizarre, and I haven’t managed to cut it down to a smaller example yet, but it seems pretty clear that something is broken: $ guix build -K some-package -> error, referencing /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0 note: keeping build directory

bug#36430: mcron would benefit from a better way to test jobs

My issue: Defined a mcron job in config.scm scheduled to run once a day, with a scheme expression. How do I test this? herd schedule mcron lists the job as merely a “Lambda expression”. I learned how to give it a descriptive name, but still there’s no script linked that I can run by hand. One

bug#36380: service urandom-seed takes too long on boot

> On 27. Jun 2019, at 21:03, Leo Famulari wrote: > Perhaps, but if the reason for the slowness on their first boot was a > suboptimal /dev/hwrng source, I would expect it to be equally slow for > each boot, since we unconditionally read 64 bytes each time. It’s 512 bytes, not that that

bug#36069: Menu-based installer unusable through noVNC

> On 26. Jun 2019, at 22:23, pelzflorian (Florian Pelz) > wrote: > > On Wed, Jun 26, 2019 at 06:51:41PM +0200, Björn Höfling wrote: >> What's the conclusion? Maybe that Guix is fine and the VNC-clients are >> also fine. It might just be a matter of configuration or using an older >> version

bug#36069: Menu-based installer unusable through noVNC

> On 26. Jun 2019, at 18:51, Björn Höfling > wrote: > In that way, I have the QEMU console in my terminal and I can call the > "system_reset" command: I suspected that the bug would only appear when > the VNC-Client is connected WHILE the installer start up. Usually the > startup would be

bug#36388: activation?

Could it be that the errors happen in the activation script, but not when actually starting nginx? I see in the code that we appear to pass a “-p” flag already when starting nginx; maybe we should simply do the same when testing the config during activation?

bug#36389: odd

I agree that it sounds odd, and some of my original diagnostic must be skewed. After several configuration changes and system reconfigurations and nginx restarts, I do appear to have a sensible state currently, and I can’t reliably reproduce the problems I had before. I’m also pretty sure I didn’t

bug#30939: still relevant

This came up again recently, compare the discussion here: https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00186.html Here’s some code to wrap an executable manually to capture its output and send it to syslog: (define* (logger-wrapper name exec . args) "Return a derivation that

bug#36380: service urandom-seed takes too long on boot

> On 26. Jun 2019, at 17:47, Leo Famulari wrote: > > On Tue, Jun 25, 2019 at 08:12:28PM +0200, Robert Vollmert wrote: >> On my VPS, booting takes forever (long enough that for a long >> time I thought the install had failed). I just rebooted again, >> and it took o

bug#36389: nginx/certbot interaction doesn't work as documented

I’ve tried setting up nginx with certbot on guix. Two immediate issues: - certbot extends the nginx service to serve challenge files. It appears that this nginx service extension conflicts (silently) with an independently configured nginx service. I.e., I had nginx previously configured, and

bug#36388: nginx startup logging error, at odds with documentation

The documentation states: At startup, ‘nginx’ has not yet read its configuration file, so it uses a default file to log error messages. If it fails to load its configuration file, that is where error messages are logged. After the configuration file is loaded, the default error log file

bug#36380: service urandom-seed takes too long on boot

On my VPS, booting takes forever (long enough that for a long time I thought the install had failed). I just rebooted again, and it took over 7 minutes, see attached screenshot. I would suggest skipping the seeding from /dev/hwrng by default if /var/lib/random-seed is available. I’m assuming here

bug#36069: Menu-based installer unusable through noVNC

> On 25. Jun 2019, at 17:54, pelzflorian (Florian Pelz) > wrote: > > On Tue, Jun 25, 2019 at 05:06:03PM +0200, Björn Höfling wrote: >> I guess you (Ludovic) have tried the installer with QEMU and its >> VNC-Server, maybe even with different VNC-clients? >> > > It works with > >

bug#36069: Menu-based installer unusable through noVNC

Hi, > On 25. Jun 2019, at 15:59, Ludovic Courtès wrote: > > Hi, > > Björn Höfling skribis: > >> On Mon, 3 Jun 2019 11:35:17 +0200 >> Robert Vollmert wrote: >> >>> There seems to be some conflict between the “graphical” installer’s >>

bug#36373: failed copy-file should print path

I just ran into this error while trying to build a go package. There’s no obvious way to figure out which file caused “permission denied”. I’d like to both see the non-truncated filename in the backtrace, as well as in the error message below. Backtrace: 10 (primitive-load

bug#36282: shepherd appears to delete log-file instead of appending

This is from reading the shepherd code, not verified by test currently. Apologies if I’m missing something. The documentation claims that log-file is appended to: When @var{log-file} is true, it names the file to which the service's standard output and standard error are redirected.

bug#36264: shepherd doesn't capture service stdout/stderr

On a pretty fresh Guix System install, I see some regular sshd error messages on tty1 (which I guess means they’re written to /dev/console). Also, setting up a regular shepherd service via make-forkexec-constructor for a program that logs to stderr (postgrest which I’m in the process of

bug#36248: poor error tracing

I’m not sure if this lies more with guile or with guix, but there’s definitely room for improvment either way. I was working on https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36084, haskell-check.scm was changed as follows: - ("ghc-clock-bootstrap" ,ghc-clock-bootstrap) +

bug#23961: fixed a while back

commit 314b63e0b4372681aec165113ae2a0349eaaa357 Author: Danny Milosavljevic Date: Wed Jul 11 11:02:51 2018 +0200 import: hackage: Support "custom-setup" field. Fixes . * guix/import/cabal.scm (make-cabal-parser): Modify. (is-custom-setup):

bug#36240: indent-code.el is not aware of (package (inherit ...)) style

When encountering a package definition that starts (package (inherit other-package)) etc/indent-code.el will indent the rest of the package body to align with the start of (inherit. That seems to be a common idiom, used in roughly half of the instances: guix/gnu/packages$ git grep '(inherit '

bug#36231: haskell-build-system: patches conflict with cabal revisions

The cabal revision mechanism replaces the cabal file after any patches have been applied, making it impossible to patch the cabal file via the regular patching mechanism.

bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken

ghc-tasty depends via “inputs” on ghc-clock-bootstrap (v0.5) which is built without tests, while ghc-clock (v0.7) depends via “native-inputs” on ghc-tasty for tests. This means that any package which depends on ghc-tasty and ghc-clock is potentially broken, e.g.: Warning: This package

bug#35942: guix install: environment variable message is very confusing

When installing a package that needs an environment variaible to be set for use, `guix install` prints e.g.: $ guix install python ... The following environment variable definitions may be needed: export

bug#35743: applies more widely

The problem seems more wide-spread, so should probably be fixed within import/cabal.scm. E.g. warp: http://hackage.haskell.org/package/warp-3.2.27/warp.cabal http://hackage.haskell.org/package/streaming-commons-0.2.1.0/streaming-commons.cabal contain things along the following lines:

bug#35883: guix import hackage: recursive import fails silently on errors

$ guix import hackage not-a-package guix import: error: failed to download cabal file for package 'not-a-package’ $ echo $? 1 $ guix import hackage -r not-a-package $ echo $? 0 It might be argued that the error code is fine, since in general it could be useful for the recursive import to keep

bug#35881: guix import hackage: option -r and -s interact poorly

Recursive import from a cabal file on standard input doesn’t work, since imports of dependencies are attempted from standard input. This typically fails due to EOF. The sensible behaviour would probably be to only read the initial package from standard input, and then fall back to hackage.

bug#35863: `guix import hackage random` fails due to mysterious CRLF-related trouble

$ curl http://hackage.haskell.org/package/random-1.1/random.cabal > random.cabal $ guix import hackage -s < random.cabal (at line 49, column 0)d token : Syntax error: unexpected end of input guix import: error: failed to import cabal file from standard input $ tr -d '\r' < random.cabal | guix

bug#25138: updated import error

These days it’s: Syntax error: unexpected token : (buildable (False)) (at line 471, column 4) Syntax error: unexpected end of input Relevant cabal extract: 469 Executable darcs 470if !flag(executable) 471 buildable: False 472else 473 buildable: True

bug#35743: fixed upstream

This specific case has been fixed upstream, and should eventually make it to hackage: https://github.com/yesodweb/wai/pull/748 The issue does remain in the sense that `guix import` doesn’t parse some such cabal files that `cabal` is happy with — mark done anyway?

bug#23961: seems to be fixed

This seems to be fixed. With current guix, both guix import hackage gtk3 and the duplicate’s guix import hackage monadplus work.

bug#35754: guix build silent failure for unterminated string

I suspect this had to do with the size of the file, but I’m not really sure what was going on. $ guix build -f postgrest.scm $ echo $? 1 The unterminated string is within the definition of `ghc-string-conversions`, line 1169. File attached. postgrest.scm Description: Binary data

bug#35750: `guix import hackage` is unaware of metadata revisions

As far as I can tell, `guix import hackage` imports the first revision of a hackage release. I suggest aiming to import the latest cabal revision from hackage, as already supported by haskell-build-system via the #:cabal-version argument. In the meantime, documenting this in the `guix import

bug#35743: indentation error

I learned about `guix import hackage --stdin`, and it turns out the problem is with bad indentation in the cabal file. (The offending line is indented by two spaces instead of four spaces for the block before.) It’s unclear to me whether this is a “valid” cabal file as it is.

bug#35743: guix import hackage wai-app-static fails (comment syntax?)

$ guix import hackage wai-app-static Syntax error: unexpected token : (ghc-options (-Wall)) (at line 106, column 2) The relevant extract of the cabal file is: test-suite runtests […] build-depends: base >= 4&& < 5 […] , mockery

bug#35735: guix import hackage cassava fails (cabal brace syntax)

$ guix import hackage cassava … Syntax error: unexpected token : { (at line 8, column 0) Syntax error: unexpected end of input guix import: error: failed to download cabal file for package ‘cassava’ The same happens with stackage import. The reason seems to be unusal syntax in the description