bug#47335: xmonad fails to recompile on guix system
Hi, I’m seeing the same issue, but it works when explicitly installing ghc@8.6. Looking at haskell-build-system all Haskell libraries are currently built with version 8.6, whereas the newest GHC version available (and thus installed by `guix install`) is 8.8. I feel that either xmonad should depend on the correct GHC or all GHC versions not used to build libraries should be hidden to avoid this situation. Lars
bug#49515: [core-updates] mescc-tools tests fail
Hi Janneke! Jan Nieuwenhuizen skribis: >> Ludovic Courtès skribis: >> >>> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’, >>> mescc-tools fails tests, with generated binaries segfaulting: >>> >>> $ ./pre-inst-env guix build mescc-tools >>> >>> […] >>> >>> + . ./sha256.sh >>> ++ set -ex >>> ++ ./bin/get_machine >>> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian >>> --architecture knight-native -o test/test3/hold >>> + '[' amd64 = amd64 ']' >>> + ./test/results/test1-binary >>> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian >>> --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary >>> --exec_enable >>> test/test1/hello.sh: line 37: 125 Segmentation fault >>> ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1 [...] >> Should we upgrade instead? If we do, what’s the potential for breakage? >> Should ‘mes-rb5’ be kept on an older version? > > We could try that, I really can't tell if upgrading to 1.1.0 creates > a different mes binary. I took this route and everything went well, and we can now build ‘bootstrap-tarballs’ on x86_64-linux. I ended up doing additional changes: e2690a8eb2 gnu: mes-rb5: Remove. da32015db0 gnu: mes-minimal-stripped: Explicitly disallow references. 5510e1c483 gnu: mes: Remove 0.19. 81096caf7d gnu: mes: Switch to Guile 3.0. 114a9f1f80 gnu: mescc-tools: Update to 1.2.0. 0b9da8b5a2 gnu: m2-planet: Update to 1.8.0. 8b627a7701 gnu: mes-minimal: Remove unused variable. Removing ‘mes-rb5’ was a bit disheartening but I guess it’d have to be updated to the current tool versions. I removed Mes 0.19 because it failed to build with Guile 3.0 and didn’t appear to be needed any longer. Let me know if you think I did anything wrong! Thanks, Ludo’.
bug#49515: [core-updates] mescc-tools tests fail
Ludovic Courtès writes: Hi Ludo! > Jan Nieuwenhuizen skribis: > >>> Should we upgrade instead? If we do, what’s the potential for breakage? >>> Should ‘mes-rb5’ be kept on an older version? >> >> We could try that, I really can't tell if upgrading to 1.1.0 creates >> a different mes binary. > > I took this route and everything went well, and we can now build > ‘bootstrap-tarballs’ on x86_64-linux. I ended up doing additional > changes: > > e2690a8eb2 gnu: mes-rb5: Remove. > da32015db0 gnu: mes-minimal-stripped: Explicitly disallow references. > 5510e1c483 gnu: mes: Remove 0.19. > 81096caf7d gnu: mes: Switch to Guile 3.0. > 114a9f1f80 gnu: mescc-tools: Update to 1.2.0. > 0b9da8b5a2 gnu: m2-planet: Update to 1.8.0. > 8b627a7701 gnu: mes-minimal: Remove unused variable. > Removing ‘mes-rb5’ was a bit disheartening but I guess it’d have to be > updated to the current tool versions. Yeah, a bit sad but OK I guess. > I removed Mes 0.19 because it failed to build with Guile 3.0 and didn’t > appear to be needed any longer. > > Let me know if you think I did anything wrong! LGTM! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#49233: gmnisrv: missing mime.types
Hi, I believe commits b459c39adb725822916a8e21ee250fb408d2e2f8 and e17f063627f826b4dd0dda77ede48fc7a535414b address this issue. So, closing this issue. Thanks, Arun signature.asc Description: PGP signature
