bug#35780: texlive-latex-polyglossia package empty

[Josh Holland]

Steps to reproduce:
$ guix build texlive-latex-polyglossia
$ tree 
/gnu/store/d9nndb33yd22pay1yyg76nb0i56qdmkq-texlive-latex-polyglossia-49435

Expected results:
Something containing the file polyglossia.sty

Actual results:
Only an empty directory share/texmf-dist/tex/latex/polyglossia exists.

bug#35780: [PATCH] attempt to fix polyglossia

[Josh Holland]

---
I had a quick look into fixing this myself, and made a little bit
of progress.  Not being that familiar with how things work yet,
I'm going on what I can guess by looking at gnu/packages/tex.scm,
guix/build-system/texlive.scm and guix/build/texlive-build-system.scm
so I may well be misinterpreting some things.

The source for polyglossia comes in a single file, polyglossia.dtx.
The README embedded within it says to extract the files by running
xetex or luatex on it.  I tried to convince the build system to do
this by this patch, which may or may not have been the right approach.
It does at least get a new error:

Generating file(s) ../README 
! I can't write on file `../README.tex'.

It appears to be trying to write its README file to the directory above
the build directory, which is failing. Is there a way to make this
directory writeable, or to stop the build system from trying to generate
the README there?

 gnu/packages/tex.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index c3ce80c8f5..0894148501 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -3249,7 +3249,8 @@ array environments; verbatim handling; and syntax 
