bug#40386: guix system init can't find file system by UUID, workaround results in broken boot
This can be closed, now that we have F2FS support. Although maybe the error message could be better for file systems that are not supported. Right now the use has no way to distinguish whether `guix system` failed to find their device because they mistyped the UUID or because it doesn't even support their file system of choice at all.
bug#41433: Sway fails at configure step
Sway package is broken, when it gets to configure it fails with: ``` ../source/meson.build:1:0: ERROR: lexer ``` No idea what that means, as I barely know Meson.
bug#41432: system argument for guix package
Hi, It would be nice to have a --system argument for guix package. For instance, on an x86_64 box, it would be nice to list all 32-bit packages. Thanks, Barrett
bug#41429: Shepherd Sometimes Crashes
I am running shepherd as a userspace service manager on an alien distro. Occassionally (often enough as to cause concern), Shepherd is crashing. I am unable to narrow down a cause, but anecdotally, it seems to happen more often when a service it's managing fails repeatedly and is disabled. I'm running `strace` against the Shepherd process in an attempt to submit a better bug report, but this is all I have for now. Maybe others have also seen this behavior. -- Katherine
bug#33517: Problem booting when using btrfs subvolume for /gnu/store
Hi Christopher, Christopher Baines writes: > Maxim Cournoyer writes: > >> Hello, >> >> Christopher Baines writes: >> >>> I'm loosing track of this issue a bit, as I've been dealing with it for >>> a while. I have a machine that I've setup where /gnu/store is a btrfs >>> subvolume. I do this so that I can make flexible use of the space on >>> that btrfs filesystem. >>> >>> Unfortunately, the grub configuration generated for this doesn't seem to >>> account for this, and so it requires some tweaking to get it to boot. >> >> [...] >> >> This issue is now resolved as of commit >> 12df6684b983507b2a73e14f45d28a71cddfb3b1 on master. > > Thanks Maxim, I'm guessing the commit that fixes this is > b460ba7992a0b4af2ddb5927dcf062784539ef7b. > > Chris Yes (and the two supporting commits right before this one). The one I pointed to includes a news entry. Maxim
bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)
On Wed, May 20, 2020 at 11:09:37PM +0200, Pierre Neidhardt wrote: > Leo Famulari writes: > > > `guix size` also accounts for build-time dependencies, and Docker is > > written in Go. > > Are you sure about this? Marius seems to disagree unless I'm > misunderstanding the two statements. I thought I was correct but it's certainly possible I'm wrong! The manual isn't clear IMO and I don't have time to read the code. The `guix graph` suggestions should help get to the bottom of it, though. signature.asc Description: PGP signature
bug#41413: guix-install.sh broken on Gentoo
Hello, I'm working on adding a gentoo VM to my test farm, so I'll have a look at the problem, and hopefully fix it properly. -- Vincent Legoll
bug#41241: [PATCH] gnu: fontconfig: Add replacement with font-dejavu instead of gs-fonts.
Leo Famulari writes: > On Sun, May 17, 2020 at 04:50:12PM +0200, Marius Bakke wrote: >> This is a hack to make (some) fonts working when users don't have fonts >> specified in their system configuration, and (crucially) places where >> the fontconfig cache may be unavailable such as 'guix pack's. >> >> I'm not sure whether font-dejavu is a good replacement here. Another >> approach could be to convert gs-fonts to TrueType or OpenType format. >> >> Thoughts? I don't know much about fonts and would appreciate feedback. > > I think you should push right away, assuming that it helps and doesn't > rebuild the world. I pushed the patch as ab9de8cfb0525ef43668712ac898707f97f9a620. I verified that it fixes the immediate problem with fonts in the Guix manual (#41282) as well as 'guix pack' (#41344). It should also provide a decent fallback for cases where the user did not explicitly install any fonts such as in #41241. Hoping for angry reports now about why such a poor replacement font was chosen. ;-) signature.asc Description: PGP signature
bug#41160: Log for another *.drv
See attached. l0yrylg3w0h7mwd4l41amhpyz5q9z5-sbcl-cffi-libffi-0.21.0.drv.bz2 Description: application/bzip
bug#41375: guix substitute: error: TLS error in procedure 'handshake'
Igor Gajsin writes: > Hi, > > I run the command `guix pull --dry-run` and got the error: > > > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% >\ > > > /substitute: guix substitute: error: TLS error in procedure 'handshake': The > TLS connection was non-properly terminated. Is this error consistent for you? It looks like it could be a transient network issue. signature.asc Description: PGP signature
bug#41213: boost-for-mysql fails to build
On 20.05.20 22:31, Marius Bakke wrote: > Do you use any packages that depend on this? I somehow had mysql in my package list, but replacing it with mariadb is sufficent.
bug#41213: boost-for-mysql fails to build
Jonathan Brielmaier writes:
> `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"
> ```
I think our efforts are better spent on updating the packages that use
this ancient Boost instead of hacking it to work with Python 3.8.
Though disabling Python support might work around the issue for now...
Do you use any packages that depend on this?
signature.asc
Description: PGP signature
bug#41418: Rendered graphs in manual have improperly rendered text
merge 41282 41418 thanks Carlo Zancanaro writes: > Apologies, immediately after sending this email I saw #41282, > which is the same bug. I don't know whether it's better to close > this, or to merge them, so I'll leave that up to someone else to > decide. :) I merged them. The main difference is that you will get a notification when it gets fixed. It also aids if someone searches for the problem and finds this report, but not the other.
bug#33517: Problem booting when using btrfs subvolume for /gnu/store
Maxim Cournoyer writes: > Hello, > > Christopher Baines writes: > >> I'm loosing track of this issue a bit, as I've been dealing with it for >> a while. I have a machine that I've setup where /gnu/store is a btrfs >> subvolume. I do this so that I can make flexible use of the space on >> that btrfs filesystem. >> >> Unfortunately, the grub configuration generated for this doesn't seem to >> account for this, and so it requires some tweaking to get it to boot. > > [...] > > This issue is now resolved as of commit > 12df6684b983507b2a73e14f45d28a71cddfb3b1 on master. Thanks Maxim, I'm guessing the commit that fixes this is b460ba7992a0b4af2ddb5927dcf062784539ef7b. Chris signature.asc Description: PGP signature
bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)
Le 20 mai 2020 12:43:16 GMT-04:00, Leo Famulari a écrit : >On Wed, May 20, 2020 at 08:16:32AM +0200, Pierre Neidhardt wrote: >> Danny Milosavljevic writes: >> >> > On Tue, 19 May 2020 14:25:23 -0400 >> > Leo Famulari wrote: >> > >> >> guix gc --references >> > >> > Doesn't contain go. >> >> So why did `guix size` contain go? > >`guix size` also accounts for build-time dependencies, and Docker is >written in Go. As I said: guix graph -t references --path /gnu/store/…-docker /gnu/store/…-go Should give you the shortest path from docker to go, looking only at references.
bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)
Leo Famulari writes: > On Wed, May 20, 2020 at 08:16:32AM +0200, Pierre Neidhardt wrote: >> Danny Milosavljevic writes: >> >> > On Tue, 19 May 2020 14:25:23 -0400 >> > Leo Famulari wrote: >> > >> >> guix gc --references >> > >> > Doesn't contain go. >> >> So why did `guix size` contain go? > > `guix size` also accounts for build-time dependencies, and Docker is > written in Go. `guix size` only looks at the closure size. One of Dockers dependencies must be carrying the spurious Go reference (guix graph might help here). signature.asc Description: PGP signature
bug#41406: Docker package retains Go references (was Re: Guix closure size of a system?)
On Wed, May 20, 2020 at 08:16:32AM +0200, Pierre Neidhardt wrote: > Danny Milosavljevic writes: > > > On Tue, 19 May 2020 14:25:23 -0400 > > Leo Famulari wrote: > > > >> guix gc --references > > > > Doesn't contain go. > > So why did `guix size` contain go? `guix size` also accounts for build-time dependencies, and Docker is written in Go.
bug#41419: FreeCAD incompatible with python 3.8
Hi Guix! When core-updates was merged in 4bdf4182fe080c3409f6ef9b410146b67cfa2595 FreeCAD got broken due to what seems to be an outstanding issue: https://forum.freecadweb.org/viewtopic.php?t=38982 This issue is to note that we might try to send a patch upstream, or patch the freecad package with method provided in that thread. - John
bug#33517: Problem booting when using btrfs subvolume for /gnu/store
Hello, Christopher Baines writes: > I'm loosing track of this issue a bit, as I've been dealing with it for > a while. I have a machine that I've setup where /gnu/store is a btrfs > subvolume. I do this so that I can make flexible use of the space on > that btrfs filesystem. > > Unfortunately, the grub configuration generated for this doesn't seem to > account for this, and so it requires some tweaking to get it to boot. [...] This issue is now resolved as of commit 12df6684b983507b2a73e14f45d28a71cddfb3b1 on master. Closing! Maxim
bug#41418: Rendered graphs in manual have improperly rendered text
Apologies, immediately after sending this email I saw #41282, which is the same bug. I don't know whether it's better to close this, or to merge them, so I'll leave that up to someone else to decide. :)
bug#41418: Rendered graphs in manual have improperly rendered text
I was looking at the manual for the guix graph command today, and I noticed that the text in the images isn't being rendered properly. Instead of legible characters, it's just boxes. For example: https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph.html#Invoking-guix-graph I looked through all the images and it looks like only the graphs are affected (ie. the installer screenshots and guix size output looked fine), however all of the graphs are affected.
