bug#41413: guix-install.sh broken on Gentoo

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hullo,

ZC via web 写道：
guix-install.sh calls "update-rc.d", which doesn't exist on a 
Gentoo system. Instead of trying to support all possible init 
systems, or make assumptions regarding how the init system 
works, I'd suggest simply dropping support for anything other 
than upstart and/or systemd.


I think we can safely assume that if ‘update-rc.d’ exists it will 
work a certain way (i.e. there aren't multiple incompatible 
‘update-rc.d’s around), and that the real bug is that the script 
checks for a random directory in /etc instead.


It should test for the script(s) it uses, not related symptoms.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#41213: boost-for-mysql fails to build

[Jonathan Brielmaier]

`tools/build/src/engine/execunix.cpp` was named
`tools/build/src/engine/execunix.c` before. So the following patch
allows to build boost@1.59 again.

```
diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
index 2f2ca289ab..d44b534939 100644
--- a/gnu/packages/boost.scm
+++ b/gnu/packages/boost.scm
@@ -120,10 +120,11 @@
  (let ((icu (assoc-ref inputs "icu4c"))
(python (assoc-ref inputs "python"))
(out (assoc-ref outputs "out")))
-   (substitute* '("libs/config/configure"
-  "libs/spirit/classic/phoenix/test/runtest.sh"
-  "tools/build/src/engine/execunix.cpp"
-  "tools/build/src/engine/Jambase")
+   (substitute* (append
+ (find-files "tools/build/src/engine/"
"execunix\\.c.*")
+ '("libs/config/configure"
+
"libs/spirit/classic/phoenix/test/runtest.sh"
+   "tools/build/src/engine/Jambase"))
  (("/bin/sh") (which "sh")))

(setenv "SHELL" (which "sh"))
```

Although it fails with
```
libs/python/src/converter/builtin_converters.cpp: In function ‘void*
boost::python::converter::{anonymous}::convert_to_cstring(PyObject*)’:
libs/python/src/converter/builtin_converters.cpp:51:35: error: invalid
conversion from ‘const void*’ to ‘void*’ [-fpermissive]
   return PyUnicode_Check(obj) ? _PyUnicode_AsString(obj) : 0;

"g++"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall
-pthread -fPIC -m64  -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG
 -I"."
-I"/gnu/store/q9rm8h9imazsq2c4qiv2yjpvlvliywqb-python-3.8.2/include/python3.8"
-c -o
"bin.v2/libs/python/build/gcc-7.5.0/release/threading-multi/converter/builtin_converters.o"
"libs/python/src/converter/builtin_converters.cpp"
```

bug#41413: guix-install.sh broken on Gentoo

[ZC via web]

guix-install.sh calls "update-rc.d", which doesn't exist on a Gentoo system. 
Instead of trying to support all possible init systems, or make assumptions 
regarding how the init system works, I'd suggest simply dropping support for 
anything other than upstart and/or systemd. Users of smaller distros using 
unusual/traditional init systems can add support for guix theirself. The safest 
and most portable option would likely be to simply point to the init script at 
the end of the install, and tell the user to copy that file to the proper 
directory and enable it, copy and modify it to fit their system, or use it as a 
template for whatever their init system happens to be. It's less user-friendly 
in the "run it and forget it" sense, but it won't break a user's already 
working system, or error out in new and fun ways.

bug#41413: guix-install.sh broken on Gentoo

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Take it away, ZombieChicken:


signature.asc
Description: PGP signature

bug#41409: “guix pull” should show a progress bar for channel updates

[Ricardo Wurmus]

When I run “guix pull” (or “guix time-machine”) I see this message

   Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...

followed by disconcerting silence.  I can’t tell if it’s doing
something, nor can I see what the progress is.

Would be nice to have a progress bar or at least a spinner.

-- 
Ricardo

