bug#30189: Retux game halts after preloading levels (missing ucd.sqlite uniseg database)

[Ben Sturmfels]

Thanks Gábor, adding zipfile fixes the build and Retux now runs.

Patch attached and CC'd to guix-patches.

Regards,
Ben

On Sun, 21 Jan 2018, Gábor Boskovits wrote:

> I think unzip should be added to native-inputs. Can you try that?
>
> 2018-01-21 4:46 GMT+01:00 Ben Sturmfels :
>
>  Hi Folks,
>
>  I'd like to play the Retux game, but while the game starts up it
>  crashes
>  on me after the "preloading levels" screen.
>
>  There's no useful console output, but when running in the debugger, I
>  see that the python-uniseg package is looking for a file called
>  ucd.sqlite3 that doesn't exist, some kind of Unicode letter spacing
>  database that's not present in the BitBucket repository.
>
>  python3 -m pdb -c continue \
>  "/gnu/store/57psnlgdyri8phkxzasaf6q0gb8nskpz-retux-1.3.5/bin/.retux-real"
>  
>
>  See uniseg/db.py:107 and 21. Since it's also looking in the current
>  directory, I tried downloading ucd.sqlite3 from the PyPI zip package -
>  that fixes the issue.
>
>  The python-uniseg package downloads the source from BitBucket, so
>  I
>  tried changing that to PyPI:
>
>  (uri (pypi-uri "uniseg" version ".zip"))
>
>  which downloads ok, but fails but the fails at the unpack phase
>  without
>  any details. Should Guix know how to unpack a .zip? Or maybe I
>  should
>  coerce the maintainer to publish a .tar.gz?
>
>  Currently Retux is the only program that uses python-uniseg (via
>  python-sge-pygame dependency).
>
>  Regards,
>  Ben
From 42c1e69526ec9781e3f7290fb74e2a561131e3be Mon Sep 17 00:00:00 2001
From: Ben Sturmfels 
Date: Sun, 21 Jan 2018 18:43:07 +1100
Subject: [PATCH] gnu: python-uniseg: Switch to PyPi source to get missing
 ucd.sqlite3.

* gnu/packages/python.scm (python-uniseg): Use PyPI, add zipfile dependency to
  unpack.