diagrams.")
(base32
 "03ma58z3ypsbp7zgkzb1ylpn2ygr27cxzkf042ns0rif4g8s491f"
 (build-system texlive-build-system)
-(arguments '(#:tex-directory "latex/polyglossia"))
+(arguments '(#:tex-directory "latex/polyglossia"
+ #:build-targets '("polyglossia.dtx")))
 (home-page "https://www.ctan.org/pkg/polyglossia";)
 (synopsis "Alternative to babel for XeLaTeX and LuaLaTeX")
 (description
-- 
2.21.0

bug#35780: [PATCH] attempt to fix polyglossia

[Josh Holland]

Hi,

(CCing guix-devel because I'm confused about this and more eyes can't
hurt)

On Sat, May 18, 2019 at 05:50:13AM +0200, Ricardo Wurmus wrote:
> Thanks for giving it a try.  The build system works on “ins” files by
> default.  I guess it should try “dtx” files as well.

Should this be a patch to the build-system?  Although maybe it's not
that simple: https://ctan.org/texarchive/macros/xetex/latex/polyglossia
lists four files, incuding an "ins" file.

> We can patch the dtx file in a build phase and replace “../README” with
> just “README”.

I tried patching the README path as Ricardo suggested.  This got
somewhere, complaining of missing fonts, so I added texlive-fonts-cm
to native-inputs.  With both these changes, the build now fails while
trying to build example-thai.tex, and the errors appear to indicate
trying to build a LaTeX file with plain TeX:

Processing file polyglossia.dtx (example-thai.tex) -> example-thai.tex
File polyglossia.dtx ended by \endinput.
Lines  processed: 11224
Comments removed: 1600
Comments  passed: 215
Codelines passed: 9209

! Undefined control sequence.
l.209 \documentclass
  [11pt]{ltxdoc}
! Undefined control sequence.
l.210 \usepackage
   {color}
! Undefined control sequence.
l.211 \usepackage
   {xspace,fancyvrb}
! Undefined control sequence.
l.212 \usepackage
   [neverdecrease]{paralist}
! Undefined control sequence.
l.213 \definecolor
{myblue}{rgb}{0.02,0.04,0.48}
! Undefined control sequence.
l.214 \definecolor
{lightblue}{rgb}{0.61,.8,.8}
! Undefined control sequence.
l.215 \definecolor
{myred}{rgb}{0.65,0.04,0.07}
! Undefined control sequence.

(and more...)

I'm not that familiar with the intricacies of properly building TeXLive
from source, but the difference between the file list on CTAN and what
comes from the Subversion repo via texlive-ref smells fishy to me.  If I
manually run any permutation of  `{xe,lua}tex polyglossia.{ins,dtx}`
it mostly seems to build OK, but to my surprise no polyglossia.sty
is produced!  There's no actual build instructions in the README or the
polyglossia.pdf, so I'm rather lost here.

Thanks,

-- 
Josh Holland

bug#36675: kodi 18.2 fails to build

[Josh Holland]

Steps to reproduce:
$ guix build kodi

Expected result:
kodi builds successfully

Actual result:
test suite fails, with the below error message

8<

Start 438: TestMassEvent.General
438/521 Test #438: TestMassEvent.General 
Child aborted***Exception:  
 0.82 sec
Note: Google Test filter = TestMassEvent.General
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from TestMassEvent
[ RUN  ] TestMassEvent.General
[   OK ] TestMassEvent.General (105 ms)
[--] 1 test from TestMassEvent (105 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (142 ms total)
[  PASSED  ] 1 test.
kodi-test: ../nptl/pthread_mutex_lock.c:434: __pthread_mutex_lock_full: 
Assertion `robust || (oldval & FUTEX_OWNER_DIED) == 0' failed.

Start 439: TestMassEvent.Polling
439/521 Test #439: TestMassEvent.Polling 
Child aborted***Exception:  
 0.79 sec
Note: Google Test filter = TestMassEvent.Polling
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from TestMassEvent
[ RUN  ] TestMassEvent.Polling
[   OK ] TestMassEvent.Polling (133 ms)
[--] 1 test from TestMassEvent (133 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (276 ms total)
[  PASSED  ] 1 test.
Clean shutdown of TestGlobalPattern1
kodi-test: ../nptl/pthread_mutex_lock.c:434: __pthread_mutex_lock_full: 
Assertion `robust || (oldval & FUTEX_OWNER_DIED) == 0' failed.

--8<----------

--
Josh Holland

bug#36675: Acknowledgement (kodi 18.2 fails to build)

[Josh Holland]

I tried again just now, and:
successfully built /gnu/store/pmq2jv9j9snmyzbdngmklghn9bpzrxig-kodi-18.2.drv
/gnu/store/qzc0j7v4b4ylgqrk5n8h2dj5q5bp8qbf-kodi-18.2

It's definitely failed before a bunch of times when I've tried to do
`guix upgrade`, so not sure what to make of it really.

--
Josh Holland

bug#36675: Same build failure with kodi 18.3

[Josh Holland]

Hi,

I just had the same error with Kodi 18.3
(z1zswg7wfz4lb6zmyzsns2hpkbw5scir-kodi-18.3.drv), although only with the
TestMassEvent.General test; .Polling passed fine.  This kind of makes
sense with it being some sort of race condition on the mutex(?).

--8<--
438/521 Test #438: TestMassEvent.General 
Child aborted***Exception:  
 1.62 sec
Note: Google Test filter = TestMassEvent.General
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from TestMassEvent
[ RUN  ] TestMassEvent.General
[   OK ] TestMassEvent.General (107 ms)
[--] 1 test from TestMassEvent (107 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (162 ms total)
[  PASSED  ] 1 test.
Clean shutdown of TestGlobalPattern1
kodi-test: ../nptl/pthread_mutex_lock.c:434: __pthread_mutex_lock_full: 
Assertion `robust || (oldval & FUTEX_OWNER_DIED) == 0' failed.

Start 439: TestMassEvent.Polling
439/521 Test #439: TestMassEvent.Polling 
   Passed0.23 sec
--8<--

I had a look in dmesg as suggested by Amirouche, and this appears to be
the only relevant line:

--8<--
[ 1540.045259] audit: type=1701 audit(1564480138.686:163): auid=4294967295 
uid=977 gid=977 ses=4294967295 pid=11783 comm="DumbThread" 
exe="/tmp/guix-build-kodi-18.3.drv-0/build/kodi-test" sig=6 res=1
--8<--


--
Josh Holland

bug#36675: Same build failure with kodi 18.3

[Josh Holland]

...and just to confirm that this is some annoyingly unreproducible race
condition, the very next try to build that same z1zswg derivation
completed fine.


--
Josh Holland

bug#36965: streamlink fails to run

[Josh Holland]

Hi,

If I try to run streamlink, each plugin it tries to import fails to load
with an error message similar to the following:

Failed to load plugin zhanqi:
  File 
"/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/lib/python3.7/imp.py",
 line 235, in load_module
return load_source(name, filename, file)
  File 
"/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/lib/python3.7/imp.py",
 line 172, in load_source
module = _load(spec)
  File "", line 696, in _load
  File "", line 677, in _load_unlocked
  File "", line 724, in exec_module
  File "", line 838, in get_code
TypeError: a bytes-like object is required, not 'str'

This smells like a Python 2 vs 3 problem to me, but I'm not sure how to
diagnose it.  I also tried upgrading the package to 1.1.1, but that
gives the same error.  I can attach a patch for the former if required,
but I'd rather get to the bottom of this error before making any changes.

--
Josh Holland

bug#37437: hash mismatch for emacs-elixir-mode

[Josh Holland]

Hi, I just did the following:

$ guix install emacs-elixir-mode
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
downloading from 
https://ci.guix.gnu.org/nar/gzip/7n24v62aw8sjlrs06gbz4zvj11zvryry-emacs-epl-0.8...
 emacs-epl-0.8  24KiB2.6MiB/s 00:00 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/gzip/152p023jxd5cf5lr87wighihp92pkal6-emacs-pkg-info-0.6...
 emacs-pkg-info-0.6  17KiB   3.1MiB/s 00:00 
[##] 100.0%

building 
/gnu/store/b91172xfzkscfd9627d0ysrdjgpbxs6z-elixir-mode-2.3.1.tar.drv...
downloading from https://stable.melpa.org/packages/elixir-mode-2.3.1.tar...
\sha256 hash mismatch for 
/gnu/store/bb5m97pbmzvwlvn8wmrdfgpvnl0k8r1m-elixir-mode-2.3.1.tar:
  expected hash: 091cizxg1aw8bkj58y048mj020ssapjflav633z9bl6gmi10dy4v
  actual hash:   13d5r64rqskdapnrbbxv0h91gn77c6af5kjjrg5mpphvl887s04c
hash mismatch for store item 
'/gnu/store/bb5m97pbmzvwlvn8wmrdfgpvnl0k8r1m-elixir-mode-2.3.1.tar'
build of /gnu/store/b91172xfzkscfd9627d0ysrdjgpbxs6z-elixir-mode-2.3.1.tar.drv 
failed
View build log at 
'/var/log/guix/drvs/b9/1172xfzkscfd9627d0ysrdjgpbxs6z-elixir-mode-2.3.1.tar.drv.bz2'.
cannot build derivation 
`/gnu/store/xqdxvb7xy4ydpwkqgp3jd985qb4vw8k2-emacs-elixir-mode-2.3.1.drv': 1 
dependencies couldn't be built
guix install: error: build of 
`/gnu/store/xqdxvb7xy4ydpwkqgp3jd985qb4vw8k2-emacs-elixir-mode-2.3.1.drv' failed

Is something nefarious going on, or have upstream just changed their
tarballs?

Thanks,

--
Josh Holland

bug#37662: substitution failure of nss-certs

[Josh Holland]

After the core-updates merge today, I did the following, and it gave an
error message (I tried a couple of times, with the same result):

$ guix pull && guix package -m ~/guix-packages.scm -u .
# ... snip ...
downloading from 
https://ci.guix.gnu.org/nar/gzip/532l4zja85y9c69i0l0bwnsxx98gpzdw-nss-certs-3.45...
 nss-certs-3.45  148KiB 
 937KiB/s 
00:00 [# ]  10.8%Backtrace:

gzip: stdout: Broken pipe
   3 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  1 (_ #(#(#)))
In guix/ui.scm:
  1734:12  0 (run-guix-command _ . _)

guix/ui.scm:1734:12: In procedure run-guix-command:
Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide 
string to output locale" 84 #f #f)'.
 nss-certs-3.45  148KiB 
 1.3MiB/s 
00:00 [##] 100.0%substitution of 
/gnu/store/532l4zja85y9c69i0l0bwnsxx98gpzdw-nss-certs-3.45 failed
killing process 645584
guix package: error: some substitutes for the outputs of derivation 
`/gnu/store/gvckkl62hkn74wcyw9x1wd0bkjf7c6y5-nss-certs-3.45.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source

I then did the same, but added the suggested `--fallback` option onto
the end:

$ guix package -m ~/guix-packages.scm -u . --fallback
# snip massive list of "the following derivations will be built"
downloading from 
https://ci.guix.gnu.org/nar/gzip/532l4zja85y9c69i0l0bwnsxx98gpzdw-nss-certs-3.45...
 nss-certs-3.45  148KiB 
36.0MiB/s 
00:00 [# ]  10.8%Backtrace:

gzip: stdout: Broken pipe
   3 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  1 (_ #(#(#)))
 nss-certs-3.45  148KiB 
12.5MiB/s 
00:00 [##] 100.0%In guix/ui.scm:
  1734:12  0 (run-guix-command _ . _)

guix/ui.scm:1734:12: In procedure run-guix-command:
Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide 
string to output locale" 84 #f #f)'.
substitution of /gnu/store/532l4zja85y9c69i0l0bwnsxx98gpzdw-nss-certs-3.45 
failed

The command did then complete successfully, I assume building nss-certs
locally instead, though I can't see any further references to it in the
output.

I'm currently trying the same thing on my other computer.

--
Josh Holland

bug#36965: Streamlink now works fine

[Josh Holland]

Hi,

Streamlink got updated recently and it now works fine, so this bug can
be closed (not sure if I can do it or how to do it myself through
debbugs).


--
Josh Holland

bug#37662: substitution failure of nss-certs

[Josh Holland]

Hi Ludo',

Ludovic Courtès  writes:
> I suppose the error here is because you’re daemon is missing its UTF-8
> locales.
>
> This could be because you upgraded the daemon but did not upgrade the
> ‘glibc-utf8-locales’ or ‘glibc-locales’ you installed as root, no?

It's possible - I rarely do anything with the root profile, and wasn't
even aware that I had to keep it up to date.  Should I have to `guix
pull` and `guix upgrade` it regularly, as well as my user profile?

--
Josh Holland

bug#37662: substitution failure of nss-certs

[Josh Holland]

Hi Arun,

Arun Isaac  writes:
> I install glibc-locales as a system-wide package in my operating-system
> configuration. Perhaps that's what Ludo meant to say.

I probably should have mentioned in my initial report that this is Guix
running on top of a foreign distro (Arch).


--
Josh Holland

bug#37662: substitution failure of nss-certs

[Josh Holland]

Hi Ludovic,

Ludovic Courtès  writes:
>
>   cat /proc/PID/environ | xargs -0 echo
>

LANG=en_GB.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/bin 
INVOCATION_ID=1518aca749efa1593610e892c3a0 JOURNAL_STREAM=9:19872 
GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale 
GUIX=/gnu/store/f2zvgl9zz13r6rp89y0jjfj9f4jk5h9s-guix-command 
GUIX_STATE_DIRECTORY=/var/guix GUIX_CONFIGURATION_DIRECTORY=/etc/guix 
NIX_STORE_DIR=/gnu/store

--
Josh Holland

bug#37662: substitution failure of nss-certs

[Josh Holland]

Hi Ludo,

Ludovic Courtès  writes:
> Does
> /var/guix/profiles/per-user/root/guix-profile/lib/locale/*/en_GB.UTF-8
> exists?

Seems so (see below).

>   guix install glibc-locales

This was already installed too:

--8<
[root@spica ~]# guix install glibc-locales
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package 
and defining
`GUIX_LOCPATH', along these lines:

 guix package -i glibc-utf8-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

The following package will be upgraded:
   glibc-locales2.29 -> 2.29
/gnu/store/03nvilh2x4z07dxv7h13gh986vvgpnsf-glibc-locales-2.29

nothing to be done
[root@spica ~]# ls 
/var/guix/profiles/per-user/root/guix-profile/lib/locale/*/en_GB.UTF-8
LC_ADDRESS  LC_CTYPE   LC_MEASUREMENT  LC_MONETARY  LC_NUMERIC  
LC_TELEPHONE
LC_COLLATE  LC_IDENTIFICATION  LC_MESSAGES LC_NAME  LC_PAPERLC_TIME
--8<

--
Josh Holland

bug#37989: python2-numpy v0.17.3 fails to build

[Josh Holland]

Hi,

It seems that the update of python-numpy to 1.17.3 in
8e5fbd5dda93e137ff527cabe25989b28ab9e1c0 has broken the build of the
corresponding Python 2 package, both on my local machine and on the CI
server: http://ci.guix.gnu.org/build/1893145/details.

The log in Cuirass is incomplete, but the error in my build is the
following:

starting phase `build'
running "python setup.py" with command "build" and parameters ()
Traceback (most recent call last):
  File "", line 1, in 
  File "setup.py", line 31, in 
raise RuntimeError("Python version >= 3.5 required.")
RuntimeError: Python version >= 3.5 required.
command "python" "-c" "import setuptools, 
tokenize;__file__='setup.py';f=getattr(tokenize, 'open', 
open)(__file__);code=f.read().replace('\\r\\n', 
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "build" failed with 
status 1

Indeed, despite the assertion on
https://numpy.org/doc/1.17/user/building.html that Python 2.7 or 3.4 are
sufficient, the setup.py script explicitly checks that Python is at
least 3.5; see the upstream commit badf2901:

https://github.com/numpy/numpy/commit/badf2901ea040aa89dbb3c19e53c6b1b692cb489

Lots of packages including libreoffice transitively depend on
python2-numpy, so this needs some sort of resolution — perhaps simply
pinning python2-numpy to a previous version?  However, Python 2 will not
be maintained after the end of 2019, and I'm not sure if there is an
overall Guix-wide migration plan for python2-* packages.

--
Josh Holland

bug#38005: org.gtk.Settings.FileChooser glib schema missing "show-type-column" key

[Josh Holland]

Hi,

I'm using Guix on a foreign distro (Arch), and I have noticed that
Firefox as installed by pacman crashes frequently.  If I run it from a
terminal, I see that the error is the following:

(firefox:1166641): GLib-GIO-ERROR **: 15:05:20.437: Settings schema 
'org.gtk.Settings.FileChooser' does not contain a key named 'show-type-column'

Indeed, with some digging, I find that it is missing from the schema
installed by Guix, although present in the system-installed schema:

$ grep show-type-column 
$GUIX_PROFILE/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml 
|| echo 'not found'
not found
$ grep show-type-column 
/usr/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml


If I go chasing down the symlinks to see where the schemas come from, we
see that Guix has installed gtk+ 3.24.10, while the Arch package is
3.24.12:

$ ls -l 
$GUIX_PROFILE/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml
lrwxrwxrwx 2 root root 120 Jan  1  1970 
.guix-profile/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml 
-> 
/gnu/store/sf58vblawmpnr384zhi231z6fcc3kaaz-glib-schemas/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml
$ ls -l 
/gnu/store/sf58vblawmpnr384zhi231z6fcc3kaaz-glib-schemas/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml
lrwxrwxrwx 17 root root 120 Jan  1  1970 
/gnu/store/sf58vblawmpnr384zhi231z6fcc3kaaz-glib-schemas/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml
 -> 
/gnu/store/6x13nr57i1qml20kjl30l7b767cw0d0b-gtk+-3.24.10/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml
$ pacman -Qi gtk3
Name: gtk3
Version : 1:3.24.12+32+g39e28ab933-1
# ...snip...

I'm not sure whether a simple update of the gtk+ package would solve
this, especially as presumably it would trigger a lot of rebuilds.

--
Josh Holland

bug#38005: Acknowledgement (org.gtk.Settings.FileChooser glib schema missing "show-type-column" key)

[Josh Holland]

I just checked, and in fact staging already has 3.24.12, which contains
the missing key.  So I suppose this will be resolved when staging gets
merged.

Thanks,
--
Josh Holland

bug#36675: [PATCH] gnu: kodi: Disable intermittently failing test.

[Josh Holland]

As reported in , occasionally the
TestMassEvent.General test in kodi crashes with a mutex error.

* gnu/packages/patches/kodi-skip-testmasseventgeneral.patch: New file.
* gnu/packages/kodi.scm (kodi)[source]: Use it.
* gnu/local.mk: (dist_patch_DATA): Add it.
---
I have tested building the kodi-wayland package with this patch, and
it successfully builds and the tests pass.

 gnu/local.mk  |  1 +
 gnu/packages/kodi.scm |  3 +-
 .../kodi-skip-testmasseventgeneral.patch  | 59 +++
 3 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/kodi-skip-testmasseventgeneral.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index e2d922373e..4fc690c785 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1036,6 +1036,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/kodi-increase-test-timeout.patch\
   %D%/packages/patches/kodi-set-libcurl-ssl-parameters.patch   \
   %D%/packages/patches/kodi-skip-test-449.patch\
+  %D%/packages/patches/kodi-skip-testmasseventgeneral.patch \
   %D%/packages/patches/laby-make-install.patch \
   %D%/packages/patches/lcalc-default-parameters-1.patch\
   %D%/packages/patches/lcalc-default-parameters-2.patch\
diff --git a/gnu/packages/kodi.scm b/gnu/packages/kodi.scm
index 59ea11f812..04d879bd17 100644
--- a/gnu/packages/kodi.scm
+++ b/gnu/packages/kodi.scm
@@ -281,7 +281,8 @@ alternatives. In compilers, this can reduce the cascade of 
secondary errors.")
 "1m0295czxabdcqyqf5m94av9d88pzhnzjvyfs1q07xqq82h313p7"))
   (patches (search-patches "kodi-skip-test-449.patch"
"kodi-increase-test-timeout.patch"
-   
"kodi-set-libcurl-ssl-parameters.patch"))
+   "kodi-set-libcurl-ssl-parameters.patch"
+   "kodi-skip-testmasseventgeneral.patch"))
   (snippet
'(begin
   (use-modules (guix build utils))
diff --git a/gnu/packages/patches/kodi-skip-testmasseventgeneral.patch 
b/gnu/packages/patches/kodi-skip-testmasseventgeneral.patch
new file mode 100644
index 00..89fe60b598
--- /dev/null
+++ b/gnu/packages/patches/kodi-skip-testmasseventgeneral.patch
@@ -0,0 +1,59 @@
+This test has been intermittently failing since version 18.2 (see Guix
+bug 36675).
+
+438/521 Test #438: TestMassEvent.General 
Child aborted***Exception:  
 0.82 sec
+Note: Google Test filter = TestMassEvent.General
+[==] Running 1 test from 1 test case.
+[--] Global test environment set-up.
+[--] 1 test from TestMassEvent
+[ RUN  ] TestMassEvent.General
+[   OK ] TestMassEvent.General (105 ms)
+[--] 1 test from TestMassEvent (105 ms total)
+
+[--] Global test environment tear-down
+[==] 1 test from 1 test case ran. (142 ms total)
+[  PASSED  ] 1 test.
+kodi-test: ../nptl/pthread_mutex_lock.c:434: __pthread_mutex_lock_full: 
Assertion `robust || (oldval & FUTEX_OWNER_DIED) == 0' failed.
+
+---
+ xbmc/threads/test/TestEvent.cpp | 19 +--
+ 1 file changed, 9 insertions(+), 10 deletions(-)
+
+diff --git a/xbmc/threads/test/TestEvent.cpp b/xbmc/threads/test/TestEvent.cpp
+index 40e644c0ed..8fe329caa4 100644
+--- a/xbmc/threads/test/TestEvent.cpp
 b/xbmc/threads/test/TestEvent.cpp
+@@ -592,17 +592,17 @@ template  void 
RunMassEventTest(std::vector>& m, boo
+ }
+
+
+-TEST(TestMassEvent, General)
+-{
+-  g_event = new CEvent();
++// TEST(TestMassEvent, General)
++// {
++//   g_event = new CEvent();
+
+-  std::vector> m(NUMTHREADS);
+-  for(size_t i=0; i> m(NUMTHREADS);
++//   for(size_t i=0; i

bug#40388: Calibre test suite fails

[Josh Holland]

Hi,

Both on my local machine and on the CI[0], the Calibre test suite has
been failing with the following error:

==
ERROR: test_msgpack (calibre.test_build.BuildTest)
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-calibre-3.42.0.drv-0/calibre-3.42.0/src/calibre/test_build.py",
 line 124, in test_msgpack
self.assertEqual(obj, msgpack_loads(s))
  File 
"/tmp/guix-build-calibre-3.42.0.drv-0/calibre-3.42.0/src/calibre/utils/serialize.py",
 line 113, in msgpack_loads
return msgpack.unpackb(dump, ext_hook=msgpack_decoder, raw=False, 
use_list=use_list)
  File 
"/gnu/store/z7dz4iiaivmadhk0x50qs5zv3rwykrmd-python2-msgpack-1.0.0/lib/python2.7/site-packages/msgpack/fallback.py",
 line 129, in unpackb
ret = unpacker._unpack()
  File 
"/gnu/store/z7dz4iiaivmadhk0x50qs5zv3rwykrmd-python2-msgpack-1.0.0/lib/python2.7/site-packages/msgpack/fallback.py",
 line 666, in _unpack
"%s is not allowed for map key" % str(type(key))
ValueError:  is not allowed for map key

--

This is happening on both staging and master.  There have been no
changes to the calibre package itself since January.  I have run a git
bisect and the offending change appears to be in commit
66ab2f5e3a0df665f6e39203aedd2bf4812e6a71, when python-msgpack was
updated to version 1.0.0.

[0]: e.g. http://ci.guix.gnu.org/build/2485977/details

--
Josh Holland

bug#40388: Reported upstream to Calibre

[Josh Holland]

I've reported this bug as
https://bugs.launchpad.net/calibre/+bug/1870541.  I also found the
backwards-incompatible change in msgpack which is the culprit of this:

* Default value of strict_map_key is changed to True to avoid
  hashdos. You need to pass strict_map_key=False if you have data which
  contain map keys which type is not bytes or str.

(from <https://pypi.org/project/msgpack/>)

I can prepare a patch (both within the Guix build system and to send
upstream) which fixes this, though I'm not sure what hashdos are or
whether they are actually important to avoid in this case.

--
Josh Holland

bug#40929: go-sctp build failure: "protocol not supported"

[Josh Holland]

7191f8-checkout/sctp_unsupported.go'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/sctp_unsupported.go'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/LICENSE'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/LICENSE'
`/gnu/store/flhrga7qm4czsas6h0vd99wnydqxsgwh-go-sctp-0.0.0-1.07191f8-checkout/example/sctp.go'
 -> 
`/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp/example/sctp.go'
phase `unpack' succeeded after 0.0 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded after 0.0 seconds
starting phase `patch-source-shebangs'
phase `patch-source-shebangs' succeeded after 0.0 seconds
starting phase `build'
WORK=/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/go-build625703083
github.com/ishidawataru/sctp
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile 
bytes=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/bytes.a
packagefile 
encoding/binary=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/encoding/binary.a
packagefile 
fmt=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/fmt.a
packagefile 
io=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/io.a
packagefile 
net=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/net.a
packagefile 
strconv=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/strconv.a
packagefile 
strings=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/strings.a
packagefile 
sync=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/sync.a
packagefile 
sync/atomic=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/sync/atomic.a
packagefile 
syscall=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/syscall.a
packagefile 
time=/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/linux_amd64/time.a
EOF
cd 
/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/src/github.com/ishidawataru/sctp
/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/tool/linux_amd64/compile
 -o $WORK/b001/_pkg_.a -trimpath "$WORK/b001=>" -p github.com/ishidawataru/sctp 
-complete -buildid Q1r1L3qH3YHBCsR6toPz/Q1r1L3qH3YHBCsR6toPz -goversion 
go1.13.9 -D "" -importcfg $WORK/b001/importcfg -pack -c=4 ./sctp.go 
./sctp_linux.go
/gnu/store/xacmln5jbjx28yb73cmp0v3i2g2wca8g-go-1.13.9/pkg/tool/linux_amd64/buildid
 -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a 
/tmp/go-cache/2b/2b41bc8c58fa2521411ed8cef888fe3c64490889db0d340a488431d7592f521f-d
 # internal
mkdir -p 
/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/pkg/linux_amd64/github.com/ishidawataru/
mv $WORK/b001/_pkg_.a 
/tmp/guix-build-go-sctp-0.0.0-1.07191f8.drv-0/pkg/linux_amd64/github.com/ishidawataru/sctp.a
rm -r $WORK/b001/
phase `build' succeeded after 0.3 seconds
starting phase `check'
--- FAIL: TestStreams (0.01s)
sctp_streams_test.go:34: failed to listen: protocol not supported
--- FAIL: TestSCTPListenerName (0.00s)
sctp_test.go:71: protocol not supported
--- FAIL: TestSCTPConcurrentAccept (0.00s)
sctp_test.go:86: protocol not supported
--- FAIL: TestSCTPCloseRecv (0.00s)
sctp_test.go:126: protocol not supported
FAIL
FAILgithub.com/ishidawataru/sctp0.018s
FAIL
command "go" "test" "github.com/ishidawataru/sctp" failed with status 1
builder for 
`/gnu/store/bc4sd2819gmy22dda1nhd179cacw7ny6-go-sctp-0.0.0-1.07191f8.drv' 
failed with exit code 1
build of 
/gnu/store/bc4sd2819gmy22dda1nhd179cacw7ny6-go-sctp-0.0.0-1.07191f8.drv failed
View build log at 
'/var/log/guix/drvs/bc/4sd2819gmy22dda1nhd179cacw7ny6-go-sctp-0.0.0-1.07191f8.drv.bz2'.
guix build: error: build of 
`/gnu/store/bc4sd2819gmy22dda1nhd179cacw7ny6-go-sctp-0.0.0-1.07191f8.drv' failed

I am running Guix on top of a foreign distro (Arch); I looked up some
recent builds of go-sctp on the CI server, with rather mixed results.
Some have succeeded, some failed, some never attempted (due to missing
dependencies, I assume), and most seem to have the output cut off.


--
Josh Holland

bug#40929: go-sctp build failure: "protocol not supported"

[Josh Holland]

Hi,

zimoun  writes:
>
> However, it seems fixed on core-updates.
>
> https://ci.guix.gnu.org/search?query=spec%3Acore-updates-core-updates+system%3Ax86_64-linux+docker-19.03.7

Ah, that's good.  I'll just wait for the (hopefully soon) core-updates
merge since this isn't essential to me.  If it is fixed, then presumably
this bug can be closed?

Thanks,

--
Josh Holland

bug#40929: go-sctp build failure: "protocol not supported"

[Josh Holland]

This now builds fine (in fact, it was substituted when I checked just
now, but `guix build --check` works with no errors).


--
Josh Holland