bug#22883: Authenticating a Git checkout

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> The list of authorized committers is meant to be stored in a
> ‘.guix-authorizations’ file in each branch of the channel.  It is
> essentially a list of fingerprints:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-openpgp=f145a2d1a982cc841c7ccae3334d4783dad24a1e
>
> To accept a new committer, an authorized committer must add its key to
> this file in the branch(es) where that person is expected to commit.
> The format currently accepts additional data for each fingerprint.  It’s
> currently ignored, but I thought it could be useful in the future, for
> instance if we want to associate a file pattern with a key.
>
> A commit is considered “authorized” if and only if its signing key is
> listed in the ‘.guix-authorizations’ file of its parent commit(s).

The good news with this model is that an adversary cannot trick users
into fetching an unrelated branch where the authorizations would be
different: they can always detect that it’s a disconnected branch or
that it’s not a fast-forward pull.

The bad news is that this also prevents “unauthorized forks” in general.
Unless Guix folks explicitly push a commit authorizing the key of the
person who forks, commits by that person will appear as unauthorized.

So we need an extra mechanism to say: “this fork starts here”.  However,
modifications to that piece of information must be detectable so that
one cannot serve a malicious fork that pretends to forego history.

Ludo’.

bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)

[Danny Milosavljevic]

Hi Leo,

> Then your patch works!

ok!

Pushed to guix master as commit f523eaba7b5460937a230a824550243d75e5f1dc.



pgpa1ubZ540cv.pgp
Description: OpenPGP digital signature

bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)

[Leo Famulari]

On Tue, May 19, 2020 at 08:32:34PM +0200, Danny Milosavljevic wrote:
> On Tue, 19 May 2020 14:25:23 -0400
> Leo Famulari  wrote:
> 
> > guix gc --references
> 
> Doesn't contain go.

Then your patch works!


signature.asc
Description: PGP signature

bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)

[Julien Lepiller]

Le 19 mai 2020 14:32:34 GMT-04:00, Danny Milosavljevic  
a écrit :
>On Tue, 19 May 2020 14:25:23 -0400
>Leo Famulari  wrote:
>
>> guix gc --references
>
>Doesn't contain go.

You can try guix graph -t references --path /gnu/store/…-docker /gnu/store/…-go

That should tell you which package references go and how it gets in the closure 
of docker.

bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)

[Danny Milosavljevic]

On Tue, 19 May 2020 14:25:23 -0400
Leo Famulari  wrote:

> guix gc --references

Doesn't contain go.


pgp7v_m9BPpka.pgp
Description: OpenPGP digital signature

bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)

[Leo Famulari]

On Tue, May 19, 2020 at 08:16:41PM +0200, Danny Milosavljevic wrote:
> Hi Leo,
> 
> the patch below makes the grep return nothing, but guix size still contains 
> go.

What about `guix gc --references /gnu/store/...-docker`?