---
 gnu/packages/python.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 0b582e6b7..2f1c20e31 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -773,15 +773,15 @@ Python 3 support.")
 (source
  (origin
(method url-fetch)
-   (uri (string-append "https://bitbucket.org/emptypage/uniseg-python/;
-   "get/rel-" version ".tar.gz"))
-   (file-name (string-append name "-" version ".tar.gz"))
+   (uri (pypi-uri "uniseg" version ".zip"))
(sha256
 (base32
- "1df4gddnj2a0v8z35wb2ra5vvh1f1qyxs8fgd25c8g64031mna6x"
+ "05jsazvz6nbmh6l3v1rph5ydkqn1hzx1pyggdyvgp2qgmgrnmiz2"
 (build-system python-build-system)
 (arguments
  '(#:tests? #f)) ; The test suite requires network access.
+(native-inputs
+ `(("unzip" ,unzip)))
 (home-page
  "https://bitbucket.org/emptypage/uniseg-python;)
 (synopsis
-- 
2.15.1



signature.asc
Description: PGP signature

bug#30189: Retux game halts after preloading levels (missing ucd.sqlite uniseg database)

[Gábor Boskovits]

I think unzip should be added to native-inputs. Can you try that?


2018-01-21 4:46 GMT+01:00 Ben Sturmfels :

> Hi Folks,
>
> I'd like to play the Retux game, but while the game starts up it crashes
> on me after the "preloading levels" screen.
>
> There's no useful console output, but when running in the debugger, I
> see that the python-uniseg package is looking for a file called
> ucd.sqlite3 that doesn't exist, some kind of Unicode letter spacing
> database that's not present in the BitBucket repository.
>
>   python3 -m pdb -c continue \
>   "/gnu/store/57psnlgdyri8phkxzasaf6q0gb8nskpz-retux-1.3.5/bin/.retux-
> real"
>
> See uniseg/db.py:107 and 21. Since it's also looking in the current
> directory, I tried downloading ucd.sqlite3 from the PyPI zip package -
> that fixes the issue.
>
> The python-uniseg package downloads the source from BitBucket, so I
> tried changing that to PyPI:
>
>   (uri (pypi-uri "uniseg" version ".zip"))
>
> which downloads ok, but fails but the fails at the unpack phase without
> any details. Should Guix know how to unpack a .zip? Or maybe I should
> coerce the maintainer to publish a .tar.gz?
>
> Currently Retux is the only program that uses python-uniseg (via
> python-sge-pygame dependency).
>
> Regards,
> Ben
>

bug#30116: [PATCH] `substitute' crashes when file contains NUL characters (core-updates)

[Maxim Cournoyer]

l...@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> I've encountered the following crash when trying to use substitute on a
>> file which contains NUL characters:
>
> Yes, that’s because Guile’s ‘regexp-exec’ simply wraps libc’s ‘regexec’,
> which does not handle NULs.
>
> We should consider switching to the pure-Scheme SRFI-115:
>
>   https://srfi.schemers.org/srfi-115/srfi-115.html

This looks good, and I started looking into porting `substitute' to it,
but quickly noticed it doesn't seem to be implemented in Guile yet?

Thanks,

Maxim

bug#30185: [PATCH] [core-updates] Put locales where libc will find them

[Mark H Weaver]

On my mips64el-linux GuixSD system, now updated to something close to
core-updates (but with binutils-2.25.1), guile prints this warning:

  guile: warning: failed to install locale

and 'locale' prints:

  mhw@yeeloong ~$ locale
  locale: Cannot set LC_CTYPE to default locale: No such file or directory
  locale: Cannot set LC_MESSAGES to default locale: No such file or directory
  locale: Cannot set LC_ALL to default locale: No such file or directory
  LANG=en_US.utf8
  LC_CTYPE="en_US.utf8"
  LC_NUMERIC="en_US.utf8"
  [...]

strace shows attempts to open files in /run/current-system/locale/2.26,
which was not included in my built system.  Instead I have:

  /run/current-system/locale/2.26.105-g0890d5379c

This matches the version field of our 'glibc' package in core-updates,
but it's not where libc is looking.

I've attached a patch that fixes the problem for me.
What do you think?

  Mark

>From cb343d623d31e0687725d37c8585b440ec5144ec Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Sat, 20 Jan 2018 01:57:07 -0500
Subject: [PATCH] system: Put locales where libc will find them.

* gnu/system/locale.scm (localedef-command, single-locale-directory): Use only
the major+minor part of the libc version number in the locale directory name.
---
 gnu/system/locale.scm | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/gnu/system/locale.scm b/gnu/system/locale.scm
index 75cb855b5..75417f669 100644
--- a/gnu/system/locale.scm
+++ b/gnu/system/locale.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015, 2016, 2017 Ludovic Courtès 
+;;; Copyright © 2018 Mark H Weaver 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,6 +22,7 @@
   #:use-module (guix store)
   #:use-module (guix records)
   #:use-module (guix packages)
+  #:use-module (guix utils)
   #:use-module (gnu packages base)
   #:use-module (gnu packages compression)
   #:use-module (srfi srfi-26)
@@ -90,9 +92,9 @@ or #f on failure."
   "--no-archive" "--prefix" #$output
   "-i" #$(locale-definition-source locale)
   "-f" #$(locale-definition-charset locale)
-  (string-append #$output "/"
- #$(package-version libc) "/"
- #$(locale-definition-name locale))
+  (string-append #$output "/" #$(version-major+minor
+ (package-version libc))
+ "/" #$(locale-definition-name locale))
 
 (define* (single-locale-directory locales
   #:key (libc (canonical-package glibc)))
@@ -102,7 +104,7 @@ Because locale data formats are incompatible when switching from one libc to
 another, locale data is put in a sub-directory named after the 'version' field
 of LIBC."
   (define version
-(package-version libc))
+(version-major+minor (package-version libc)))
 
   (define build
 #~(begin
-- 
2.16.0

bug#30184: guix publish issue: guix substitute: error: corrupt input while restoring

[Efraim Flashner]

On Sat, Jan 20, 2018 at 12:07:41PM +, Christopher Baines wrote:
> Hey,
> 
> I think something may have broken recently with the guix publish
> service. I run this on a server with very basic configuration, just
> setting the host, but I noticed recently that there were problems using
> the service. The following example is guix failing to download something
> from that server.
> 
> Downloading 
> http://beid.cbaines.net/nar/gzip/pwg84wqsniamc4vx9c7p06284i5rxiay-wxwidgets-3.0.3...
>  wxwidgets-3.0.3   
> 256KiB/s 00:00 | 16KiB transferred
> gzip: stdin: not in gzip format
> guix substitute: error: corrupt input while restoring 
> '/gnu/store/pwg84wqsniamc4vx9c7p06284i5rxiay-wxwidgets-3.0.3' from #{read 
> pipe}#
>  wxwidgets-3.0.3   
> 316KiB/s 00:00 | 48KiB transferredguix package: error: build failed: some 
> substitutes for the outputs of derivation 
> `/gnu/store/7f0zr1zgp6q1nyrsxf88qn003gr1w53b-wxwidgets-3.0.3.drv' failed 
> (usually happens due to networking issues); try `--fallback' to build 
> derivation from source
> 
> I reverted the 4 recent changes [1], changed the service configuration
> to use (guix (current-guix)) and now it seems to be working again.
> 
> I've had a look through the changes, I couldn't spot anything, but I
> think there could be a regression in these changes [1].
> 
> Thanks,
> 
> Chris
> 
> 
> 1: f396611776e7ed6f1a070569a338ad56461b099e
>152b7beeacb72fe96fd5d3c0fd8b321e247c2c6c
>c04ffadbed741254b8be6b78f23eed150d26
>297e04d66010ada31a40f40143d81bf6b62affcc

I'm also coming up against this with my aarch64 machines. The guix
version is the same on both of them, both machines are running
guix-publish with guix-0.14.0-6.0dcf675.
efraim@odroidc2:~$ guix --version
guix (GNU Guix) 0.14.0.1000-3b1ad

I checked the logs for guix-publish but all I have are entries like:
Jan 20 21:16:09 firefly guix[406]: GET 
/nar/gzip/h4s5s9zlbph0r27x4plfmh89r67s4mdq-dosfstools-4.1

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#30184: guix publish issue: guix substitute: error: corrupt input while restoring

[Christopher Baines]

Hey,

I think something may have broken recently with the guix publish
service. I run this on a server with very basic configuration, just
setting the host, but I noticed recently that there were problems using
the service. The following example is guix failing to download something
from that server.

Downloading 
http://beid.cbaines.net/nar/gzip/pwg84wqsniamc4vx9c7p06284i5rxiay-wxwidgets-3.0.3...
 wxwidgets-3.0.3   256KiB/s 
00:00 | 16KiB transferred
gzip: stdin: not in gzip format
guix substitute: error: corrupt input while restoring 
'/gnu/store/pwg84wqsniamc4vx9c7p06284i5rxiay-wxwidgets-3.0.3' from #{read pipe}#
 wxwidgets-3.0.3   316KiB/s 
00:00 | 48KiB transferredguix package: error: build failed: some substitutes 
for the outputs of derivation 
`/gnu/store/7f0zr1zgp6q1nyrsxf88qn003gr1w53b-wxwidgets-3.0.3.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source

I reverted the 4 recent changes [1], changed the service configuration
to use (guix (current-guix)) and now it seems to be working again.

I've had a look through the changes, I couldn't spot anything, but I
think there could be a regression in these changes [1].

Thanks,

Chris


1: f396611776e7ed6f1a070569a338ad56461b099e
   152b7beeacb72fe96fd5d3c0fd8b321e247c2c6c
   c04ffadbed741254b8be6b78f23eed150d26
   297e04d66010ada31a40f40143d81bf6b62affcc


signature.asc
Description: PGP signature