> 
> diff --git a/gnu/packages/docker.scm b/gnu/packages/docker.scm
> index c95ca3f9d7..bf009a792b 100644
> --- a/gnu/packages/docker.scm
> +++ b/gnu/packages/docker.scm
> @@ -544,7 +544,9 @@ built-in registry server of Docker.")
> (install-file (string-append 
> "bundles/dynbinary-daemon/dockerd-"
>  (getenv "VERSION"))
>   out-bin)
> -   #t))
> +   #t)))
> + (add-after 'install 'remove-go-references
> +   (assoc-ref go:%standard-phases 'remove-go-references)
>  (inputs
>   `(("btrfs-progs" ,btrfs-progs)
> ("containerd" ,containerd)   ; for containerd-shim
> 




signature.asc
Description: PGP signature

bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)

[Danny Milosavljevic]

Hi Leo,

the patch below makes the grep return nothing, but guix size still contains go.

diff --git a/gnu/packages/docker.scm b/gnu/packages/docker.scm
index c95ca3f9d7..bf009a792b 100644
--- a/gnu/packages/docker.scm
+++ b/gnu/packages/docker.scm
@@ -544,7 +544,9 @@ built-in registry server of Docker.")
(install-file (string-append "bundles/dynbinary-daemon/dockerd-"
 (getenv "VERSION"))
  out-bin)
-   #t))
+   #t)))
+ (add-after 'install 'remove-go-references
+   (assoc-ref go:%standard-phases 'remove-go-references)
 (inputs
  `(("btrfs-progs" ,btrfs-progs)
("containerd" ,containerd)   ; for containerd-shim



pgp6T2TPbsHnX.pgp
Description: OpenPGP digital signature

bug#41387: "Building from Git" on foreign distro starting with NO guix?

[Bengt Richter]

Hi Julien,

On +2020-05-19 08:03:37 -0400, Julien Lepiller wrote:
> Le 18 mai 2020 23:07:42 GMT-04:00, Bengt Richter  a écrit :
> >Hi,
> >
> >[~/wb/guix110git/guix]$ ./configure --prefix=$(realpath ./mybuild)
> >checking for a BSD-compatible install... /usr/bin/install -c
> >checking whether build environment is sane... yes
> >...
> >...
> >checking pkg-config is at least version 0.9.0... yes
> >configure: checking for guile 3.0
> >configure: checking for guile 2.2
> >configure: found guile 2.2
> >checking for guile-2.2... /usr/bin/guile-2.2
> >checking for Guile version >= 2.2... 2.2.4
> >checking for guild-2.2... /usr/bin/guild-2.2
> >checking for guile-config-2.2... /usr/bin/guile-config-2.2
> >checking for GUILE... yes
> >checking if (gnutls) is available... no
> >configure: error: The Guile bindings of GnuTLS are missing; please
> >install them.
> >--8<---cut here---end--->8---
> >
> >Well, it was looking for guile 3.0 and my foreign distro only has 2.2.4
> >--8<---cut here---start->8---
> >guile (GNU Guile) 2.2.4
> >Packaged by Debian (2.2.4-deb+1-2)
> >Copyright (C) 2018 Free Software Foundation, Inc.
> >--8<---cut here---end--->8---
> >which it seemed ok with, but I don't seem to be able get my distro's
> >GnuTLS
> >hooked up with this installation procedure, and suspect a GnuTLS/Guile
> >version
> >mismatch problem or such, but then I ran out of enthusiasm :)
> 
> As you can see, configure looks for guile 3.0, fails and falls back to guile 
> 2.2, which it finds as /usr/bin/guile-2.2.
> 
> Gnutls provides guile bindings, but they are not necessarily built by your 
> distribution. From my experiments with debian/hurd, the bindings were not 
> present, so probably the same with debian/linux? You'll probably have to 
> checkout gnutls and build the bindings.
> 
> The configure script only checks that the guile it found (your 2.2) can load 
> the (gnutls) module, so there cannot be a version mismatch, unless debian 
> built the gnutls module with guile 3.0. Check with your distribution what 
> files are installed with the gnutls package. There should be some in 
> /usr/lib/guile/.
> 
> You'll need to look at the dependencies, some of them are probably not 
> provided by debian yet. I remember some discussions about creating a debian 
> package of guix. If this was accepted, then the dependencies must be 
> available at least in unstable. You might want to check.
>

Thanks for your tips!
I also went on to read Pjotr Prins' extensive notes on installing [1].

Looks like he can say "Been there, done that" re most install travails,
and IIUC he recommends against "Building from Git" as step 1, advising
to use a binary install first, and then use guix tools to hack further in a 
full repo.

BTW, he suggests a recursive clone, but I didn't see what that really does or 
entails.
Not sure I want to download the entire history of all development branches of 
guix,
if that's what it means :)

(re that: it would be nice to see an approximate download size when advice to 
download
appears in docs, for those who pay for GBs ;-)

Perhaps 14.1 in the docs should be updated with a reference to [1] and to 
suggest (emphatically?)
there in 14.1 (as it does elsewhere) that the easier path will be to do a 
binary install first?
And also un-mix directions for the two kinds of install activities!

Leading people into frustrating experiences can't be good PR for guix. Cui bono?

Anyway, I think I'll give up on Building from Git for now, and go back to 
monkeying with
guix-install.sh (making it incrementally restartable to avoid re-downloading 
etc. and
seeing how far I can factor out root both in the script and the resulting guix 
daemonium) :)

[1] https://gitlab.com/pjotrp/guix-notes/-/blob/master/INSTALL.org

Thanks again.

-- 
Regards,
Bengt Richter

bug#41396: java-kafka-clients fails tests

[Marius Bakke]

merge 41396 40718
thanks

Ricardo Wurmus  writes:

> java-kafka-clients has a failing test:
>
> [junit] Running org.apache.kafka.common.network.SslTransportLayerTest
> [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
> [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
> further details.
> [junit] Tests run: 31, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
> 8.072 sec
>
> The SLF4J failure seems to be unrelated (other tests also have this warning).

It only seems to happen on big-memory systems (but consistently so).
Björn did some investigation here:

  https://issues.guix.gnu.org/40718#2

If you can reproduce it, please help!  :-)

bug#41344: Font broken in GUI application with guix pack

[Marius Bakke]

Alexandros Theodotou  writes:

> Hi,
>
> This is the command I ran to generate a pack:
> guix pack -RR -S /opt/zrythm/bin=bin -L . zrythm
>
> I then tried moving this pack to a VM running another distro
> (archlinux) and all letters are shown as boxes. I have asked other
> people to test it on other distros, including debian, and they reported
> the same issue.
>
> I am not exactly sure what is missing. Attaching a screenshot of what
> it looks like.

Can you try the patch posted at
 ?

When no fonts are installed in the common Guix profiles, applications
only "see" the font hard-coded into fontconfig, which happens to be
broken[*] since the recent 'core-updates' merge for any application
using Pango (such as GTK+).

[*] because fontconfig currently uses "gs-fonts", which are bitmap only,
and Pango no longer supports bitmap fonts[**]
[**] https://gitlab.gnome.org/GNOME/pango/issues/386


signature.asc
Description: PGP signature

bug#41344: Font broken in GUI application with guix pack

[Alexandros Theodotou]

> Did it work roughly before the ‘core-updates’ merge?

This is the first time I tried `guix pack` so I don't know.

> As discussed on IRC, could you check “strace -f” the program and
> check
> where it’s looking for fonts (TTFs?)?

I'm not really sure what to look for. Here is the strace -f output: 
https://www.zrythm.org/downloads/trace.text.tar.gz

The package I'm trying to pack is zrythm-next from here:
https://git.zrythm.org/cgit/guix-repo/tree/audio.scm

Thanks,
Alex

On Tue, 2020-05-19 at 15:43 +0200, Ludovic Courtès wrote:
> 
> 
> 
> Our ‘fontconfig’ package searches ~/.guix-profile/share/fonts and
> /run/current-system/profile/share/fonts by default, which obviously
> doesn’t work on foreign distros.
> 
> 
> 
> Thanks,
> Ludo’.


signature.asc
Description: This is a digitally signed message part

bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)

[Leo Famulari]

The Docker package should not refer to the Go compiler after it is
built:

On Tue, May 19, 2020 at 12:22:28PM -0400, Leo Famulari wrote:
> On Tue, May 19, 2020 at 05:58:54PM +0200, Pierre Neidhardt wrote:
> > I haven't looked at the details, but
> > 
> > --8<---cut here---start->8---
> > > guix size docker
> > store item   total
> > self
> > /gnu/store/w8gjhcw6a16rk1dvxa97bz2znal5fihm-go-1.13.9  639.1   
> > 350.7  28.2%
> > --8<---cut here---end--->8---
> > 
> > Then
> > 
> > --8<---cut here---start->8---
> > > grep w8gjhcw6a16rk1dvxa97bz2znal5fihm dockerd
> > Binary file dockerd matches
> > --8<---cut here---end--->8---
> 
> I don't think that package is using the go-build-system, so that is
> probably the reason for the bogus reference.

bug#41264: Bootstrap packages fail to build.

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hello Mathieu,

>> So stat, lstat, and all other related function will return -EOVERFLOW
>> unless their 64 bits stat64, lstat64 counterpart is used.
>>
>> So I think this means that one cannot build the Guix bootstrap toolchain on 
>> an
>> NVME disk.
>
> After further investigations I think that it is needed to patch GNU Mes
> to fix this bug.

Hmm, we need to patch Mes after all.  That's unfortunate.

> We would need to add three new syscalls for x86:
>
> #define SYS_stat640xc3
> #define SYS_lstat64   0xc4
> #define SYS_fstat64   0xc5
>
>
> lib/linux/stat.c should be modified this way:
>
> #if __i386__
> #define STAT_SYSCALL SYS_stat64
> #else
> #define STAT_SYSCALL SYS_stat
> #endif

Ah...the stat64 syscall is meant for i386; now it at starts making at
least some sense to me.

> int
> stat (char const *file_name, struct stat *statbuf)
> {
>   struct stat64 statbuf64;
>   int ret;
>
>   ret = _sys_call2 (STAT_SYSCALL, (long) file_name, (long) );
>
> #if __i386__
>   stat64_to_32(, statbuf);
> #else
>   *statbuf = statbuf64;
> #endif
>
>   return ret;
> }

That looks OK...

> Then we would need to create stat64_to_32 which could be inspired from
> __xstat64_conv from the glibc. Then, lstat and fstat64 would need to be
> patched the same way.
>
> This way, we would replicate the glibc behavior.

Beautiful, thanks for getting to the bottom of this.  Now that you
already have gone this far, would you like to whip-up a full patch for
GNU Mes?

To test it we may have to provide a tarball as we don't want to use XZ
and we don't have patch yet.  Or possibly we can download some
individual files ande overwrite them.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#41384: failing to build util-linux 2.35.1

[Marius Bakke]

Josh  writes:

> I'm consistently running into this error when running `guix pull`.
> What can I do to help debug?

Try using 'guix pull --keep-failed' and inspect the util-linux test
suite logs in /tmp/guix-build-util-linux-2.35.1.drv-0.

Did you intentionally disable binary substitutes?


signature.asc
Description: PGP signature

bug#41397: xfce4-terminal not reproducible

[Danny Milosavljevic]

--- /gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8-check
+++ /gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8
├── share
│ ├── gnome-control-center
│ │ ├── default-apps
│ │ │ ├── xfce4-terminal-default-apps.xml
│ │ │ │ │   --- 
/gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8-check/share/gnome-control-center/default-apps/xfce4-terminal-default-apps.xml
│ │ │ │ ├── +++ 
/gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8/share/gnome-control-center/default-apps/xfce4-terminal-default-apps.xml
│ │ │ │ │ @@ -2,14 +2,15 @@
│ │ │ │ │  
│ │ │ │ │  
│ │ │ │ │
│ │ │ │ │  
│ │ │ │ │Xfce Terminal Emulator
│ │ │ │ │محاكي طرفية Xfce
│ │ │ │ │ +  Emulador de terminal pa Xfce
│ │ │ │ │Эмулятар тэрмінала Xfce
│ │ │ │ │Xfce Терминален Емулатор
│ │ │ │ │Emulador de terminal de Xfce
│ │ │ │ │Emulátor terminálu Xfce
│ │ │ │ │Xfce-terminalemulator
│ │ │ │ │Xfce Terminal-Emulator
│ │ │ │ │Προσομοιωτής Tερματικού Xfce
│ ├── xfce4
│ │ ├── terminal
│ │ │ ├── colorschemes
│ │ │ │ ├── tango.theme
│ │ │ │ │ @@ -13,14 +13,15 @@
│ │ │ │ │  Name[en_GB]=Tango
│ │ │ │ │  Name[es]=Tango
│ │ │ │ │  Name[eu]=Tango
│ │ │ │ │  Name[fi]=Tango
│ │ │ │ │  Name[fr]=Tango
│ │ │ │ │  Name[gl]=Tango
│ │ │ │ │  Name[he]=טנגו
│ │ │ │ │ +Name[hr]=Tango
│ │ │ │ │  Name[hu]=Tangó
│ │ │ │ │  Name[hy_AM]=Tango
│ │ │ │ │  Name[id]=Tango
│ │ │ │ │  Name[ie]=Tango
│ │ │ │ │  Name[is]=Tangó
│ │ │ │ │  Name[it]=Tango
│ │ │ │ │  Name[ja]=Tango


pgpLdrUxq4OA1.pgp
Description: OpenPGP digital signature

bug#41397: xfce4-terminal not reproducible

[Marius Bakke]

Danny Milosavljevic  writes:

> output ‘/gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8’ of 
> ‘/gnu/store/c48jlbvl4n48gkq1g47mv5xf6hyk8dc8-xfce4-terminal-0.8.8.drv’ 
> differs from 
> ‘/gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8-check’ from 
> previous round
>
>
> guix master commit 67c0d7fb9a32065fb77f0f595299182c60db85f4.

Can you post diffoscope output?


signature.asc
Description: PGP signature

bug#41344: Font broken in GUI application with guix pack

[Ludovic Courtès]

Hi,

Alexandros Theodotou  skribis:

> This is the command I ran to generate a pack:
> guix pack -RR -S /opt/zrythm/bin=bin -L . zrythm
>
> I then tried moving this pack to a VM running another distro
> (archlinux) and all letters are shown as boxes. I have asked other
> people to test it on other distros, including debian, and they reported
> the same issue.
>
> I am not exactly sure what is missing. Attaching a screenshot of what
> it looks like.
>
> I tried adding a propagated input for font-cantarell, font-gnu-freefont 
> and font-dejavu just to see if it would work, without success.

Did it work roughly before the ‘core-updates’ merge?

Our ‘fontconfig’ package searches ~/.guix-profile/share/fonts and
/run/current-system/profile/share/fonts by default, which obviously
doesn’t work on foreign distros.

As discussed on IRC, could you check “strace -f” the program and check
where it’s looking for fonts (TTFs?)?

Thanks,
Ludo’.

bug#41394: java-testng: again nondeterministic test-failures?

[Julien Lepiller]

Le 19 mai 2020 05:27:45 GMT-04:00, "Björn Höfling" 
 a écrit :
>Does anyone else have the same problems?
>
>On my system java-testng sometimes fails nondeterministically within
>the check phase:
>
>===
>TestNG
>Total tests run: 1633, Failures: 2, Skips: 0
>===
>
>Failures in  :TestNG,  :Regression2
>test.thread.ParallelTestTest.verifyParallel()
>StackTrace:
> java.lang.AssertionError: 
>Expected size:<4> but was:<3> in:
><{59L=59L, 60L=60L, 62L=62L}>
>   at test.thread.ParallelTestTest.verifyExpected(Unknown Source)
>   at test.thread.ParallelTestTest.verifyParallel(Unknown Source)
>... Removed 24 stack frames 
>
>test.thread.ParallelTestTest.verifyParallel()
>StackTrace:
> java.lang.AssertionError: 
>Expected size:<4> but was:<3> in:
><{55L=55L, 56L=56L, 58L=58L}>
>   at test.thread.ParallelTestTest.verifyExpected(Unknown Source)
>   at test.thread.ParallelTestTest.verifyParallel(Unknown Source)
>... Removed 24 stack frames 
>
>
>Do others experience this too, or is it just my machine?
>
>On berlin, everything looks fine, that makes we wonder:
>
>https://ci.guix.gnu.org/search?query=%5Ejava-testng
>
>We had some problems in the past with other parallel tests:
>
>https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30526
>
>I also tried to update java-testng but that was not possible quickly,
>because of new/updated dependency-graph.
>
>Björn

During my work on getting a maven-build-system, I recently rebuilt testng 
multiple times, with no issue at all.

bug#41387: "Building from Git" on foreign distro starting with NO guix?

[Julien Lepiller]

Le 18 mai 2020 23:07:42 GMT-04:00, Bengt Richter  a écrit :
>Hi,
>
>[~/wb/guix110git/guix]$ ./configure --prefix=$(realpath ./mybuild)
>checking for a BSD-compatible install... /usr/bin/install -c
>checking whether build environment is sane... yes
>...
>...
>checking pkg-config is at least version 0.9.0... yes
>configure: checking for guile 3.0
>configure: checking for guile 2.2
>configure: found guile 2.2
>checking for guile-2.2... /usr/bin/guile-2.2
>checking for Guile version >= 2.2... 2.2.4
>checking for guild-2.2... /usr/bin/guild-2.2
>checking for guile-config-2.2... /usr/bin/guile-config-2.2
>checking for GUILE... yes
>checking if (gnutls) is available... no
>configure: error: The Guile bindings of GnuTLS are missing; please
>install them.
>--8<---cut here---end--->8---
>
>Well, it was looking for guile 3.0 and my foreign distro only has 2.2.4
>--8<---cut here---start->8---
>guile (GNU Guile) 2.2.4
>Packaged by Debian (2.2.4-deb+1-2)
>Copyright (C) 2018 Free Software Foundation, Inc.
>--8<---cut here---end--->8---
>which it seemed ok with, but I don't seem to be able get my distro's
>GnuTLS
>hooked up with this installation procedure, and suspect a GnuTLS/Guile
>version
>mismatch problem or such, but then I ran out of enthusiasm :)

As you can see, configure looks for guile 3.0, fails and falls back to guile 
2.2, which it finds as /usr/bin/guile-2.2.

Gnutls provides guile bindings, but they are not necessarily built by your 
distribution. From my experiments with debian/hurd, the bindings were not 
present, so probably the same with debian/linux? You'll probably have to 
checkout gnutls and build the bindings.

The configure script only checks that the guile it found (your 2.2) can load 
the (gnutls) module, so there cannot be a version mismatch, unless debian built 
the gnutls module with guile 3.0. Check with your distribution what files are 
installed with the gnutls package. There should be some in /usr/lib/guile/.

You'll need to look at the dependencies, some of them are probably not provided 
by debian yet. I remember some discussions about creating a debian package of 
guix. If this was accepted, then the dependencies must be available at least in 
unstable. You might want to check.

>I thought maybe I could cheat and find a path into the cloned repo,
>since
>all the magic has to be there somehow, but that way seems pretty
>kludgey.
>
>Any help past this GnuTLS obstacle is welcome!
>
>BTW, could I check out at a commit prior to the guile3 introduction
>so that my distro might have a matching GnuTLS for that?
>If so, which commit would be best?
>
>In the meanwhile, back to hacking guix-install.sh :)
>
>Thanks for reading.
>
>--
>Regards,
>Bengt Richter

bug#41400: Current biber version is incompatible with biblatex

[Mikhail Tsykalov]

When running biber the following error appears:

ERROR - Error: Found biblatex control file version 3.5, expected version 
3.4.
This means that your biber (2.11) and biblatex (3.12) versions are 
incompatible.

See compat matrix in biblatex or biber PDF documentation.

bug#41397: xfce4-terminal not reproducible

[Danny Milosavljevic]

output ‘/gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8’ of 
‘/gnu/store/c48jlbvl4n48gkq1g47mv5xf6hyk8dc8-xfce4-terminal-0.8.8.drv’ differs 
from ‘/gnu/store/7pjnp69halq4kmi9m0q896p8ss1qmscq-xfce4-terminal-0.8.8-check’ 
from previous round


guix master commit 67c0d7fb9a32065fb77f0f595299182c60db85f4.


pgpLFlRau3AQ3.pgp
Description: OpenPGP digital signature

bug#41396: java-kafka-clients fails tests

[Ricardo Wurmus]

java-kafka-clients has a failing test:

[junit] Running org.apache.kafka.common.network.SslTransportLayerTest
[junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
[junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
further details.
[junit] Tests run: 31, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
8.072 sec

The SLF4J failure seems to be unrelated (other tests also have this warning).

-- 
Ricardo

bug#41394: java-testng: again nondeterministic test-failures?

[Björn Höfling]

Does anyone else have the same problems?

On my system java-testng sometimes fails nondeterministically within
the check phase:

===
TestNG
Total tests run: 1633, Failures: 2, Skips: 0
===

Failures in  :TestNG,  :Regression2
test.thread.ParallelTestTest.verifyParallel()
StackTrace:
 java.lang.AssertionError: 
Expected size:<4> but was:<3> in:
<{59L=59L, 60L=60L, 62L=62L}>
at test.thread.ParallelTestTest.verifyExpected(Unknown Source)
at test.thread.ParallelTestTest.verifyParallel(Unknown Source)
... Removed 24 stack frames 

test.thread.ParallelTestTest.verifyParallel()
StackTrace:
 java.lang.AssertionError: 
Expected size:<4> but was:<3> in:
<{55L=55L, 56L=56L, 58L=58L}>
at test.thread.ParallelTestTest.verifyExpected(Unknown Source)
at test.thread.ParallelTestTest.verifyParallel(Unknown Source)
... Removed 24 stack frames 


Do others experience this too, or is it just my machine?

On berlin, everything looks fine, that makes we wonder:

https://ci.guix.gnu.org/search?query=%5Ejava-testng

We had some problems in the past with other parallel tests:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30526

I also tried to update java-testng but that was not possible quickly,
because of new/updated dependency-graph.

Björn



pgp493RmL_Vpp.pgp
Description: OpenPGP digital signature

bug#41264: Bootstrap packages fail to build.

[Mathieu Othacehe]

Hello,

> So stat, lstat, and all other related function will return -EOVERFLOW
> unless their 64 bits stat64, lstat64 counterpart is used.
>
> So I think this means that one cannot build the Guix bootstrap toolchain on an
> NVME disk.

After further investigations I think that it is needed to patch GNU Mes
to fix this bug.

We would need to add three new syscalls for x86:

--8<---cut here---start->8---
#define SYS_stat640xc3
#define SYS_lstat64   0xc4
#define SYS_fstat64   0xc5
--8<---cut here---end--->8---

lib/linux/stat.c should be modified this way:

--8<---cut here---start->8---
#if __i386__
#define STAT_SYSCALL SYS_stat64
#else
#define STAT_SYSCALL SYS_stat
#endif

int
stat (char const *file_name, struct stat *statbuf)
{
  struct stat64 statbuf64;
  int ret;

  ret = _sys_call2 (STAT_SYSCALL, (long) file_name, (long) );

#if __i386__
  stat64_to_32(, statbuf);
#else
  *statbuf = statbuf64;
#endif

  return ret;
}
--8<---cut here---end--->8---

Then we would need to create stat64_to_32 which could be inspired from
__xstat64_conv from the glibc. Then, lstat and fstat64 would need to be
patched the same way.

This way, we would replicate the glibc behavior.

Thanks,

Mathieu

bug#41390: Hunspell packages don't work in Libreoffice

[Pierre Neidhardt]

Installing hunspell-dict-fr has no effect on Libreoffice which does not
offer spell checking beyond English.

For now the only way to add extra dictionaries is to fetch them manually online.

Besides, we miss many hunspell dictionaries.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#35728: Tor & IceCat's TorButton shows it's connected but doesn't route the traffic

[Pierre Neidhardt]

I can confirm this issue and I've been experiencing it for almost a
year.
It used to work.

This is very embarrassing since our IceCat is misleading the users that
they are browsing anonymously while they are not.

Mark, any idea about this?

-- 
Pierre Neidhardt
https://ambrevar.xyz/