bug#53515: Solarus Quest Editor makes new quests read-only

[Jesse Gibbons]

1. Launch solarus-quest-editor (in package solarus-quest-editor)

2. File->New quest...

3. Make a new directory for the quest,  select that directory, click "Open"

A dialog pops up with an error like the following:

I believe this is likely because it recursively copies a template from 
/share/solarus-quest-editor/assets/initial_quest/ relative to the 
installed solarus-quest-editor to the destination and keeps permissions.


--
-Jesse Gibbons

bug#53710: guix pull fails

[Jesse Gibbons]

~$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 787b13a (279 new 
commits)...

Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git    787b13a
Computing Guix derivation for 'x86_64-linux'... \Backtrace:
  17 (primitive-load 
"/gnu/store/rx23w5k5nys4a2hjwcy4lampkhnslj3m-compute-guix-derivation")

In ice-9/eval.scm:
    155:9 16 (_ _)
    159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ice-9/boot-9.scm:
    152:2 14 (with-fluid* _ _ _)
    152:2 13 (with-fluid* _ _ _)
In ./guix/store.scm:
  2123:24 12 (run-with-store # 
# ?)

   1960:8 11 (_ #)
In ./guix/gexp.scm:
   296:22 10 (_ #)
   1180:2  9 (_ #)
   1046:2  8 (_ #)
    892:4  7 (_ #)
In ./guix/store.scm:
  2008:12  6 (_ #)
   1406:5  5 (map/accumulate-builds #7f691ce7e140> # ?)
  1421:15  4 (_ # 
("/gnu/store/gmi62pbnf0jfish26chd7pvfzs2rzlxa-guile-ssh-?" ?) ?)

  1421:15  3 (loop #f)
   733:11  2 (process-stderr # _)
In ./guix/serialization.scm:
   102:11  1 (read-int #)
 80:6  0 (get-bytevector-n* # 8)

./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
ERROR:
  1. &nar-error:
  file: #f
  port: #
guix pull: error: You found a bug: the program 
'/gnu/store/rx23w5k5nys4a2hjwcy4lampkhnslj3m-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"787b13a5d9df8f0cc7170de1b80cead68b516c66"; system: "x86_64-linux";

host version: "90a41fe388102d448b3f91a070e38a7680d2d568"; pull-version: 1).
Please report the COMPLETE output above by email to .

--
-Jesse Gibbons

bug#54121: Calibre doesn't display text in interface.

[Jesse Gibbons]

Calibre isn't displaying any text in its book view interface (see 
screenshot). Even after I delete all the calibre configuration files in 
.config and .local/share the problem persists. I do not know if this is 
specific to guix or a problem generally with Calibre  5.36.


~$ guix describe
Generation 47    Feb 19 2022 17:42:44    (current)
  guix f8aa889
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: f8aa8899e265a46fd3dff6c717ec484057ba2b68

This is the case when calibre is run in the following ways (with the 
cache and configs deleted in between):

~/guix-home/profile/bin/calibre

~/guix-profile/bin/calibre

guix shell calibre -- calibre

guix shell --pure calibre -- calibre

guix time-machine -- shell calibre -- calibre

--
-Jesse Gibbons

bug#53710: "guix pull" doesn't have nice error messages in case of network errors

[Jesse Gibbons]

On 3/2/22 06:14, Maxime Devos wrote:

Ludovic Courtès schreef op wo 02-03-2022 om 12:19 [+0100]:

./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
ERROR:
   1. &nar-error:
   file: #f
   port: #
guix pull: error: You found a bug: the program
'/gnu/store/rx23w5k5nys4a2hjwcy4lampkhnslj3m-compute-guix-
derivation'
failed to compute the derivation for Guix (version:
"787b13a5d9df8f0cc7170de1b80cead68b516c66"; system: "x86_64-linux";
host version: "90a41fe388102d448b3f91a070e38a7680d2d568"; pull-
version: 1).
Please report the COMPLETE output above by email to
.

Thanks for reporting the issue.  Unfortunately, I suspect it was
“just”
a transient issue (probably a networking issue while downloading
substitutes for guile-ssh, which we see in the backtrace).  It’s
unfortunate that it crashed like that.

Even if it's ‘only’ a networking issue, shouldn't it be reported
better?  When "guix package -u" fails due to networking errors, the
error messages are much clearer.  Why not the same for "guix pull"?
Perhaps the issue should be reopened?

Greetings,
Maxime.
A proper error message would at least ensure this particular kind of 
crash does not prompt the end user to send a bug report. It would seem 
the real bug is communication to the user, "you found a bug, report it 
to the developers." instead of "Network error. Try later."


--
-Jesse Gibbons

bug#65252: Renpy raises exception when opening save screen.

[Jesse Gibbons]

Here's a problem I diagnosed in the version of renpy installed by guix 
(19a7a824c35eae56ce56e2a460042fb7e2129234):

Problem: Save screen raises an exception
How to replicate:
1. launch a renpy project
2. Navigate to the save screen.
An exception is raised and the stack trace is dumped.
Cause: config.has_sync not set outside renpy/common/00sync.rpy which is 
deleted by guix (presumably for security reasons)
Proposed Solution: Set config.has_sync = None in a different file at a 
point while config.locked=False. If no suitable file can be found, 
perhaps create renpy/common/00guix.rpy using a patch?


--
-Jesse Gibbons

bug#65253: Renpy-launcher raises exception when opening editor.

[Jesse Gibbons]

Here's a problem I diagnosed in the version of renpy installed by guix 
(hash 19a7a824c35eae56ce56e2a460042fb7e2129234):

Problem: Editor won't open, raises exception.
How to replicate:
1. Run renpy-launcher
2. Click any of the files under Edit File.
An exception is raised and the stack trace is dumped.
Cause: Editor files (*.edit.py) are not copied at install.
Proposed Solution: Copy editor files at install. I frankly don't care 
about Visual Studio Code or Atom, but at minimum "launcher/None.edit.py" 
and "launcher/System Editor.edit.py" must be included or the editor 
function won't work.


--
-Jesse Gibbons

bug#65253: Acknowledgement (Renpy-launcher raises exception when opening editor.)

[Jesse Gibbons]

It turns out 'Visual Studio Code (System).edit.py' is required to fix 
this. I recommend a patch that removes the Visual Studio Code (system 
and 'official') and Atom editor options, but that could be just my own 
preference. Please do not remove the None or System Editor options.


Until a patch is sent to fix this issue, concerned users may work around 
it by creating a directory in the configured projects directory and 
copying 'None.edit.py', 'System Editor.edit.py', and 'Visual Studio Code 
(System).edit.py' from the source into that directory. 'Visual Studio 
Code (System).edit.py' can contain the contents of either of the 
alternatives.

bug#42217: Build failure: kdenlive

[Jesse Gibbons]

Though I am working on this in a personal fork channel, I can confirm 
using time-machine that it is also an issue in guix's master branch.


Closest Commit (in guix master): 2ca4ae2993e20a1415fa25acf8fd6b993ee48c18

Since the build system uses multiple threads, the log itself is a mess. 
Here's what it says when it fails.


-

cd /tmp/guix-build-kdenlive-18.08.1.drv-0/build && 
/gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/bin/cmake 
-E cmake_depends "Unix Makefiles" /tmp/guix-build-kdenlive-18.08
.1.drv-0/source 
/tmp/guix-build-kdenlive-18.08.1.drv-0/source/thumbnailer 
/tmp/guix-build-kdenlive-18.08.1.drv-0/build 
/tmp/guix-build-kdenlive-18.08.1.drv-0/build/thumbnailer /tmp/guix-buil
d-kdenlive-18.08.1.drv-0/build/thumbnailer/CMakeFiles/mltpreview.dir/DependInfo.cmake 
--color=
/tmp/guix-build-kdenlive-18.08.1.drv-0/source/src/lib/external/media_ctrl/mediactrl.c: 
In function ‘find_first_device’:
/tmp/guix-build-kdenlive-18.08.1.drv-0/source/src/lib/external/media_ctrl/mediactrl.c:406:2: 
error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode

  for (int i = 0; i < 32; i++ ) {
  ^~~
/tmp/guix-build-kdenlive-18.08.1.drv-0/source/src/lib/external/media_ctrl/mediactrl.c:406:2: 
note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile 
your code
make[2]: *** 
[src/lib/external/media_ctrl/CMakeFiles/media_ctrl.dir/build.make:79: 
src/lib/external/media_ctrl/CMakeFiles/media_ctrl.dir/mediactrl.c.o] Error 1

make[2]: Leaving directory '/tmp/guix-build-kdenlive-18.08.1.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:1291: 
src/lib/external/media_ctrl/CMakeFiles/media_ctrl.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs

-

Based on this, I know it's a problem in mediactrl.c related to the 
version of c the compiler is expecting. Here is what make calls when it 
compiles mediactrl.c:


-

cd 
/tmp/guix-build-kdenlive-18.08.1.drv-0/build/src/lib/external/media_ctrl 
&& /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/gcc 
-DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_CAST_TO_ASCII
-DQT_NO_URL_CAST_FROM_STRING -DTRANSLATION_DOMAIN=\"kdenlive\" 
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/tmp/guix-build-kdenlive-18.08.1.drv-0/build/src/lib/external/media_ctrl 
-I/tmp/guix-buil
d-kdenlive-18.08.1.drv-0/source/src/lib/external/media_ctrl 
-I/tmp/guix-build-kdenlive-18.08.1.drv-0/build/src/lib/external/media_ctrl/media_ctrl_autogen/include 
-I/tmp/guix-build-kdenlive-1
8.08.1.drv-0/build/generated 
-I/tmp/guix-build-kdenlive-18.08.1.drv-0/build  -fno-common -Wall 
-Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long 
-Wpointer-arith -Wundef
 -Wmissing-format-attribute -Wwrite-strings 
-Werror=implicit-function-declaration --std=c99 -O2 -g -DNDEBUG 
-fvisibility=hidden   -std=gnu90 -o 
CMakeFiles/media_ctrl.dir/mediactrl.c.o   -c /

tmp/guix-build-kdenlive-18.08.1.drv-0/source/src/lib/external/media_ctrl/mediactrl.c

-

I see --std=c99 and -std=gnu90 here. I'm guessing gcc favors std=-gnu90 
in this situation.


I have passed --keep-failed and searched for "gnu90" in the source, and 
only found it in the generated Makefiles. I also searched for gnu90 in 
the package definition, but I can't find it.


I have tried adding the following line to the list of arguments in the 
package definition, but it doesn't remove the -std=gnu90 option.


-

    #:configure-flags '("-DCMAKE_C_FLAGS=-std=c99")))

-----

What a puzzle.

-Jesse Gibbons

bug#42385: guile-based jupyter kernels mix guile3 and guile2.2

[Jesse Gibbons]

jupyter-guile-kernel and guix-jupyter mix guile3 and guile2.2.

- jupyter-guile-kernel only has one of its dependencies in 
GUILE_LOAD_PATH, so it doesn't build.


- guix-jupyter builds successfully, but searches in the wrong directory 
for guix-jupyter-kernel.scm.


jupyter-guile-kernel requires guile-json1 which has not been packaged 
for guile3, and is still built with guile2.2. IINM the 
jupyter-guile-kernel repository has been updated to build with guile3, 
so it might be worth updating. Unfortunately, there are no releases in 
its github repository. I expect guix-jupyter will be much easier to fix.

bug#42385: guile-based jupyter kernels mix guile3 and guile2.2

[Jesse Gibbons]

I have a series of patches coming soon that fix both named issues.

bug#42385: guile-based jupyter kernels mix guile3 and guile2.2

[Jesse Gibbons]

On 7/20/20 3:22 AM, Ludovic Courtès wrote:

Hi Jesse,

Jesse Gibbons  skribis:


jupyter-guile-kernel and guix-jupyter mix guile3 and guile2.2.

- jupyter-guile-kernel only has one of its dependencies in
GUILE_LOAD_PATH, so it doesn't build.

- guix-jupyter builds successfully, but searches in the wrong
directory for guix-jupyter-kernel.scm.

jupyter-guile-kernel requires guile-json1 which has not been packaged
for guile3, and is still built with guile2.2. IINM the
jupyter-guile-kernel repository has been updated to build with guile3,
so it might be worth updating. Unfortunately, there are no releases in
its github repository. I expect guix-jupyter will be much easier to
fix.
I have a series of patches coming soon that fix both named issues.

Good catch!  Did you eventually manage to complete your work?

Thanks,
Ludo’.



The only reason I have not yet sent these patches (and others I have 
ready to send) is I haven't found the time to make the patches 
acceptable (lint, format commit messages, etc.). I will have time to do 
that tomorrow, so expect patches by July 22.

bug#42814: request: make guix upgrade recognize --do-not-upgrade

[Jesse Gibbons]

From the manual:

   • ‘guix search’ is an alias for ‘guix package -s’,
   • ‘guix install’ is an alias for ‘guix package -i’,
   • ‘guix remove’ is an alias for ‘guix package -r’,
   • ‘guix upgrade’ is an alias for ‘guix package -u’,
   • and ‘guix show’ is an alias for ‘guix package --show=’.

One option for "guix package -u" I often find myself using is 
--do-not-upgrade. However, guix upgrade does not recognize that option.


When I run "guix upgrade --do-not-upgrade=ungoogled-chromium" I get the 
following results:


guix upgrade: error: do-not-upgrade=ungoogled-chromium: unrecognized option

This is a bit frustrating, because I want to be able to upgrade all my 
profiles with the command:


"guix package --list-profiles | xargs -n1 guix upgrade 
--do-not-upgrade=ungoogled-chromium"


But it prints the above error for every profile and doesn't actually do 
anything.


For now, my work-around is code like the following:

"for profile in $(guix package --list-profiles); do guix package -p 
$profile --do-not-upgrade=ungoogled-chromium -u; done"


As you can see, this is quite a bit more complex than it needs to be.

So, why not have guix upgrade recognize the --do-not-upgrade option?

bug#42959: enable alpine passfile

[Jesse Gibbons]

Unless alpine is configured with a default passfile, it does not even 
offer the option to use one. There are some security concerns to 
consider[0], and I would understand if they were reason enough to not 
enable the alpine passfile. But I don't want to keep typing several 
complicated passwords every time I check my email from a VT, and I don't 
think I'm the only one. Since this was not found in the archive, I 
figured it would be worth sending a bug report.


On a side note, alpine 2.23 is released, and guix is still configured 
for 2.22. Strangely enough, the package uses the same commit the release 
tag points to.


Thanks,

-Jesse

[0]: https://bugs.archlinux.org/task/11965

bug#43011: unattended-upgrade fails and doesn't log why

[Jesse Gibbons]

An example is the attached log. It says the process failed with status 
1, but it doesn't say what failed or even reference a log in 
/var/log/guix. The only way to find out what could have caused it is to 
run the command, which might not fail the second time if it was a 
network error or (IIUC) if the issue was fixed between failure and retry.
[2020-08-23T01:30:00-0600] starting upgrade...
command "/gnu/store/a3qjvkp2z4h96ycc9afir5yrqbbsixbf-guix-1.1.0-18.218a67d/bin/guix" "time-machine" "-C" "/gnu/store/qkccph0zyh7nmwab6hisbhya7agsfb3y-channels.scm" "--" "system" "reconfigure" "/run/current-system/configuration.scm" failed with status 1

bug#43012: Scroll fails to produce expected output directory

[Jesse Gibbons]

Run "guix build scroll" -- after completing all steps it outputs 
"builder for 
`/gnu/store/r35sa0d9fnp22y0jgzk810yyhn8d7lrl-scroll-1.20180421.drv' 
failed to produce output path 
`/gnu/store/1q7aj03p7f0nk7dmdyp3lfscizywdr4m-scroll-1.20180421-static'"


I ran "guix edit scroll" and saw it doesn't do anything fancy with the 
phases or the source. Perhaps there's something wrong with the package's 
install process that needs correction?


See attached log.

guix describe:

Generation 267    Aug 21 2020 10:11:46    (current)
  guix c02398e
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: c02398edf43c393b858d57c7b9e4839514f85acb



5sa0d9fnp22y0jgzk810yyhn8d7lrl-scroll-1.20180421.drv.bz2
Description: Binary data

bug#43061: freedink package is needlessly complex

[Jesse Gibbons]

TL;DR The freedink package is defined in a complex way that breaks 
guix's custom source build features and the GUI wrapper.


The freedink package wraps the freedink-engine and freedink-data 
packages so the resulting executable bin/freedink runs the freedink 
engine pointed at the output of freedink-data. The wrapped packages are 
not exported from gnu/packages/games.scm. Because of these two design 
choices,


-> guix build --sources=all freedink does not list the freedink-data source.

-> the only way to get the freedink-data source is to run guix build 
--sources=transitive freedink. This is not ideas because it gets the 
source for bash as well.


-> "guix build --with-source=freedink-data=..." has no effect on 
freedink, so guix cannot be used to facilitate freedoms 1 and 3 with 
freedink, unlike most other packages. To be clear,  freedoms 1 (to 
modify the software) and 3 (to distribute the modified software) are not 
violated, but a very nice feature of guix that makes them less complex 
does not work with freedink. To achieve a guix install or pack of 
freedink as it is currently defined with custom sources and/or data, one 
must define new freedink packages, which is more work than one or two 
simple command-line flags.


-> freedink-dfarc does not find "dinkedit" or "dink", which are links to 
binaries built in freedink-engine. Once again, freedoms 1 and 3 are a 
little more difficult to exercise than reasonably expected given what 
guix provides, but not violated. To point freedink-dfarc to the correct 
binaries, one must copy the store location in the wrapper script 
produced by freedink. Obviously, this store location will not 
automatically be updated when freedink-engine is upgraded.


-> Because the wrapper hard-codes a location to look for the data, I 
suspect (but have yet to confirm) that an attempt to use freedink-dfarc 
to build a modified version of freedink will ultimately throw an error.


There must be a way to re-package freedink such that:

1) It works with the custom source build features provided by guix.

2) The guix wrapper freedink-dfarc is neither necessary for running 
freedink, nor broken when used to run freedink.


The solution could be as simple as publicly exposing freedink-engine and 
freedink-data, and redefining the freedink package to simply take the 
two packages as inputs and produce a wrapper script. The script should 
probably have a name other than "freedink" or "dink" so all three 
packages can optionally co-exist in the same profile without a name 
conflict. I will try this solution and send a patch if it passes the 
following tests:


-> The sources for all freedink-related packages can be produced with 
"guix build --source" or "guix build --sources=all"


-> all freedink-related packages can be installed and packed with 
modified local sources specified by --with-source


-> installing freedink does not add anything to the profile other than a 
wrapper script.


-> There is no name conflict between the executables provided by 
freedink-engine and freedink


If anyone knows why freedink is packaged the way it is and thinks it is 
better that way, I want to know your reasons before I begin to attempt 
to fix this issue, because those reasons could lead me to a different 
approach.


I suspect freedink is not the only package with these issues.

-Jesse

bug#42155: --with-source=PACKAGE=REPLACEMENT-SOURCE doesn't work recursively

[Jesse Gibbons]

(In response to issue at https://issues.guix.info/issue/42155):

I want to be able to specify dependency sources, so I am working on this 
issue. It's complicated because --with-source= can take a simple source 
(implying the package being built should be built from SOURCE) or 
package=source (AIUI implying PACKAGE in the specified list of packages 
should be built from SOURCE).  Should we deprecate the current 
interpretation of "--with-source=package=source"? Or would it be better 
to preserve these options and make a new recursive 
'--with-dependency-source=package=source' option?


I'm leaning towards making the option 
"--with-dependency-source=package=source" because I think that will be 
easier to accomplish and maintain. But if anyone has a compelling reason 
to deprecate the old usage, I am willing to listen.

bug#43392: utmp file not correctly updated when logging out from xfce to sddm

[Jesse Gibbons]

To replicate:

From a fresh startup,

1. log in to the XFCE window manager from the SDDM display manager.

2. log out

3. In a virtual console, log in with the same user and run `who`

Expected results:

The value of $USER should be listed once, because it is officially 
logged in only once.


Actual results:

The value of $USER is listed twice, and one of them is not associated 
with a virtual console.


Notes:

The way coreutils knows who is logged in is by referencing a file, 
referenced as UTMP_FILE in the coreutils source code, which should keep 
track of user logins. My guess is that something is not updating it in 
this case.


My current system config is a bit messy, so I will work on making a 
minimalist config file that can replicate this bug.

bug#37190: rhythmbox cannot subscribe to any podcasts

[Jesse Gibbons]

I just checked this, it seems to have been fixed.

bug#36951: guile-sly will not build

[Jesse Gibbons]

I just checked this, it seems to have been fixed.

bug#44347: mingetty --no-clear is hard-coded

[Jesse Gibbons]

The --no-clear option is hard-coded for mingetty, with no documentation 
about why. The mingetty page says,

   --noclear
  Do not clear the screen before prompting for the login 
name (the

  screen is normally cleared).

I do not think I am alone in preferring the screen cleared after logout. 
I also think it could be a security issue. For now my workaround is to 
include a call to "tput reset" or "clear" in my .bash_logout script, but 
that has to be configured for every user and requires more packages 
installed either at the system level or per-user.


I think this is an "easy for beginners" issue. I would fix it myself, 
but I have a lot of other stuff to do.

bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader

[Jesse Gibbons]

To replicate:
cd to a git checkout of the source code, gnu/system/examples
The hash for my current checkout is 
d7e033b9a153a9e60f52ff64f4eb355c1c3d0a6e which is also the hash for my 
current version of guix.

guix system disk-image -t raw lightweight-desktop.tmpl

lightweight-desktop.tmpl defines an operating-system that uses 
grub-efi-bootloader, and is embedded in the info pages as an example 
operating system. Since it is lightweight, it doesn't take as long to 
build as desktop.tmpl.


Expected results: guix builds the raw image just fine, and that image 
can be copied to an SD card and run on a computer with an efi 
bootloader, just like the counterpart with grub-bootloader. There is 
nothing in the documentation suggesting that this should not work by design.


Actual results: guix fails, see attached log.

-Jesse


1zv1w0vbd4yvnmnnyn06ajkllx21gc-partition.img.drv.bz2
Description: Binary data

bug#44445: json-c cross-build fails from x86-64 to armhf

[Jesse Gibbons]

I'm trying to build a guix system for my banana pi m2u, but json-c fails 
to cross-build.


~$ guix describe
Generation 319    Nov 04 2020 06:41:25    (current)
  guix 3d67269
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 3d67269ee787c8624bafdd68df9fbf7eedd8eb1e

~$ guix build --system=armhf-linux json-c
...
command "cmake" "../json-c-0.14" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" 
"-DCMAKE_INSTALL_PREFIX=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14" 
"-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" 
"-DCMAKE_INSTALL_RPATH=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14/lib" 
"-DCMAKE_VERBOSE_MAKEFILE=ON" failed with status 1
builder for 
`/gnu/store/m3x5hnlp9d9qmg72a0c7rqlz40yc0x0m-json-c-0.14.drv' failed 
with exit code 1

build of /gnu/store/m3x5hnlp9d9qmg72a0c7rqlz40yc0x0m-json-c-0.14.drv failed
View build log at 
'/var/log/guix/drvs/m3/x5hnlp9d9qmg72a0c7rqlz40yc0x0m-json-c-0.14.drv.bz2'.
guix build: error: build of 
`/gnu/store/m3x5hnlp9d9qmg72a0c7rqlz40yc0x0m-json-c-0.14.drv' failed



Log attached.




x5hnlp9d9qmg72a0c7rqlz40yc0x0m-json-c-0.14.drv.bz2
Description: Binary data

bug#44717: ISO grub config points to nonexistent drive UUID.

[Jesse Gibbons]

On multiple computers, when I try to copy a custom operating system iso 
to an sd card and boot, the boot operation fails. Here's the output on 
one of the computers:


GC Warning: pthread_getattr_up or pthread_getattr_getstack failed for 
main thread

GC Warning: couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use --repl for an initrd REPL.

loading kernel modules...
waiting for partition '31393730-3031-3031-3139-333534353239' to appear...
waiting for partition '31393730-3031-3031-3139-333534353239' to appear...
waiting for partition '31393730-3031-3031-3139-333534353239' to appear...
[    5.044226] sd 0:0:0:0: [sda] No Caching mode page found
[    5.044336] sd 0:0:0:0: [sda] Assuming drive cache: write through
No file system check procedure for /dev/sda; skipping
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure mount: Permission denied

Entering a new prompt. Type `,bt' for a backtrace or `,q` to continue.
GNU Guile 3.0.2
Copyright (C) 1995-2020 Free Software foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help\ for help.
scheme@(guile-user)>

When I type ,q or C-d I trigger a kernel panic.

This happens on at least three different computers:
- a lenovo ideapad s100 (intel atom, only successfully boots 32-bit 
image, output above)

- a laptop (unidentified brand) with an amd athlon-x2, only tried 64-bit iso
- an acer aspire one (cnet says intel atom), only tried 64-bit iso

I can confirm the lenovo successfully boots the i686 install iso 
(version 1.1.0) on the guix website and lets me see the info page on 
installing the system by hand, though the UI installer fails (most 
likely because the network hardware is disgustingly blobby).


I built the install image for i686-linux and flashed it to the sd card. 
It looks for the exact same partition and falls back on a boot guile repl.


$ guix describe
Generation 334    Nov 17 2020 17:52:52    (current)
  guix 129b9b1
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 129b9b16d9b588316cc997cf8f4fefe30961a417

I generated the iso with the command
`guix system disk-image -t iso9660 --root=installer.BaNl/install-x86.iso 
--system=i686-linux gnu/system/install.scm`

and flash the sd card with the command
`sudo bash -c "echo success" && time sudo dd if=install-x86.iso of=/dev/sdc`

When I inspect the GRUB menu, I see the option
--root=31393730-3031-3031-3139-333534353239
but in the gnome disk utility on my main laptop I do not see the above 
UUID in any of the partitions on the SD card I'm using, still with the 
freshly built install iso flashed onto it. Instead I see the UUIDs 
1970-01-01-19-49-46-83 for partition 1 and 3495-32E0 for partition 2.


Thanks,
-Jesse

bug#44717: ISO grub config points to nonexistent drive UUID.

[Jesse Gibbons]

On 11/18/20 3:31 AM, Ludovic Courtès wrote:

Hi,

Jesse Gibbons  skribis:


I generated the iso with the command
`guix system disk-image -t iso9660
--root=installer.BaNl/install-x86.iso --system=i686-linux
gnu/system/install.scm`
and flash the sd card with the command
`sudo bash -c "echo success" && time sudo dd if=install-x86.iso of=/dev/sdc`

When I inspect the GRUB menu, I see the option
--root=31393730-3031-3031-3139-333534353239
but in the gnome disk utility on my main laptop I do not see the above
UUID in any of the partitions on the SD card I'm using, still with the
freshly built install iso flashed onto it. Instead I see the UUIDs
1970-01-01-19-49-46-83 for partition 1 and 3495-32E0 for partition 2.

The option in the GRUB menu uses the “DCE” format for the UUID, but if
you convert it to an ISO-9660 UUID, it looks almost the same:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(gnu system uuid)
scheme@(guile-user)> (string->uuid "31393730-3031-3031-3139-333534353239")
$60 = #vu8(49 57 55 48 48 49 48 49 49 57 51 53 52 53 50 57)
scheme@(guile-user)> (bytevector->uuid $60 'iso9660)
$61 = #< type: iso9660 bv: #vu8(49 57 55 48 48 49 48 49 49 57 51 53 52 53 50 
57)>
scheme@(guile-user)> (uuid->string $61)
$62 = "1970-01-01-19-35-45-29"
--8<---cut here---end--->8---

The ISO UUID is computed in a deterministic fashion.  Are you sure
you’re looking at the same ISO?

For example, if you pick
<https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz>,
it boots just fine.  In the GRUB menu entry (type ‘e’ in the menu), you
can see both the DCE UUID for ‘--root’ and the ISO UUID for ‘search.fs’,
which are actually the same.

HTH!

Ludo’.


When I posted this initial bug report, I reported what happened when I 
flashed the built iso to an SD card and tried it on another laptop. Just 
to be sure, I remade the image (in the same directory as my guix checkout)


guix system disk-image -t iso9660 --root=$(mktemp -p /tmp -d 
install.XXX)/install-x86.iso --system=i686-linux gnu/system/install.scm


and I mounted the ISO itself and took a look at it. The grub.conf 
specifies both UUIDs as you described.


When I try it on a VM, it opens a repl with a completely different error 
which I'm too lazy to type out by hand. See attached screenshot.


When I download the iso you linked and run it on a vm, it works just 
fine. Just to see if it has anything to do with the architecture, I also 
decided to try a vm with the i686-linux counterpart. It also works fine.


I do not have access to any of those old laptops right now, so I can't 
experiment further.

bug#44717: ISO grub config points to nonexistent drive UUID.

[Jesse Gibbons]

On 11/18/20 10:17 AM, Ludovic Courtès wrote:

Hi Jesse,

Jesse Gibbons  skribis:


For example, if you pick
<https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz>,
it boots just fine.  In the GRUB menu entry (type ‘e’ in the menu), you
can see both the DCE UUID for ‘--root’ and the ISO UUID for ‘search.fs’,
which are actually the same.

[...]


guix system disk-image -t iso9660 --root=$(mktemp -p /tmp -d
install.XXX)/install-x86.iso --system=i686-linux
gnu/system/install.scm

and I mounted the ISO itself and took a look at it. The grub.conf
specifies both UUIDs as you described.

When I try it on a VM, it opens a repl with a completely different
error which I'm too lazy to type out by hand. See attached screenshot.

Do you observe the same problem with the image I linked to above?  It’s
built with ‘guix system disk-image -t iso9660 --label=GUIX…
gnu/system/install.scm’.
No, I did not have any trouble booting either of the "official" 
installer images in a VM.


The error you sent looks as if it’s trying to mount the root file system
read/write.

Thinking about it: does it work if you pass ‘--volatile’ on the
‘disk-image’ command line?  This flag was added recently on ‘master’
(commit 41f27bf8702838f19b1dc5ffee8eec1d4315d4e6), so perhaps what
you’re seeing is a regression here.

Maxim, could it be that we need (volatile-root? #t) for the ISO9660
image type and/or passing ‘--volatile’ in Makefile.am (‘release’ target)
and updating the “Building the Installation Image” node of the manual?

Thanks,
Ludo’.

I looked up the commit for the v1.2.0rc1 tag and ran
`guix time-machine --commit=1e272d42f6217b70c9801b93e46b144e9ab27664 -- 
system disk-image -t iso9660 --system=i686-linux --root=$(mktemp -p /tmp 
-d install.x86.XXX)/install.x86.iso gnu/system/install.scm`
I tried the output in a vm. It booted fine. I'll try including the 
--volatile flag without using the time machine.

bug#44717: ISO grub config points to nonexistent drive UUID.

[Jesse Gibbons]

On 11/18/20 11:09 AM, Bengt Richter wrote:

Hi Jesse,

On +2020-11-17 21:56:32 -0700, Jesse Gibbons wrote:
[...]

I generated the iso with the command
`guix system disk-image -t iso9660 --root=installer.BaNl/install-x86.iso
--system=i686-linux gnu/system/install.scm`
and flash the sd card with the command
`sudo bash -c "echo success" && time sudo dd if=install-x86.iso of=/dev/sdc`


&& sync ??

I think I have gotten corrupted results before, by assuming that DD does its 
own sync
of its output all the way to completed writing to destination disk before 
returning.
(not sure if of= was an ordinary file when I got hit, though ;)
I'm not sure how I can get it to sync. I would normally use the gnome 
disk utiltity to flash an image to an external drive, but for a while it 
didn't respond when I tried to "restore disk image". Now it's working 
fine though. I'll try using gnome disk utility to flash and see if that 
makes a difference.

When I inspect the GRUB menu, I see the option
--root=31393730-3031-3031-3139-333534353239
but in the gnome disk utility on my main laptop I do not see the above UUID
in any of the partitions on the SD card I'm using, still with the freshly
built install iso flashed onto it. Instead I see the UUIDs
1970-01-01-19-49-46-83 for partition 1 and 3495-32E0 for partition 2.

Thanks,
-Jesse

bug#44717: ISO grub config points to nonexistent drive UUID.

[Jesse Gibbons]

On 11/18/20 10:17 AM, Ludovic Courtès wrote:

Hi Jesse,

Jesse Gibbons  skribis:


For example, if you pick
<https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz>,
it boots just fine.  In the GRUB menu entry (type ‘e’ in the menu), you
can see both the DCE UUID for ‘--root’ and the ISO UUID for ‘search.fs’,
which are actually the same.

[...]


guix system disk-image -t iso9660 --root=$(mktemp -p /tmp -d
install.XXX)/install-x86.iso --system=i686-linux
gnu/system/install.scm

and I mounted the ISO itself and took a look at it. The grub.conf
specifies both UUIDs as you described.

When I try it on a VM, it opens a repl with a completely different
error which I'm too lazy to type out by hand. See attached screenshot.

Do you observe the same problem with the image I linked to above?  It’s
built with ‘guix system disk-image -t iso9660 --label=GUIX…
gnu/system/install.scm’.

The error you sent looks as if it’s trying to mount the root file system
read/write.

Thinking about it: does it work if you pass ‘--volatile’ on the
‘disk-image’ command line?  This flag was added recently on ‘master’
(commit 41f27bf8702838f19b1dc5ffee8eec1d4315d4e6), so perhaps what
you’re seeing is a regression here.

Maxim, could it be that we need (volatile-root? #t) for the ISO9660
image type and/or passing ‘--volatile’ in Makefile.am (‘release’ target)
and updating the “Building the Installation Image” node of the manual?

Thanks,
Ludo’.
Passing --volatile to the iso build command fixes the issue with the VM. 
I'm flashing an the resulting to my external drive right now. In a few 
hours, I should be able to test if the problem was that the drive didn't 
fully sync, and hopefully we can close this issue tonight.

bug#44893: `guix deploy` doesn't recognize option --dry-run

[Jesse Gibbons]

--dry-run is an option listed in `guix deploy --help` but when I try it, 
it isn't recognized:


$ guix deploy --dry-run deploy.scm
guix deploy: error: dry-run: unrecognized option

bug#44948: glade does not respond

[Jesse Gibbons]

guix environment --ad-hoc glade -- glade
The main window pops up, and so does a dialog asking if I want to take a 
survey. I click to close the dialog and it doesn't respond.

My WM is xfce.
$ guix describe
Generation 342    Nov 28 2020 17:39:32    (current)
  guix f816deb
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: f816deb9055669deaca59ac7652943adf7f11bb1

bug#44948: glade does not respond

[Jesse Gibbons]

On 12/3/20 6:26 AM, zimoun wrote:

Hi,

On Thu, 03 Dec 2020 at 04:15, Michael Rohleder  wrote:

Jesse Gibbons  writes:

The main window pops up, and so does a dialog asking if I want to take
a survey. I click to close the dialog and it doesn't respond.

[...]


Is this on a foreign distro?

How didn't I receive this response?

This is not foreign. I'm on xfce if that makes a difference.

bug#52913: 0ad only builds fine with a specific version of mozjs

[Jesse Gibbons]

> What would be the best way to fix this?
>  - keep a mozjs-78.6 package around just for 0ad
>  - patch 0ad to fix the compatibility issues with mozjs 78.15
>  - use the mozjs version bundled in the 0ad sources
>
> WDYT?

Keeping mozjs-78.6 just for 0ad will probably make things harder later 
on because it's another package to maintain and users likely won't be 
able install 0ad and icecat/icedove in the same profile. I suppose users 
can always use `-P /path/to/0ad-profile` when installing or updating 0ad.


I'm thinking using the bundled mozjs is perhaps the best option, though 
it isn't particularly guixy, because I expect most users would want the 
0ad packaged by guix to be compatible with other 0ad builds in the wild. 
However, I think it would be useful to fix compatibility issues with 
mozjs 78.15 so interested contributors can tell upstream if guix's 
current minor version breaks the expected deterministic behaviors 
described in the error.


Another option would be to keep mozjs-78.6 for 0ad and patch it so 
interested users can test updated mozjs using 
`--with-input=mozjs=mozjs`. It isn't very difficult to modify a list of 
packages to use a specific mozjs in a manifest or home configuration, 
right? Though I guess interested contributors could always add the patch 
themselves just as easily...


Anyway, that's my two cents.

bug#53002: guix can't find gfortran-toolchain or gdc-toolchain

[Jesse Gibbons]

Strange bug, guix can't find gfortran-toolchain even though it is a 
package defined publicly in one of the files it presumably searches.


`which guix` outputs the expected "$HOME/.config/guix/current/bin/guix", 
so it probably isn't a problem with my guix home.


`guix package -A gfortran` returns nothing.

`guix package -A gcc-toolchain` shows several different versions of 
gcc-toolchain in gnu/packages/commencement.scm


`guix edit gcc-toolchain` opens the source where guix presumably found 
the gcc-toolchain package definition. Within that file, 
gfortran-toolchain is defined publicly.


This is also the case for gdc-toolchain.

`guix describe`:

    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 8bfb1258d32b5ffeeefd9d44753b87f62bdbf822

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

[Jesse Gibbons]

I brought this to the help mailing list, and now I see it as a
particular bug in guix. When I change into a guix environment and try
to run a Python project that uses the WebKitGTK2 library, it cannot
find the specified shared library, even though it is in $LIBRARY_PATH.
As a result, the project crashes. This does not happen when I call guix
build. On a side note, guix build fails due to another error (possibly
related).

Thanks in advance for looking into this.
-Jesse


Package Definition:
#!
see https://github.com/jendrikseipp/rednotebook
!#
(define-module (custom packages rednotebook)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system python)
  #:use-module (guix licenses))
(define-public rednotebook

  (package
   (name "rednotebook")
   (version "2.11.1")
   (source
(origin
 (method url-fetch)
 (uri (string-append
   "https://github.com/jendrikseipp/rednotebook/archive/v";
   version
   ".tar.gz"))
 (sha256
  (base32
   "15n1ziypfj3lzpvhha7r637zrb259l9yrcsvkic9cg5mndiaivs3"
   (build-system python-build-system)
   (inputs
`(("python" ,(@ (gnu packages python) python-3
   (propagated-inputs
`(("python-pygobject"
   ,(@ (gnu packages glib) python-pygobject))
  ("gtk+" ,(@ (gnu packages gtk) gtk+))
  ("gtksourceview"
   ,(@ (gnu packages gtk) gtksourceview-3))
  ("webkitgtk"
   ,(@ (gnu packages webkit) webkitgtk-2.24))
  ("python-pyyaml"
   ,(@ (gnu packages python-xyz) python-pyyaml
   (home-page "https://www.rednotebook.app";)
   (synopsis #f)
   (description
"RedNotebook is a modern desktop journal. It lets you format, tag and 
search your entries. You can also add pictures, links and customizable 
templates, spell check your notes, and export to plain text, HTML, Latex or 
PDF.")
   (license gpl2+))
  )


Program log (streams merged):
Adding /home/jesse/Documents/rednotebook/rednotebook-2.11.1 to sys.path
2019-05-07 16:15:41,122 INFO Writing log to file 
"/home/jesse/.rednotebook/rednotebook.log"
2019-05-07 16:15:41,122 INFO System encoding: utf-8
2019-05-07 16:15:41,122 INFO Language code: None
rednotebook/journal.py:161: PyGIDeprecationWarning: Since version 3.11, calling 
threads_init is no longer needed. See: 
https://wiki.gnome.org/PyGObject/Threading
  GObject.threads_init()
2019-05-07 16:15:41,182 WARNING  For spell checking, please install enchant 
(python3-enchant).

** (journal.py:2179): WARNING **: 16:15:41.209: Failed to load shared library 
'libwebkit2gtk-4.0.so.37' referenced by the typelib: libwebkit2gtk-4.0.so.37: 
cannot open shared object file: No such file or directory

** (journal.py:2179): WARNING **: 16:15:41.209: Failed to load shared library 
'libjavascriptcoregtk-4.0.so.18' referenced by the typelib: 
libjavascriptcoregtk-4.0.so.18: cannot open shared object file: No such file or 
directory
/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py:226:
 Warning: cannot derive 'rednotebook+gui+browser+Browser' from non-derivable 
parent type 'void'
  _gi.type_register(cls, namespace.get('__gtype_name__'))
Traceback (most recent call last):
  File "rednotebook/journal.py", line 168, in 
from rednotebook.gui.main_window import MainWindow
  File 
"/home/jesse/Documents/rednotebook/rednotebook-2.11.1/rednotebook/gui/main_window.py",
 line 45, in 
from rednotebook.gui import browser
  File 
"/home/jesse/Documents/rednotebook/rednotebook-2.11.1/rednotebook/gui/browser.py",
 line 41, in 
class Browser(WebKit2.WebView):
  File 
"/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py",
 line 235, in __init__
super(GObjectMeta, cls).__init__(name, bases, dict_)
  File 
"/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py",
 line 214, in __init__
cls._type_register(cls.__dict__)
  File 
"/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/python3.7/site-packages/gi/types.py",
 line 226, in _type_register
_gi.type_register(cls, namespace.get('__gtype_name__'))
RuntimeError: could not create new GType: rednotebook+gui+browser+Browser 
(subclass of void)

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

[Jesse Gibbons]

On Wed, 8 May 2019 14:38:02 +0200
Gábor Boskovits  wrote:

> Hello Jesse,
> 
> Jesse Gibbons  ezt írta (időpont: 2019. máj.
> 8., Sze, 0:33):
> 
> > I brought this to the help mailing list, and now I see it as a
> > particular bug in guix. When I change into a guix environment and
> > try to run a Python project that uses the WebKitGTK2 library, it
> > cannot find the specified shared library, even though it is in
> > $LIBRARY_PATH. As a result, the project crashes. This does not
> > happen when I call guix build. On a side note, guix build fails due
> > to another error (possibly related).
> >
> > Thanks in advance for looking into this.
> > -Jesse
> >
> >
> > So it seems that the guix environment  misses some environment
> > variables.  
> Can you check if this is still the case, when you keep the build
> output using guix build --keep-failed --check, and then guix
> environment , and source the environment variables dropped
> at the kept build directory?

I followed those steps. It doesn't seem to make a difference. I think I
am running code not called when guix builds, but I think it is leaking
into a problem that causes 'guix build' to fail.
The help list suggests there might be something hard-coded. I will
check for that.

> 
> If that helps, then can you send the two environments?
I'm not certain how to get the variables initially set under 'guix
environment' but here's the environment variables dropped by guix build:

export 
CPLUS_INCLUDE_PATH="/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/include:/gnu/store/36gjs99v2z70123fw375i768gjklspf9-python-pygobject-3.28.3/include:/gnu/store/i8x3yn47chgnmzwdbnj5s3knla405qvi-gtk+-3.24.7/include:/gnu/store/9rpr30qpjav31nn181bdyazdmq4vq67z-gtksourceview-3.24.10/include:/gnu/store/lmmbga46bnx7iwcs8y9rbnnaylxrx9c6-webkitgtk-2.24.1/include:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/include:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/include:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/include:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/include:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/include:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/include:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/include:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include:/gnu/store/vd35w7c44njixcagxqyqpd81frc3ngpz-libffi-3.2.1/include:/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/include:/gnu/store/6zy28hygcagsrngvihk7dnq3qqj2ljhi-wayland-1.17.0/include:/gnu/store/a27pvkbi2wc7772zjar1adncxd7lr759-pango-1.42.4/include:/gnu/store/rxqxn0mxmg0v2xg5nvpaidvpj3d1kxb7-mesa-18.3.5/include:/gnu/store/6hq2ha8hfghnkrnrpawx2vlsp88zq537-libxdamage-1.1.4/include:/gnu/store/b9w8flar3z94xjnbajsqbw97ggpmx4qa-libxkbcommon-0.8.4/include:/gnu/store/mcd9pz6miv4wsrwlzam18akn3nix0ysa-libxinerama-1.1.4/include:/gnu/store/1wgjfp47da8zm7ap9n0sl6wfn295qvcw-libxi-1.7.9/include:/gnu/store/qgzhkhmm4cis6wmx8n469jlshgr28fsh-libxcursor-1.2.0/include:/gnu/store/dxir0rz1q9cmnjkbjdjq41gi0c7j1sbn-libepoxy-1.5.3/include:/gnu/store/6m8mfngzi0hmjgi3hfnszyhis8i0vg4c-gdk-pixbuf+svg-2.38.1/include:/gnu/store/5yaa39a8rvq8xdv8h37n29sxfmnlcv12-atk-2.32.0/include:/gnu/store/24afn7chbs6r1a6mn7w4yfv3czq76jya-at-spi2-atk-2.32.0/include:/gnu/store/l2f5m536i38z1403fyxjnrbrfk6d9xqb-libxml2-2.9.8/include:/gnu/store/d81m3wm7w9cxdgb9r3ppr77hfmb88jrf-libsoup-2.66.1/include:/gnu/store/xha1mk4qji8fmg62nygfzdx0l94ikdhm-linux-libre-headers-4.14.67/include:/gnu/store/05zlxc7ckwflz56i6hmlngr86pmccam2-pcre-8.42/include:/gnu/store/k641x9mjzjl6flyj9q8qpv7nalhmi1gl-harfbuzz-2.2.0/include:/gnu/store/5dnkbi6zchkisgwx2914k0iafllcvv93-freetype-2.9.1/include:/gnu/store/66jfnfgca7yi6xmpw6ax86cldvr016ia-fontconfig-2.13.1/include:/gnu/store/wrk6d4pf66rp81v989ybmh1jp6jhh8lf-fribidi-1.0.5/include:/gnu/store/w946jk6bl2riqpfcklf4bbs7haqmg8fv-cairo-1.16.0/include:/gnu/store/hdwn6fbbii6907ibvyax92cxzam0hrhx-xorgproto-2018.4/include:/gnu/store/v1vnqq6nzf1n842956l30yjxzjy0130h-libxxf86vm-1.1.4/include:/gnu/store/hcxcbbsf0p1fzjajd2idc3j5qvlyyp5w-libxshmfence-1.3/include:/gnu/store/dis1laih296cvfjrcj3azcjfxkip4hdb-libxfixes-5.0.3/include:/gnu/store/8baabfjazsr7s4y0jig1sn84xnxf75xa-libx11-1.6.6/include:/gnu/store/inw59iqwpal8pz3vxlfqdn1pjahd3rdx-libvdpau-1.2/include:/gnu/store/smpgxk3vmydbmnhnd5ljnj1ll96463r8-libdrm-2.4.97/include:/gnu/store/2dk55i5wdhcbh2z8hhn3r55x4873iyp1-libxext-1.3.3/include:/gnu/store/xrvwszmahcb7k2zcyag3vmqwswzrbvcg-libxrender-0.9.10/include:/gnu/store/55m57xamf980iymccl9k26k4an0ynf7d-libpng-1.6.34/include:/gnu/store/ri7mjihsihcl7wkarhklg0l4kfr26m43-at-spi2-core-2.32.0/include:/gnu/store/nq4lsyipmfb0q7g26ra45rwwqrh3x8zw-zlib-1.2.11/include:/gnu/store/pba3xzrkq2k4wgh3arif4xpkblr5qz2n-sqlite-3.24.0/include:/gnu/store/vbybdsgmyr5qcnfawax8y4w129b17a91-libpsl-

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

[Jesse Gibbons]

On Wed, 8 May 2019 09:31:50 -0600
Jesse Gibbons  wrote:

> On Wed, 8 May 2019 14:38:02 +0200
> Gábor Boskovits  wrote:
> 
> > Hello Jesse,
> > 
> > Jesse Gibbons  ezt írta (időpont: 2019. máj.
> > 8., Sze, 0:33):
> >   
> > > I brought this to the help mailing list, and now I see it as a
> > > particular bug in guix. When I change into a guix environment and
> > > try to run a Python project that uses the WebKitGTK2 library, it
> > > cannot find the specified shared library, even though it is in
> > > $LIBRARY_PATH. As a result, the project crashes. This does not
> > > happen when I call guix build. On a side note, guix build fails
> > > due to another error (possibly related).
> > >
> > > Thanks in advance for looking into this.
> > > -Jesse
> > >
> > >
> > > So it seems that the guix environment  misses some environment
> > > variables.
> > Can you check if this is still the case, when you keep the build
> > output using guix build --keep-failed --check, and then guix
> > environment , and source the environment variables dropped
> > at the kept build directory?  
> 
> I followed those steps. It doesn't seem to make a difference. I think
> I am running code not called when guix builds, but I think it is
> leaking into a problem that causes 'guix build' to fail.
> The help list suggests there might be something hard-coded. I will
> check for that.
> 
> > 
> > If that helps, then can you send the two environments?  
> I'm not certain how to get the variables initially set under 'guix
> environment' but here's the environment variables dropped by guix
> build:
> 
> export
> CPLUS_INCLUDE_PATH="/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/include:/gnu/store/36gjs99v2z70123fw375i768gjklspf9-python-pygobject-3.28.3/include:/gnu/store/i8x3yn47chgnmzwdbnj5s3knla405qvi-gtk+-3.24.7/include:/gnu/store/9rpr30qpjav31nn181bdyazdmq4vq67z-gtksourceview-3.24.10/include:/gnu/store/lmmbga46bnx7iwcs8y9rbnnaylxrx9c6-webkitgtk-2.24.1/include:/gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/include:/gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/include:/gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/include:/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/include:/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/include:/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/include:/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/include:/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include:/gnu/store/vd35w7c44njixcagxqyqpd81frc3ngpz-libffi-3.2.1/include:/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/include:/gnu/store/6zy28hygcagsrngvihk7dnq3qqj2ljhi-wayland-1.17.0/include:/gnu/store/a27pvkbi2wc7772zjar1adncxd7lr759-pango-1.42.4/include:/gnu/store/rxqxn0mxmg0v2xg5nvpaidvpj3d1kxb7-mesa-18.3.5/include:/gnu/store/6hq2ha8hfghnkrnrpawx2vlsp88zq537-libxdamage-1.1.4/include:/gnu/store/b9w8flar3z94xjnbajsqbw97ggpmx4qa-libxkbcommon-0.8.4/include:/gnu/store/mcd9pz6miv4wsrwlzam18akn3nix0ysa-libxinerama-1.1.4/include:/gnu/store/1wgjfp47da8zm7ap9n0sl6wfn295qvcw-libxi-1.7.9/include:/gnu/store/qgzhkhmm4cis6wmx8n469jlshgr28fsh-libxcursor-1.2.0/include:/gnu/store/dxir0rz1q9cmnjkbjdjq41gi0c7j1sbn-libepoxy-1.5.3/include:/gnu/store/6m8mfngzi0hmjgi3hfnszyhis8i0vg4c-gdk-pixbuf+svg-2.38.1/include:/gnu/store/5yaa39a8rvq8xdv8h37n29sxfmnlcv12-atk-2.32.0/include:/gnu/store/24afn7chbs6r1a6mn7w4yfv3czq76jya-at-spi2-atk-2.32.0/include:/gnu/store/l2f5m536i38z1403fyxjnrbrfk6d9xqb-libxml2-2.9.8/include:/gnu/store/d81m3wm7w9cxdgb9r3ppr77hfmb88jrf-libsoup-2.66.1/include:/gnu/store/xha1mk4qji8fmg62nygfzdx0l94ikdhm-linux-libre-headers-4.14.67/include:/gnu/store/05zlxc7ckwflz56i6hmlngr86pmccam2-pcre-8.42/include:/gnu/store/k641x9mjzjl6flyj9q8qpv7nalhmi1gl-harfbuzz-2.2.0/include:/gnu/store/5dnkbi6zchkisgwx2914k0iafllcvv93-freetype-2.9.1/include:/gnu/store/66jfnfgca7yi6xmpw6ax86cldvr016ia-fontconfig-2.13.1/include:/gnu/store/wrk6d4pf66rp81v989ybmh1jp6jhh8lf-fribidi-1.0.5/include:/gnu/store/w946jk6bl2riqpfcklf4bbs7haqmg8fv-cairo-1.16.0/include:/gnu/store/hdwn6fbbii6907ibvyax92cxzam0hrhx-xorgproto-2018.4/include:/gnu/store/v1vnqq6nzf1n842956l30yjxzjy0130h-libxxf86vm-1.1.4/include:/gnu/store/hcxcbbsf0p1fzjajd2idc3j5qvlyyp5w-libxshmfence-1.3/include:/gnu/store/dis1laih296cvfjrcj3azcjfxkip4hdb-libxfixes-5.0.3/include:/gnu/store/8baabfjazsr7s4y0jig1sn84xnxf75xa-libx11-1.6.6/include:/gnu/store/inw59iqwpal8pz3vxlfqdn1pjahd3rdx-libvdpau-1.2/include:/gnu/store/smpgxk3vmydbmnhnd5ljnj1ll96463r8-libdrm-2.4.97/include:/gnu/store/2dk55i5wdhcbh2z8hhn3r55x4873iyp1-libxext-1.3.3/include:/gnu/store/xrvwszmahcb7k2zcyag3vmqwswzrbvcg-libxrender-0.9.10/include:/gnu/store/55m57xamf980iymccl9k26k4an0ynf7d-libpng-1.6.34/includ

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

[Jesse Gibbons]

The good news is this bug is no longer an impediment to installing the
package because I took a(n arguably foolish) risk and disabled the tests
in the package definition (see attachment: rednotebook.scm). The bad
news is this bug persists when I run the installed package. When I
install rednotebook and run it, I get an error like the following:

Adding 
/gnu/store/cb2qs9gg7jlb83qc9k1aballzrfvia35-rednotebook-2.11.1/lib/python3.7/site-packages
to sys.path 2019-05-19 18:00:57,995 INFO Writing log to file
"/home/jesse/.rednotebook/rednotebook.log" 2019-05-19 18:00:57,995
INFO System encoding: utf-8 2019-05-19 18:00:57,995 INFO
Language code: en_US 2019-05-19 18:00:58,054 WARNING  For spell
checking, please install enchant (python3-enchant).

** (.rednotebook-real:5662): WARNING **: 18:00:58.089: Failed to load
shared library 'libwebkit2gtk-4.0.so.37' referenced by the typelib:
libwebkit2gtk-4.0.so.37: cannot open shared object file: No such file
or directory

** (.rednotebook-real:5662): WARNING **: 18:00:58.089: Failed to load
shared library 'libjavascriptcoregtk-4.0.so.18' referenced by the
typelib: libjavascriptcoregtk-4.0.so.18: cannot open shared object
file: No such file or
directory 
/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/types.py:226:
Warning: cannot derive 'rednotebook+gui+browser+Browser' from
non-derivable parent type 'void' _gi.type_register(cls,
namespace.get('__gtype_name__')) Traceback (most recent call last):
File
"/gnu/store/cb2qs9gg7jlb83qc9k1aballzrfvia35-rednotebook-2.11.1/bin/.rednotebook-real",
line 6, in  import journal ModuleNotFoundError: No module named
'journal'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/gnu/store/cb2qs9gg7jlb83qc9k1aballzrfvia35-rednotebook-2.11.1/bin/.rednotebook-real",
line 11, in  import rednotebook.journal File
"/gnu/store/cb2qs9gg7jlb83qc9k1aballzrfvia35-rednotebook-2.11.1/lib/python3.7/site-packages/rednotebook/journal.py",
line 168, in  from rednotebook.gui.main_window import
MainWindow File
"/gnu/store/cb2qs9gg7jlb83qc9k1aballzrfvia35-rednotebook-2.11.1/lib/python3.7/site-packages/rednotebook/gui/main_window.py",
line 45, in  from rednotebook.gui import browser File
"/gnu/store/cb2qs9gg7jlb83qc9k1aballzrfvia35-rednotebook-2.11.1/lib/python3.7/site-packages/rednotebook/gui/browser.py",
line 41, in  class Browser(WebKit2.WebView): File
"/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/types.py",
line 235, in __init__ super(GObjectMeta, cls).__init__(name, bases,
dict_) File
"/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/types.py",
line 214, in __init__ cls._type_register(cls.__dict__) File
"/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/types.py",
line 226, in _type_register _gi.type_register(cls,
namespace.get('__gtype_name__')) RuntimeError: could not create new
GType: rednotebook+gui+browser+Browser (subclass of void)


Looks like this bug infests more than a temporary guix
environment. The program crashes unable to find some essential class
definitions even when I add a directory containing the necessary shared
libraries to $LD_LIBRARY_PATH and check that GI_TYPELIB_PATH has the
necessary typelib files.

#!
see https://github.com/jendrikseipp/rednotebook
!#
(define-module (custom packages rednotebook)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system python)
  #:use-module (guix licenses))
(define-public rednotebook

  (package
   (name "rednotebook")
   (version "2.11.1")
   (source
(origin
 (method url-fetch)
 (uri (string-append
	   "https://github.com/jendrikseipp/rednotebook/archive/v";
	   version
	   ".tar.gz"))
 (sha256
  (base32
   "15n1ziypfj3lzpvhha7r637zrb259l9yrcsvkic9cg5mndiaivs3"
   (build-system python-build-system)
   (arguments `(#:tests? #f))
   (inputs
`(("python" ,(@ (gnu packages python) python-3
   (propagated-inputs
`(("python-pygobject"
   ,(@ (gnu packages glib) python-pygobject))
  ("gtk+" ,(@ (gnu packages gtk) gtk+))
  ("gtksourceview"
   ,(@ (gnu packages gtk) gtksourceview-3))
  ("webkitgtk"
   ,(@ (gnu packages webkit) webkitgtk-2.24))
  ("python-pyyaml"
   ,(@ (gnu packages python-xyz) python-pyyaml
   (home-page "https://www.rednotebook.app";)
   (synopsis #f)
   (description
"RedNotebook is a modern desktop journal. It lets you format, tag and search your entries. You can also add pictures, links and customizable templates, spell check your notes, and export to plain text, HTML, Latex or PDF.")
   (license gpl2+))
  )

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

[Jesse Gibbons]

When I set LD_LIBRARY_PATH=$LIBRARY_PATH before I run the program in
the guix environment I get an error like the following:

** (journal.py:22592): WARNING **: 23:24:01.406: Failed to load shared
library 'libwebkit2gtk-4.0.so.37' referenced by the
typelib: 
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/libgcc_s.so.1:
version `GCC_7.0.0' not found (required
by 
/gnu/store/kz1d84nv5rlqdf415i16wz8zvf492l1c-profile/lib/libwebkit2gtk-4.0.so.37)

I'm a bit confused. What does it mean by "`GCC_7.0.0' not found"?

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Jesse Gibbons]

(from the digest)
>Date: Thu, 23 May 2019 17:31:38 +0200
>From: "pelzflorian (Florian Pelz)" 
>To: Ricardo Wurmus 
>Cc: 35...@debbugs.gnu.org
>Subject: bug#35864: ~/.local/bin is missing in default PATH on Guix
>   System
>Message-ID: <20190523153138.6kspxwfzeisntll5@pelzflorian.localdomain>
>Content-Type: text/plain; charset=us-ascii
>
>[...]
>
>Adding ~/.local/bin to the PATH is common on other distros.  When
>compiling and installing software as a user without making a package
>for it, I want to configure it with --prefix=$HOME/.local so I can
>install without sudo.  Then I want to be able to run:
>
>myprog
>
>instead of
>
>PATH=$HOME/.local/bin myprog
>
>In particular, I want instructions to work on all distros, even though
>Debian failed/fails to do this at the moment too.
>
>Regards,
>Florian
>

I personally think including $HOME/.local/bin in PATH by default is
unnecessary because the Guix package manager lets non-root users
install packages and installs from source with the --no-substitutes
option. However if some people don't want take the time to write and
debug a package definition for programs they want to install that are
not included in guix by default, installing to $HOME/.local remains a
valid option.

The simplest way to resolve this is probably to include it in the
skeleton folder in your OS definition (flexible design FTW, am I
right?). Maybe there can be a service to allow this option without
everyone who wants it writing the code themselves?

bug#35893: guix import json does not specify input package's output when provided in the json

[Jesse Gibbons]

I'm trying to generate a package definition from the following json:

{
"name" : "pysolfc",
"version" : "2.6.4",
"source" : "https://github.com/shlomif/PySolFC/archive/pysolfc-2.6.4.tar.gz";
"build-system" : "python",
"home-page" : "https://pysolfc.sourceforge.io/";,
"synopsis" : "Solitaire Collection, Written in Python",
"description" : "PySol Fan Club Edition (PySolFC) is a collection of more 
than 1000 solitaire card games. It is a fork of PySol Solitaire.",
"license" : "GPL-3.0+",
"inputs" : ["python2:tk"],
"propagated-inputs" : ["python2-six"]
}


==
When I run guix import json pysolfc.json >> pysolfc.scm and define the
output as a public package, I get the following:

(define-module (custom packages pysolfc)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system python)
  #:use-module (guix licenses))

(define-public pysolfc
(package
  (name "pysolfc")
  (version "2.6.4")
  (source
(origin
  (method url-fetch)
  (uri (string-append
 "https://github.com/shlomif/PySolFC/archive/pysolfc-";
 version
 ".tar.gz"))
  (sha256
(base32
  "17r9mbn4fj6kbxhllsab74gfjac0j2mjdwkkwaxp6cqpy4dss3z8"
  (build-system python-build-system)
  (inputs
`(("python2" ,(@ (gnu packages python) python-2
  (propagated-inputs
`(("python2-six"
   ,(@ (gnu packages python-xyz) python2-six
  (home-page "https://pysolfc.sourceforge.io/";)
  (synopsis
"Solitaire Collection, Written in Python")
  (description
"PySol Fan Club Edition (PySolFC) is a collection of more than 1000 
solitaire card games. It is a fork of PySol Solitaire.")
  (license gpl3+))
)


When I try to build this I get the following error:

import _tkinter # If this fails your Python may not be configured
for Tk ModuleNotFoundError: No module named '_tkinter'


Conclusion: guix import json doesn't specify the output required by the
json.

bug#36051: "guix import gnu" says public key is not in keyring

[Jesse Gibbons]

I am trying to define the gnurobots package using guix import. I try
the following and get the corresponding results:

~$ guix import gnu gnurobots

Starting download of /tmp/guix-file.sRnZ4I
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz...
 gnurobots-1.2.0.tar.gz  173KiB   163KiB/s 00:01
[##] 100.0%

Starting download of /tmp/guix-file.cZoC7H
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz.sig...
 ….0.tar.gz.sig  72B  170KiB/s 00:00
[##] 100.0% In execvp of gpgv: No such file or directory
guix import: warning: signature verification failed for
`ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz' guix import:
warning: (could be because the public key is not in your keyring) guix
import: error: 'gnu' import failed


~$ guix import gnu --key-download=interactive gnurobots

Starting download of /tmp/guix-file.e0KAGy
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz...
 gnurobots-1.2.0.tar.gz  173KiB   162KiB/s 00:01
[##] 100.0%

Starting download of /tmp/guix-file.lStU1V
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz.sig...
 ….0.tar.gz.sig  72B  111KiB/s 00:00
[##] 100.0% In execvp of gpgv: No such file or directory
guix import: warning: signature verification failed for
`ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz' guix import:
warning: (could be because the public key is not in your keyring) guix
import: error: 'gnu' import failed



~$ guix import gnu --key-download=always gnurobots

Starting download of /tmp/guix-file.DtCU1Y
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz...
 gnurobots-1.2.0.tar.gz  173KiB   178KiB/s 00:01
[##] 100.0%

Starting download of /tmp/guix-file.QOlbzN
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz.sig...
 ….0.tar.gz.sig  72B   48KiB/s 00:00
[##] 100.0% In execvp of gpgv: No such file or directory
guix import: warning: signature verification failed for
`ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz' guix import:
warning: (could be because the public key is not in your keyring) guix
import: error: 'gnu' import failed


 ~$ guix import gnu --key-download=never gnurobots

Starting download of /tmp/guix-file.fgTq6E
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz...
 gnurobots-1.2.0.tar.gz  173KiB   132KiB/s 00:01
[##] 100.0%

Starting download of /tmp/guix-file.v4rsPY
From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz.sig...
 ….0.tar.gz.sig  72B   51KiB/s 00:00
[##] 100.0% In execvp of gpgv: No such file or directory
guix import: warning: signature verification failed for
`ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz' guix import:
warning: (could be because the public key is not in your keyring) guix
import: error: 'gnu' import failed


It appears the --key-download option does nothing, even though the
documentation says --key-download=always should automatically
install the missing keys, and there should be a prompt if the option
is omitted. This is fixed when I install gnupg. It appears guix needs
gnupg as a propagated input for this function to work statelessly.

If anyone has a contrary opinion, please express it. I will
make, test, and submit a patch on Monday if nobody beats me to it.

--Jesse

bug#36051: "guix import gnu" says public key is not in keyring

[Jesse Gibbons]

On Sun, 02 Jun 2019 18:13:16 +0200
Ludovic Courtès  wrote:

> Hi,
> 
> Jesse Gibbons  skribis:
> 
> > Starting download of /tmp/guix-file.cZoC7H
> > From ftp://ftp.gnu.org/gnu/gnurobots/gnurobots-1.2.0.tar.gz.sig...
> >  ….0.tar.gz.sig  72B  170KiB/s 00:00
> > [##] 100.0% In execvp of gpgv: No such file or
> > directory  
> 
> The real issue here is that ‘gpgv’ cannot be found in $PATH.
> 
> I think you have to run “guix install gnupg” to fix it.
> 
> HTH,
> Ludo’.

I pointed that out at the end of my bug report. I thought guix was
supposed to be stateless, with behavior independent on what the user has
installed, so I recommended adding gnupg as a propagated input so it
wouldn't be dependant on a user (or administrator) installing gnupg.
If it is preferrable not to install gnupg alongside guix, then I will
note in the docs that gnupg must be found in $PATH for "guix import
gnu", "guix import elpa" and "guix refresh" to be successful, and then
we can close this issue.

Thanks,
-Jessez

bug#35625: Python3 Cannot Find Existing Shared Library within guix environment

[Jesse Gibbons]

This issue can be closed. Webkitgtk-2.24 uses gcc 7 which must be a
dependency for packages that use it. Luckily my package works just fine
with the older version of webkitgtk.

bug#36430: mcron would benefit from a better way to test jobs

[Jesse Gibbons]

> My issue:

> Defined a mcron job in config.scm scheduled to run once a day,
> with a scheme expression. How do I test this?

Write the mcron job for a local installation of mcron first for
testing purposes, then move it into config.scm. That's how I do it.

> herd schedule mcron lists the job as merely a “Lambda expression”.
> I learned how to give it a descriptive name, but still there’s
> no script linked that I can run by hand.
>
> One major improvement would be to have:
>
> 1. `herd schedule mcron` lists jobs with some kind of id
> 2. `herd execute mcron ` runs the specific mcron job
>
> Or perhaps, any mcron job could be turned into a simple argument-less
> guile or shell script that’s shown in the schedule listing?
>
> Thoughts?
mcron --schedule=count gives you a listing of each scheduled job and
when it will next be run. I would expect "herd schedule mcron" runs
that command. I don't know about scheduling a function, but
if the scheduled job is a string it can be copied/pasted into a
terminal.

mcron is super buggy in my experience. If I power my laptop off
overnight it will skip all jobs scheduled for the day of the month,
even if they are scheduled for after I power it back on. And it doesn't
have a way to easily schedule for a given day of the week.

bug#36636: Tell users to update/reconfigure regularly

[Jesse Gibbons]

On Sun, 14 Jul 2019 18:36:45 +0200
"pelzflorian (Florian Pelz)"  wrote:

> Yes, you are right that unattended upgrades are a more responsible
> default than a notification cron job.  Unattended upgrades would
> resolve this issue.  Should an unattended upgrades service be added to
> Guix’ list of longer-term todos and this bug be closed?
> 
> Regards,
> Florian
> 
> 
> 

How often would the job be run by default? Daily? Weekly? I presume it
would be configurable to run more or less often.

bug#36698: shepherd: list-actions not implemented

[Jesse Gibbons]

I am curious about what actions are implemented in the system services
on my GuixSD install. I try something like the following for the
different system services and get an error:

jesse@piranhaplant ~$ sudo herd list-actions term-tty6
Password:
herd: service 'term-tty6' does not have an action 'list-actions'


Based on what the manual says[1], the 'list-actions' action should be a
special action of every service, so I would expect it to at least either
list the default actions status, start, stop, enable, disable, etc. or
display a message that there are no custom actions defined for the
named service.

Surprisingly I could not find anything related to this in the archives.

[1] https://www.gnu.org/software/shepherd/manual/html_node/Jump-Start.html

bug#36711: transformation 'with-source' had no effect on local git checkout directory

[Jesse Gibbons]

I could not find this bug in the archives. This bug seems a
bit inconsistent.

How to reproduce:
Note that I use a variable after I discovered this does not happen with
some packages.

   my_package=guile-git

1. clone any repository referenced by a package:
   git clone https://gitlab.com/guile-git/guile-git.git checkout

2. modify the repository. I use a harmless comment, but I initially
saw this bug when I made a much greater change:
   cd checkout
   echo ";;;hello world" >> git/blob.scm

3. (optional) build the package with no flags:
   guix build $my_package

4. build the package with the flag "--with-source=$PWD":
   guix build --with-source=$PWD $my_package


output result:
guix build: warning: transformation 'with-source' had no effect on
guile-git@0.2.0 /gnu/store/36vgw4w0dh49n5l5vmlnlmiryhay8i52-guile-git-0.2.0


5. check for the edit:
grep ";;hello world" `guix build --with-source=$PWD \
$my_package`/share/guile/site/2.2/git/blob.scm; echo $?

output: guix build: warning: transformation 'with-source' had no effect
on guile-git@0.2.0 1

If the git repository was used to build anything grep would have found
my comment and returned 0. If the file in question did not exist grep
would have returned 2.

Should I use --with-git-url instead? Probably not. That does not work
either:

guix build --with-git-url=$PWD $my_package

guix build: error: /home/jesse/Documents/tmp/guile-git/checkout:
invalid Git URL replacement specification

Should I commit? Turns out that doesn't help:
git add git/blob.scm
git commit -m"message"
guix build --with-source=$PWD $my_package

guix build: warning: transformation 'with-source' had no effect on
guile-git@0.2.0 /gnu/store/36vgw4w0dh49n5l5vmlnlmiryhay8i52-guile-git-0.2.0

Committing doesn't change the response to --with-git-url=$PWD either,
which is logical given the error message:
guix build --with-git-url=$PWD $my_package

guix build: error: /home/jesse/Documents/tmp/guile-git/checkout:
invalid Git URL replacement specification

Finally I try to build after I delete the .git directory, which makes my
working directory no longer a git checkout directory:
rm -rf .git
guix build --with-source=$PWD guile-gdbm-ffi 

gives me the same result:

guix build: warning: transformation 'with-source' had no effect on
guile-gdbm-ffi@20120209.fa1d5b6 
/gnu/store/s5k6sc82ylbgxajdjvk7ns7i17dvx62r-guile-gdbm-ffi-20120209.fa1d5b6


I would expect this to be different, but I guess that's not the case.

However, this does not happen when I use source from guix itself:

cp --dereference --recursive `guix build --source \
$my_package` ./$my_package
cd $my_package
chmod --recursive u+w .
guix build --with-source=$PWD $my_package

...
successfully
built /gnu/store/0vjqhdwv1rsa40naziy9prq8v1jgbyxr-guile-git-0.2.0.drv

But it does not work when I use . instead of $PWD:
guix build --with-source=. $my_package

guix build: warning: transformation 'with-source' had no effect on
guile-git@0.2.0
/gnu/store/36vgw4w0dh49n5l5vmlnlmiryhay8i52-guile-git-0.2.0

This bug not happen when I try it with the guile-readline package.

Because of this bug, it can be very complicated to develop and install
packages out of a local git clone directory. For example, it becomes
frustrating to check that changes made to the installation process
allow guix to install a package that guix previously couldn't build
before the source is committed and pushed to a remote repository.

I hope this issue has enough information to find a solution.

-Jesse

bug#36868: guix system build autocompletes with package list

[Jesse Gibbons]

In bash, when I type "guix system build" and press tab to autocomplete,
I get a list of packages. I would expect it to list scheme source files
like the "guix system 
{container,disk-image,docker-image,extension-graph,init,reconfigure,shepherd-graph,vm,vm-image}"
 autocompletes. 

bug#36869: gnome-todo won't create new todo list

[Jesse Gibbons]

To replicate:
1. launch gnome-todo
2. Click "New List" in the top-left corner of the window.
3. Create a new list with any name
4. click ok

An error message will appear in the top-center of the window:
"An error occurred... creating a task list [Details]"

5. Click "Details".

An error message shows:
"An error occurred while creating a tak list

The name org.gnome.evolution.dataserver.Source5 was not provided
by any service files."

Any ideas how to fix?

-Jesse

bug#36876: guix system delete-generations removes custom boot menu entries

[Jesse Gibbons]

I dual-booted Guix with another gnu/linux-libre distro.
My configuration includes the other distro in the grub menu. When I run
"sudo guix system delete-generations" the changes to the grub menu drop
the other distro with the older system generations of guix.

My current work-around for this is to run "guix system reconfigure ..."
which includes the boot menu entries specified in the configuration.

bug#36900: key-mon crashes on launch

[Jesse Gibbons]

1. install key-mon
2. run key-mon
it crashes:

(.key-mon-real:5006): Gtk-WARNING **: 16:23:06.088: Unable to locate
theme engine in module_path: "adwaita",

(.key-mon-real:5006): Gtk-WARNING **: 16:23:06.092: Unable to locate
theme engine in module_path: "adwaita",
Traceback (most recent call last):
  File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
1.17/bin/.key-mon-real", line 3, in 
km.main()
  File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
1.17/lib/python2.7/site-packages/keymon/key_mon.py", line 1032, in main
keymon = KeyMon(opts)
  File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
1.17/lib/python2.7/site-packages/keymon/key_mon.py", line 130, in
__init__
self.devices = xlib.XEvents()
  File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
1.17/lib/python2.7/site-packages/keymon/xlib.py", line 80, in __init__
self.record_display = display.Display()
  File "/gnu/store/4xl1xl2fp6c0c9f9pm1xm10x1qgbwp08-python2-xlib-
0.14/lib/python2.7/site-packages/Xlib/display.py", line 85, in __init__
self.display = _BaseDisplay(display)
  File "/gnu/store/4xl1xl2fp6c0c9f9pm1xm10x1qgbwp08-python2-xlib-
0.14/lib/python2.7/site-packages/Xlib/display.py", line 67, in __init__
apply(protocol.display.Display.__init__, (self, ) + args, keys)
  File "/gnu/store/4xl1xl2fp6c0c9f9pm1xm10x1qgbwp08-python2-xlib-
0.14/lib/python2.7/site-packages/Xlib/protocol/display.py", line 121,
in __init__
raise error.DisplayConnectionError(self.display_name, r.reason)
Xlib.error.DisplayConnectionError: Can't connect to display ":1": No
protocol specified



One possible reason it crashes is the python2-xlib is far outdated. The
package was added in patch db62afa55ad443cc50bcafe64eb3ba239eae9c11
(2015) and has been version 0.14 ever since. The website says it has
been migrated to github, which says the most recent stable release is
0.25. It looks like there is a similar issue (though not identical) htt
ps://github.com/python-xlib/python-xlib/issues/53 which was fixed.

I will see if updating python2-xlib fixes this, and if so I will send a
patch.

Any objections?

-- 
-Jesse

bug#36900: key-mon crashes on launch

[Jesse Gibbons]

On Fri, 2019-08-02 at 16:40 -0600, Jesse Gibbons wrote:
> 1. install key-mon
> 2. run key-mon
> it crashes:
> 
> (.key-mon-real:5006): Gtk-WARNING **: 16:23:06.088: Unable to locate
> theme engine in module_path: "adwaita",
> 
> (.key-mon-real:5006): Gtk-WARNING **: 16:23:06.092: Unable to locate
> theme engine in module_path: "adwaita",
> Traceback (most recent call last):
>   File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
> 1.17/bin/.key-mon-real", line 3, in 
> km.main()
>   File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
> 1.17/lib/python2.7/site-packages/keymon/key_mon.py", line 1032, in
> main
> keymon = KeyMon(opts)
>   File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
> 1.17/lib/python2.7/site-packages/keymon/key_mon.py", line 130, in
> __init__
> self.devices = xlib.XEvents()
>   File "/gnu/store/jkjmj9l72rmnh642dyprnpwgmz4mn6cx-key-mon-
> 1.17/lib/python2.7/site-packages/keymon/xlib.py", line 80, in
> __init__
> self.record_display = display.Display()
>   File "/gnu/store/4xl1xl2fp6c0c9f9pm1xm10x1qgbwp08-python2-xlib-
> 0.14/lib/python2.7/site-packages/Xlib/display.py", line 85, in
> __init__
> self.display = _BaseDisplay(display)
>   File "/gnu/store/4xl1xl2fp6c0c9f9pm1xm10x1qgbwp08-python2-xlib-
> 0.14/lib/python2.7/site-packages/Xlib/display.py", line 67, in
> __init__
> apply(protocol.display.Display.__init__, (self, ) + args, keys)
>   File "/gnu/store/4xl1xl2fp6c0c9f9pm1xm10x1qgbwp08-python2-xlib-
> 0.14/lib/python2.7/site-packages/Xlib/protocol/display.py", line 121,
> in __init__
> raise error.DisplayConnectionError(self.display_name, r.reason)
> Xlib.error.DisplayConnectionError: Can't connect to display ":1": No
> protocol specified
> 
> 
> 
> One possible reason it crashes is the python2-xlib is far outdated.
> The
> package was added in patch db62afa55ad443cc50bcafe64eb3ba239eae9c11
> (2015) and has been version 0.14 ever since. The website says it has
> been migrated to github, which says the most recent stable release is
> 0.25. It looks like there is a similar issue (though not identical)
> htt
> ps://github.com/python-xlib/python-xlib/issues/53 which was fixed.
> 
> I will see if updating python2-xlib fixes this, and if so I will send
> a
> patch.
> 
> Any objections?
> 

Updating python2-xlib does not fix this bug.
-- 
-Jesse

bug#36925: guix pack -R or -RR will not produce outputs other than 'out'

[Jesse Gibbons]

This happens with all the packages I have tried. For example,
`guix pack --dry-run -R ghc:doc` fails with the message:

$ guix pack --dry-run -R ghc:doc
guix pack: error: reference to invalid output 'doc' of derivation
'/gnu/store/a0blj0d79mzgvb4fk8fkai51xjf68s7z-ghc-8.4.3R.drv'

I get similar results if I change -R to -RR:

$ guix pack --dry-run -RR ghc:doc
guix pack: error: reference to invalid output 'doc' of derivation
'/gnu/store/905g4g323i8ngdfnmqdgdm89z66ikj07-ghc-8.4.3R.drv'

However, if I leave out the -R or -RR flag, it succeeds:

$ guix pack --dry-run ghc:doc
substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0%
The following derivations would be built:
   /gnu/store/4qnslab7r748r44ydc3zcni0zgfsicak-tarball-pack.tar.gz.drv
   /gnu/store/p3k0xh40ypv7vnvd70jarswn0yykvi8m-profile.drv
0.0 MB would be downloaded:
   /gnu/store/sw8vw31fnmfrjhb32sxvvy0yxrx9s1hc-mkfontscale-1.2.1
   /gnu/store/3rgvdjy72vqsv45f85b0phpirnzxb4w2-mkfontdir-1.0.7
The following profile hooks would be built:
   /gnu/store/1rlk94msgnanr5yyhmx5hck5b3xvsmxa-info-dir.drv
   /gnu/store/56qn66jcnwg8rkz7w0mfw0qkx1fx997n-ghc-package-cache.drv
   /gnu/store/8bpnr5pkzjnlj1zzrcjgr26x1yyyw82l-manual-database.drv
   /gnu/store/d7l70fw7zyg7mpkxnm87v69cphfi4s9z-fonts-dir.drv
   /gnu/store/f4xcbmbzzq32g8ywy8z96pyr89qni1g6-ca-certificate-
bundle.drv

The --dry-run flag is not necessary to replicate this bug. I included
it to keep success output short and (hopefully) help narrow down when
the bug happens.

-- 
-Jesse

bug#36931: guile-bash repository no longer exists?

[Jesse Gibbons]

guile-bash fails to build. The site https://anonscm.debian.org/cgit/use
rs/kaction-guest/retired/dev.guile-bash.git says it is not on the web
server.

I checked the wayback machine, github, and gitlab for some sort of
backup, but have had no luck. Is there a trustworthy replacement
source? If not, I'm not sure we should keep the package.

bug#36931: guile-bash repository no longer exists?

[Jesse Gibbons]

On Mon, 2019-08-05 at 16:38 +0200, Ricardo Wurmus wrote:
> Jesse Gibbons  writes:
> 
> > guile-bash fails to build. The site https://anonscm.debian.org/cgit
> > /use
> > rs/kaction-guest/retired/dev.guile-bash.git says it is not on the
> > web
> > server.
> 
> Perhaps a copy of the sources can be found in the Software Heritage
> archive?
> 
> --
> Ricardo
> 

I don't know if it's exactly the same, but I found something similar at
https://archive.softwareheritage.org/browse/origin/https://github.com/k
action/guile-bash/directory/
Thanks for the suggestion.

I requested a tarball, and received this statement in the email:
"Please keep in mind that this link might expire at some point, in
which case you will need to request the bundle again."

Do you have any recommendations on where to host the tarball? If
necessary, I am willing to create a repository for the code on my
github.

bug#36876: guix system delete-generations removes custom boot menu entries

[Jesse Gibbons]

On Mon, 2019-08-05 at 12:05 -0400, Jakob L. Kreuze wrote:
> ...
> 
> I don't think this should be _too_ hard to fix. To me, parsing the
> installed Grub configuration to get existing menu entries seems like
> a
> logical step forward.
> 
> Thoughts from anyone else?
> 
> Regards,
> Jakob

Alternatively, we could save in the store a derivation for the the grub
config generated from the bootloader of the configuration. When the
user calls "guix system delete-generations", the derivation can be run,
and the remaining system generations (if any) can be appended in a menu
like when the user calls "guix system reconfigure". (Although it does
not work for me right now, I'm assuming "guix system delete-generations 
2m" as described in the manual will be implemented in the future.)

The immediate downsides I see to my solution:

- It would take space in the store per generation, which can add up if
the user does not often call "guix system delete-generations" and calls
"guix system reconfigure" on a healthy basis. The user could just be
reminded to call "guix system delete-generations" occasionally, and any
 official service that automatically updates the system via "guix
system reconfigure" can (and considering how large a generation with a
lot of updated system packages can get, probably should) also be
configured to call "guix system delete-generations".

- If someone hand-edits the grub config the changes would be lost. This
is the case as it is right now, and grub options can be edited in the
configuration, so I'm not too concerned about this.

-It would be much simpler to identify menu entries generated by guix
that are no longer in the store and remove them, and remove all empty
submenus. Parsing would make hand-editing grub.cfg more dangerous than
a solution that simply scraps the hand-made changes and rebuilds as I
propose, because the user doing the hand-editing would not necessarily
be aware what patterns the parser checks. It would also be inconsitent:
edits to grub.cfg being scrapped when "guix system reconfigure" is
called, but not when 'guix system delete-generations" is called looks
to me like a good way to introduce a bug to the more adventurous
"Murphy's Law"-type users down the road.


These are just my thoughts. I would love to hear other downsides to my
solution.

-- 
-Jesse

bug#36951: guile-sly will not build

[Jesse Gibbons]

When I try `guix build guile-sly` it gives the error "configure: error:
freeimage not found."

When I try to manually build guile-sly, I get additional information:
ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc-
profile/lib/libfreeimage.so: undefined reference to `PerfTimerStart'
ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc-
profile/lib/libfreeimage.so: undefined reference to
`PerfTimerCopyStartTime'
ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc-
profile/lib/libfreeimage.so: undefined reference to
`PerfTimerGetResults'
ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc-
profile/lib/libfreeimage.so: undefined reference to `PerfTimerStop'
ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc-
profile/lib/libfreeimage.so: undefined reference to `PerfTimerDelete'
ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc-
profile/lib/libfreeimage.so: undefined reference to `PerfTimerNew'
collect2: error: ld returned 1 exit status


I looked into freeimage. The missing function reference should be
defined in the libjxr bundled with freeimage.

Some related history:
- commit a5d4c96b8d90b8bb87e07bd6a7be78991db91bc9 (http://git.savannah.
gnu.org/cgit/guix.git/commit/gnu/packages/image.scm?id=a5d4c96b8d90b8bb
87e07bd6a7be78991db91bc9) gnu: freeimage: Remove bundled libraries.
- commit f347c24acc14e080dc2801561edca0d525a90257 (http://git.savannah.
gnu.org/cgit/guix.git/commit/gnu/packages/image.scm?id=f347c24acc14e080
dc2801561edca0d525a90257) gnu: freeimage: Use bundled libjxr.

- bug #28261 (https://issues.guix.gnu.org/issue/28261) freeimage uses
bundled libraries

- commit 37dc29200c44adc0474476b8df46ed44e8a1d41a (http://git.savannah.
gnu.org/cgit/guix.git/commit/gnu/packages/maths.scm?id=37dc29200c44adc0
474476b8df46ed44e8a1d41a) gnu: Add opencascade-occt.

- bug #34013 (https://issues.guix.gnu.org/issue/34013) [PATCH 1/2] gnu:
libjxr: Build and install shared library.

It seems commit f347c24acc14e080dc2801561edca0d525a90257 was an attempt
to fix guile-sly, but it looks like it was unsuccessful.

Commit 37dc29200c44adc0474476b8df46ed44e8a1d41a mentions a similar
issue and has a work-around. I do not think the configure script will
be as cooperative with this work-around because it checks for FreeImage
unconditionally.

- bug #34013 was a patch submitted in January but nobody has responded
to it. I don't know if it will fix this issue, but it's worth
reviewing.

-- 
-Jesse

bug#37164: Generated installation image does not include grub.

[Jesse Gibbons]

1. generate the install image
 guix system disk-image --file-system-type=iso9600 --verbosity=3 --
root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
system install) installation-os)'

2. examine the resulting iso
readlink installation-os-x86_64.iso | xargs file

output: /gnu/store/3xp541s4zrxass6h6rcwfz7bc33wv84p-disk-image: DOS/MBR
boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-
CHS (0xe3,198,58), startsector 2048, 3657239 sectors; partition 2 :
ID=0xef, start-CHS (0xe3,198,59), end-CHS (0xe8,224,16), startsector
3659287, 81921 sectors

3. Compare this output with what file says about the official
installation iso:
wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.x86_64-linu
x.iso.xz
unxz guix-system-install-1.0.1.x86_64-linux.iso.xz
readlink guix-system-install-1.0.1.x86_64-linux.iso

output:guix-system-install-1.0.1.x86_64-linux.iso: DOS/MBR boot sector;
GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2
address 0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201;
partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3f6,38,4),
startsector 1, 2694403 sectors, extended partition table (last)

It appears file discovered the GRand Unified Bootloader in the official
iso but not in the generated iso.

When I try to use the generated iso in virt-manager, it claims there
are no bootable drives. I think this is because the generated iso has
no GRUB.

The manual says to specify the file gnu/system/install.scm instead of
the value (@ (gnu system install) installation-os)) but ultimately they
give guix the same value, so I think that wouldn't make a difference.

removing --system=x86_64 does not trigger a full rebuild, so it looks
like guix does not expect to build anything different.

Guix describe outputs:

Generation 47   Aug 23 2019 09:22:24(current)
  guix d78bc23
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d78bc23411b1351ff9495a511c22b27d17f9226f

GUIX_PACKAGE_PATH="/home/jesse/Documents/broken-guix/Broken-Guix-
Packages"

Thanks
-Jesse

bug#37190: rhythmbox cannot subscribe to any podcasts

[Jesse Gibbons]

To replicate:
1. open rhythmbox (rhythmbox 3.4.3)
2. go to "podcasts" tab
3. Click "Add" button.
4. In the search bar, search for any podcast. Note that in order to get
results there needs to be internet access.
5. Click on any of the results. An error message will drop down that
says "Unable to load the feed. Check your network connection."

I tried this with debug output. All I found that could help is
something like this:

(20:56:56) [0x13764d0] [rb_audioscrobbler_should_handshake] rb-
audioscrobbler.c:839: No username set
(20:56:56) [0x13764d0] [rb_audioscrobbler_should_handshake] rb-
audioscrobbler.c:839: No username set

-It was only logged after rhythmbox logged that search results were
loaded and was logged almost every time.
-It was logged in pairs
-Clicking the "subscribe" button did not cause rhythmbox to log it.


I checked on PureOS in a VM, (rhythmbox 3.4.3) this does not happen. I
did not check with other OSes.

Any help would be appreciated.
-- 
-Jesse

bug#37164: Generated installation image does not include grub.

[Jesse Gibbons]

On Mon, 2019-08-26 at 22:44 +0200, Gábor Boskovits wrote:
> Hello,
> 
> Jesse Gibbons  ezt írta (időpont: 2019. aug.
> 23., P, 19:41):
> > 1. generate the install image
> >  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> > system install) installation-os)'
> > 
> 
> Just a wild guess, does it work with the verbosity option removed?
> I had issues with that in the past.
I tried generating an install image with --verbosity and another
without --verbosity. There was no difference because guix does not
expect the --verbosity option to make a difference.

I deleted the link and ran the garbage collector, then tried building
the image without --verbosity, but file does not detect grub. I think
it isn't a problem with 'file' because a virtual machine setup with
virt-manager does not think the ISO is bootable.

bug#37164: Generated installation image does not include grub.

[Jesse Gibbons]

On Tue, 2019-08-27 at 07:09 +0200, Gábor Boskovits wrote:
> Hello,
> 
> Jesse Gibbons  ezt írta (időpont: 2019. aug.
> 27., K, 4:48):
> > On Mon, 2019-08-26 at 22:44 +0200, Gábor Boskovits wrote:
> > > Hello,
> > > 
> > > Jesse Gibbons  ezt írta (időpont: 2019.
> > aug.
> > > 23., P, 19:41):
> > > > 1. generate the install image
> > > >  guix system disk-image --file-system-type=iso9600 --
> > verbosity=3 --
> > > > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@
> > (gnu
> > > > system install) installation-os)'
> > > > 
> > > 
> > > Just a wild guess, does it work with the verbosity option
> > removed?
> > > I had issues with that in the past.
> > I tried generating an install image with --verbosity and another
> > without --verbosity. There was no difference because guix does not
> > expect the --verbosity option to make a difference.
> > 
> > I deleted the link and ran the garbage collector, then tried
> > building
> > the image without --verbosity, but file does not detect grub. I
> > think
> > it isn't a problem with 'file' because a virtual machine setup with
> > virt-manager does not think the ISO is bootable.
> 
> Is it possible that you are hit by this issue?
> https://issues.guix.gnu.org/issue/36865
I don't see how grub.cfg not being a GC root could cause guix to build
an ISO without GRUB. Perhaps you could clarify your thoughts?

> Could you try again after guix pull?
I pull'd but nothing changed.


commit according to guix describe:
48752f277c589435aab4d80947fa80f01577d55d


> Best regards,
> g_bor
> 

I tried the following:
cd ~/.config/guix/current/share/guile/site/2.2/gnu/system/examples/
guix system disk-image --file-system-type=iso9600 bare-bones.tmpl |
xargs file

end result:
/gnu/store/g1ba8gkhkcjkdraxpnrw166i5qpa7cb9-disk-image: DOS/MBR boot
sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS
(0xac,86,27), startsector 2048, 2766577 sectors; partition 2 : ID=0xef,
start-CHS (0xac,86,28), end-CHS (0xb1,111,48), startsector 2768625,
81921 sectors


As you can see, GRUB was not detected by file.

I noticed guix outputs odd characters when I try to build an ISO.
Here's a sample:
/��@ build-log 23054 1
�@ build-log 23054 1
�@ build-log 23054 1
"@ build-log 23054 1
)@ build-log 23054 1
@ build-log 23054 1

\��@ build-log 23054 1
�@ build-log 23054 1
�@ build-log 23054 1
)@ build-log 23054 1
@ build-log 23054 1

-��@ build-log 23054 1
�@ build-log 23054 1
�@ build-log 23054 1
>@ build-log 23054 1
)@ build-log 23054 1
@ build-log 23054 1

\��@ build-log 23054 1
�@ build-log 23054 1
�@ build-log 23054 1
"@ build-log 23054 1
)@ build-log 23054 1
 @ build-log 23054 1
�@ build-log 23054 1
�@ build-log 23054 1
�@ build-log 23054 1
)@ build-log 23054 1
@ build-log 23054 1

Perhaps this could be related.

I'm curious if anyone is able to replicate this bug.
-- 
-Jesse

bug#37164: Generated installation image does not include grub.

[Jesse Gibbons]

On Thu, 2019-08-29 at 02:34 +0200, Danny Milosavljevic wrote:
> > Jesse Gibbons  skribis:
> > 
> > > 1. generate the install image
> > >  guix system disk-image --file-system-type=iso9600 --verbosity=3
> > > --
> > > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@
> > > (gnu
> > > system install) installation-os)'
> 
> There's a typo there :)
> 
> You wrote: iso9600
> It should be: iso9660
> 
> But the error message could be vastly improved O_o
It looks like this solves the issue. 

bug#37226: previously working system config fails to build

[Jesse Gibbons]

I try to run guix system reconfigure and get this error:

guix system: error: #< type: dce bv: #vu8(51 12 55 214 249 221 79
112 186 51 233 64 103 99 34 57)>: invalid G-expression input


Here's the minimum of what I feed it to replicate the error (comments
and non-essentials removed):

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop pm virtualization networking cups sound)
(use-package-modules certs gnome guile-xyz)

(define pureos-root "330c37d6-f9dd-4f70-ba33-e94067632239")
(define swap-uuid "049a0350-bcce-4920-9816-5fd4ee3c0de1")

(define (other-partition entry-label vmlinuz-version root-uuid resume-
uuid)
  (menu-entry
   (label "pureos")
   (linux (string-concatenate `("/boot/vmlinuz-" ,vmlinuz-version)))
   (linux-arguments
`(,(string-concatenate `("root=UUID=" ,root-uuid))
  "ro" "quiet" "splash"
  ,(string-concatenate `("resume=UUID=" ,resume-uuid
   (initrd (string-concatenate `("/boot/initrd.img-" ,vmlinuz-
version)))
   (device (uuid root-uuid


(operating-system
 (host-name "piranhaplant")
 (timezone "America/Boise")
 (locale "en_US.utf8")
 (bootloader (bootloader-configuration
  (bootloader grub-bootloader)
  (target "/dev/sda") ;include my usual OS
  (menu-entries
   (list
(other-partition
 "pureos"
 "4.19.0-2-amd64"
 pureos-root
 swap-uuid)

 (file-systems (cons (file-system
  (device (file-system-label "my-root"))
  (mount-point "/")
  (type "ext4"))
 %base-file-systems))

 )


Please forgive the ugly formatting and quasiquote/unquote abuse. I was
beginning to understand scheme when I wrote the .

It breaks when I add (file-system ...) which is identical to what's in
the manual. I think it might have something to do with the bootloader,
but I don't know what. Where is a G-expression expected?

bug#37226: previously working system config fails to build

[Jesse Gibbons]

On Thu, 2019-08-29 at 21:32 -0600, Jesse Gibbons wrote:
> I try to run guix system reconfigure and get this error:
> 
> guix system: error: #< type: dce bv: #vu8(51 12 55 214 249 221
> 79
> 112 186 51 233 64 103 99 34 57)>: invalid G-expression input
> 
> 
> Here's the minimum of what I feed it to replicate the error (comments
> and non-essentials removed):
> 
> (use-modules (gnu) (gnu system nss))
> (use-service-modules desktop pm virtualization networking cups sound)
> (use-package-modules certs gnome guile-xyz)
> 
> (define pureos-root "330c37d6-f9dd-4f70-ba33-e94067632239")
> (define swap-uuid "049a0350-bcce-4920-9816-5fd4ee3c0de1")
> 
> (define (other-partition entry-label vmlinuz-version root-uuid
> resume-
> uuid)
>   (menu-entry
>(label "pureos")
>(linux (string-concatenate `("/boot/vmlinuz-" ,vmlinuz-version)))
>(linux-arguments
> `(,(string-concatenate `("root=UUID=" ,root-uuid))
>   "ro" "quiet" "splash"
>   ,(string-concatenate `("resume=UUID=" ,resume-uuid
>(initrd (string-concatenate `("/boot/initrd.img-" ,vmlinuz-
> version)))
>(device (uuid root-uuid
> 
> 
> (operating-system
>  (host-name "piranhaplant")
>  (timezone "America/Boise")
>  (locale "en_US.utf8")
>  (bootloader (bootloader-configuration
>   (bootloader grub-bootloader)
>   (target "/dev/sda") ;include my usual OS
>   (menu-entries
>  (list
>   (other-partition
>  "pureos"
>  "4.19.0-2-amd64"
>  pureos-root
>  swap-uuid)
> 
>  (file-systems (cons (file-system
>   (device (file-system-label "my-root"))
> (mount-point "/")
> (type "ext4"))
>  %base-file-systems))
> 
>  )
> 
> 
> Please forgive the ugly formatting and quasiquote/unquote abuse. I
> was
> beginning to understand scheme when I wrote the .
> 
> It breaks when I add (file-system ...) which is identical to what's
> in
> the manual. I think it might have something to do with the
> bootloader,
> but I don't know what. Where is a G-expression expected?

The menu entry with the other partition is the problem. I'm not sure
what to do to keep the pureos partition, so I will comment it out. 
Specifically, I think it's the (device) field of  which
took a uuid as specified in the manual.

Ludo, you wanted to know if anything is out of place when you closed
bug#36876 "guix system delete-generations removes custom boot menu
entries". I think this might be related. Is there anything that might
not be documented that needs to happen differently to add a menu item
to grub?
-- 
-Jesse

bug#37286: Make a faster method to list supported boards.

[Jesse Gibbons]

There should be a faster way to list the supported boards with custom
versions of U-Boot.

>From manual:
Many ARM boards require a specific variant of the U-Boot
(https://www.denx.de/wiki/U-Boot/) bootloader.

   If you build a disk image and the bootloader is not available
otherwise (on another boot drive etc), it’s advisable to build an image
that includes the bootloader, specifically:

 guix system disk-image --system=armhf-linux -e '((@ (gnu system
install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-
OLinuXino-Lime2")'

   ‘A20-OLinuXino-Lime2’ is the name of the board.  If you specify an
invalid board, a list of possible boards will be printed.



I think an example of an invalid board is "dne-board", which (last I
checked) does not exist and probably never will exist. If I run the
following command:

guix system disk-image --system=armhf-linux -e '((@ (gnu system
install) os-with-u-boot) (@ (gnu system install) installation-os) "dne-
board")'

guix tries to build an entire system. It doesn't look like it checks if
"dne-board" is a valid board until it is building the image. It takes
hours to cross-compile the kernel, and even longer if the kernel needs
to be deblobbed. I have not yet been able to cross-compile any system
using this method.

bug#37286: Make a faster method to list supported boards.

[Jesse Gibbons]

On Mon, 2019-09-02 at 22:49 +0200, Danny Milosavljevic wrote:
> Hi,
> 
> On Mon, 02 Sep 2019 12:52:49 -0600
> Jesse Gibbons  wrote:
> 
> > guix tries to build an entire system. It doesn't look like it
> > checks if
> > "dne-board" is a valid board until it is building the image. It
> > takes
> > hours to cross-compile the kernel, and even longer if the kernel
> > needs
> > to be deblobbed.
> 
> Yes, that's true.
> 
> For better or for worse, there are a LOT of different ARM boards.
> 
> Back when I implemented that part I thought that when you want to
> find out
> whether your board is supported, there's a good chance that you want
> to
> install Guix anyway--so you need the system image anyway.
If the bootloader build fails, which appears necessary to generate the
list, doesn't the system build fail?
> 
> If it turns out not to be supported you just uselessly built a lot of
> stuff--but the substitute cache should have cached all that stuff
> anyway.
> 
> But for some reason the ARM build farm substitute cache has a very
> bad hit
> rate (I remember waiting MONTHS to finally get a "flash-image"
> substitute
> that I didn't build myself).
It would be good to find out what's going on there. How many concurrent
builds can the build farm handle? 
> 
> If we decided to do so, we could limit ourselves to just a few that
> we
> specially support--but that would make Guix System really a non-
> universal
> operating system.  (with the current state of Guix ARM implementation
> it is
> anyway)
Guix is a libre operating system. The fact that you need to carefully
choose the hardware it can use means universal use is not officially
supported. But if hardware is supported, I think we should be able to
install guix onto it, and the users should be able to look up if it is
supported.
> 
> It would be easy to get the list of supported u-boot targets from the
> derivation.  It might be that Guix Data Service would help with that
> (see "More progress with the Guix Data Service" by Christopher
> Baines).
That sounds like an interesting article, but my search engine of choice
doesn't know where it is. Would you mind providing a link please?
> 
> Or we can maintain a list in the package definition ourselves.
The list would be most accurate if :
- The user keeps the building install up-to-date.
- We keep the list up-to-date.
This solution is good as long as we are diligent to update the list
when a new board is added.
> 
> What do you think?
The behavior described in the manual is implemented in the make-u-boot-
package function in gnu/packages/bootloaders.scm, in the replaced
'configure phase. If it could be moved from that function to a script
(maybe guix system list-boards), that would be the best solution IMHO. 

At this point, the fastest way to get the list would be "guix package
-e '((@ (gnu packages bootloaders) make-u-boot-package) "dneboard"
"arm-linux-gnueabihf")'" and view the end of the resulting log. I
tested this, and it takes a minute at most. It's still needlessly
complicated though -- the boards listed are not limited to the triplet.

Here's what it gives me (it's very long):
Invalid board name. Valid board names are:- 10m50
- 3c120
- A10-OLinuXino-Lime
- A10s-OLinuXino-M
- A13-OLinuXino
- A13-OLinuXinoM
- A20-Olimex-SOM-EVB
- A20-Olimex-SOM204-EVB-eMMC
- A20-Olimex-SOM204-EVB
- A20-OLinuXino-Lime2-eMMC
- A20-OLinuXino-Lime2
- A20-OLinuXino-Lime
- A20-OLinuXino_MICRO-eMMC
- A20-OLinuXino_MICRO
- A33-OLinuXino
- a64-olinuxino
- adp-ae3xx
- adp-ag101p
- ae350_rv32
- ae350_rv64
- Ainol_AW1
- alt
- am335x_baltos
- am335x_boneblack_vboot
- am335x_evm
- am335x_hs_evm
- am335x_hs_evm_uart
- am335x_igep003x
- am335x_pdu001
- am335x_shc
- am335x_shc_ict
- am335x_shc_netboot
- am335x_shc_sdboot
- am335x_sl50
- am3517_crane
- am3517_evm
- am43xx_evm
- am43xx_evm_qspiboot
- am43xx_evm_rtconly
- am43xx_evm_usbhost_boot
- am43xx_hs_evm
- am57xx_evm
- am57xx_hs_evm
- am57xx_hs_evm_usb
- am65x_evm_a53
- am65x_evm_r5
- amarula_a64_relic
- amcore
- Ampe_A76
- ap121
- ap143
- ap325rxa
- ap_sh4a_4a
- apalis-tk1
- apalis_imx6
- apalis_imx6_nospl_com
- apalis_imx6_nospl_it
- apalis_t30
- apf27
- apx4devkit
- aristainetos2
- aristainetos2b
- aristainetos
- armadillo-800eva
- arndale
- aspenite
- astro_mcf5373l
- at91rm9200ek
- at91rm9200ek_ram
- at91sam9260ek_dataflash_cs0
- at91sam9260ek_dataflash_cs1
- at91sam9260ek_nandflash
- at91sam9261ek_dataflash_cs0
- at91sam9261ek_dataflash_cs3
- at91sam9261ek_nandflash
- at91sam9263ek_dataflash_cs0
- at91sam9263ek_dataflash
- at91sam9263ek_nandflash
- at91sam9263ek_norflash_boot
- at91sam9263ek_norflash
- at91sam9g10ek_dataflash_cs0
- at91sam9g10ek_dataflash_cs3
- at91sam9g10ek_na

bug#37293: image-size is meaningless when generating ext4 images

[Jesse Gibbons]

The manual says in multiple places the --image-size option should set
the size of a generated ext4 disk image.

I start with a minimalist configuration (attached: minimal.scm) and run
build-minimal-os.sh (attached). I start virt-manager and make a new
virtual machine with the generated img as the disk image. virt-manager
says the disk image is 20G. So far so good...

I run "guix pull" and it fails because it runs out of disk space.

I run df -h and see the partition mounted on / has only 494M.
available.

I run cfdisk /dev/sda and see the first partition is 20G.

I have added quite a bit to the minimal os, but have not changed the
behavior. The attached minimal.scm is my most recent version.

Does anyone know of a way to expand the main partition's size?

Thanks,

-- 
-Jesse

build-minimal-os.sh
Description: application/shellscript
(use-modules (gnu)
	 (gnu services networking))

(operating-system
 (bootloader
  (bootloader-configuration
  (bootloader grub-bootloader)))
  (host-name "minimal-os")
 (file-systems (cons*
		(file-system
		 (type "ext4")
		 (mount-point "/")
		 (device "/dev/sda1")
		 (needed-for-boot? #t)
		 (create-mount-point? #t))
		%base-file-systems))
 (packages (cons*
	%base-packages))

 (services
  (cons*
   (service network-manager-service-type)
   (service wpa-supplicant-service-type)
   %base-services))
 (timezone "America/Denver"))

bug#37293: image-size is meaningless when generating ext4 images

[Jesse Gibbons]

On Mon, 2019-09-02 at 20:48 -0600, Jesse Gibbons wrote:
> The manual says in multiple places the --image-size option should set
> the size of a generated ext4 disk image.
> 
> I start with a minimalist configuration (attached: minimal.scm) and
> run
> build-minimal-os.sh (attached). I start virt-manager and make a new
> virtual machine with the generated img as the disk image. virt-
> manager
> says the disk image is 20G. So far so good...
> 
> I run "guix pull" and it fails because it runs out of disk space.
> 
> I run df -h and see the partition mounted on / has only 494M.
> available.
> 
> I run cfdisk /dev/sda and see the first partition is 20G.
> 
> I have added quite a bit to the minimal os, but have not changed the
> behavior. The attached minimal.scm is my most recent version.
> 
> Does anyone know of a way to expand the main partition's size?
> 
> Thanks,
> 
If I take build-minimal-os.sh and have it build a qcow2 vm-image
instead of an ext4 disk-image it says I found a bug. I think it might
be related, but it doesn't give me any details.

bug#37345: Icecat doesn't display numbers on Guix System

[Jesse Gibbons]

On Sun, 2019-09-08 at 23:10 +0200, Jan wrote:
> Hi everyone,
> I've recently installed Icecat on Guix System natively and it doesn't
> display numbers properly - instead of numbers, there are transparent
> squares without a black frame - they're just invisible globally, no
> matter if on a website or in the browser's interface.
> Tried changing font to GNU unifont (because it supports the whole
> unicode), reinstalling Icecat (which shouldn't help anyway, because
> Guix is reproducible, including bugs), guix pulling, system
> reconfiguration, but nothing helps.
> I have this issue only on Icecat, because ungoogled chromium and
> other
> programs display numbers properly. 
> 
> architecture: x86_64
> 
> I saw a similar bug in the database, but it's from 2017 and it was
> about font issue on other distributions, not on Guix System, so I
> submitted a new report, hope that's not a problem.
> 
> Jan Wielkiewicz 
> 
> 
> 
I cannot replicate.
What commit did you notice this? (guix describe)
Are there any settings different from the default?

bug#37345: Icecat doesn't display numbers on Guix System

[Jesse Gibbons]

Hi Jan,
On Mon, 2019-09-09 at 00:18 +0200, Jan wrote:
> Okay, I found some probably more helpful info - I run icecat in a
> terminal and it throws the following warnings, don't know if they're
> related to this bug though:
> ...
> (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-
> guix1/lib/icecat/.icecat-real:4648):
> Pango-WARNING **: 22:11:58.541: failed to create cairo scaled font,
> expect ugly output. the offending font is 'Nimbus Sans L
> 9.9990234375'
> 
> (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-
> guix1/lib/icecat/.icecat-real:4648):
> Pango-WARNING **: 22:11:58.541: font_face status is: file not found
> 
> (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-
> guix1/lib/icecat/.icecat-real:4648):
> Pango-WARNING **: 22:11:58.541: scaled_font status is: file not found
> 
> (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-
> guix1/lib/icecat/.icecat-real:4648):
> Pango-WARNING **: 22:11:58.541: shaping failure, expect ugly output.
> shape-engine='PangoFcShapeEngine', font='Nimbus Sans L 9.9990234375',
> text=''
> 
> (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-
> guix1/lib/icecat/.icecat-real:4648):
> Pango-WARNING **: 22:11:58.546: failed to create cairo scaled font,
> expect ugly output. the offending font is 'Nimbus Sans L
> 9.9990234375'
> 
> (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-
> guix1/lib/icecat/.icecat-real:4648):
> Pango-WARNING **: 22:11:58.546: font_face status is: file not found
> 
> (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0-
> guix1/lib/icecat/.icecat-real:4648):
> Pango-WARNING **: 22:11:58.546: scaled_font status is: file not found
> 
> 
> ...
> ---
> 
> Jan Wielkiewicz
> 
> 
> 
Looks like it isn't finding the "Nimbus Sans L" font. Try running 

fc-list | grep "Nimbus Sans L"

and reply with the output.
-- 
-Jesse

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Jesse Gibbons]

On Mon, 2019-09-09 at 02:49 +0200, Jan wrote:
> Hi, I'm a new Guix user and I wanted to hack on Guix and update a
> package, I hadn't known exactly how to do this, so I started
> following
> instructions from
> https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-In
> stalled.html#Running-Guix-Before-It-Is-Installed
> and
> https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/
> 
> The situation started to be interesting, when the tutorial told me to
> run "cd $GUIX_CHECKOUT" and "./pre-inst-env guix package
> --list-available=ruby"
> I was confused, because I couldn't find any "./pre-inst-env" file, so
> I
> used 'find' to search for it and there were one file with a similar
> name
> in $GUIX_CHECKOUT/build-aux - ./pre-inst-env.in (as I'm composing
> this
> email now I see that's stupid, but I tried using this file, as I
> don't
> know what I was doing (still don't know))
> So I started running the following stupid commands:
> 
> 
> user@machine ~/Prog/repo/guix [env]$ sudo -E ./pre-inst-env.in
> guix-daemon --build-users-group=guixbuild
> 
> sudo: /gnu/store/z26h622slm8p61myhk45v3jjg8p7qm8z-profile/bin/sudo
> must
> be owned by uid 0 and have the setuid bit set 
> 
> user@machine ~/Prog/repo/guix [env]$ ./pre-inst-env.in
> bash: ./pre-inst-env.in: No such file or directory 
> user@machine ~/Prog/repo/guix [env]$ cd build-aux/ 
> user@machine ~/Prog/repo/guix/build-aux [env]$ sudo
> -E ./pre-inst-env.in guix-daemon --build-users-group=guixbuild
> sudo: /gnu/store/z26h622slm8p61myhk45v3jjg8p7qm8z-profile/bin/sudo
> must
> be owned by uid 0 and have the setuid bit set 
> user@machine ~/Prog/repo/guix/build-aux [env]$ exit
> ---
> 
> And then:
> 
> --
> user@machine ~/Prog/repo/guix/build-aux$ chmod +x ./pre-inst-env.in 
> user@machine ~/Prog/repo/guix/build-aux$ sudo -E ./pre-inst-env.in
> guix-daemon --build-users-group=guixbuild Password: 
> ./pre-inst-env.in: line 33: cd: @abs_top_srcdir@:
> there is no such file or directory 
> ./pre-inst-env.in: line 34: cd:
> @abs_top_builddir@: there is no such file or directory
> 
> 
> And after that I couldn't run "guix
> environment" anymore, it threw an error:
> 
> guix environment: error: failed to connect to
> `/var/guix/daemon-socket/socket': Connection refused
> 
> Restarting the computer helps, but doing the same stuff breaks it
> again, so guess it's reproducible.
> 
> After doing it I ran the "history" command so you can know what I did
> exactly (some commands were unfortunately run in an environment and I
> can't provide them), here it is:
> 
>   371  git clone --recurse-submodules
>   git://git.savannah.gnu.org/guix.git 
>   372  guix environment guix --pure
>   373  sudo -E
>   374  sudo --help
>   375  guix environment guix --pure
>   376  guix environment guix --pure --ad-hoc sudo 
>   377  ls
>   378  cd guix/
>   379  ls
>   380  cd build-aux/
>   381  ls
>   382  .
>   383  guix environment guix --pure
>   384  chmod +x ./pre-inst-env.in 
>   385  sudo -E ./pre-inst-env.in guix-daemon
>   --build-users-group=guixbuild 
>   386  ls
>   387  cd ..
>   388  ./configure 
>   389  guix environment guix --pure
>   390  history
> 
> As stupid and complicated as it is, something is definitely broken
> here.
> 
> Sincerely,
> Jan Wielkiewicz
> 
> 
> 

pre-inst-env.in is for generating the pre-inst-env script. Have you
tried:
./bootstrap
./configure

This should generate pre-inst-env for you.

Also, make sure the guix daemon is running after you restart.

bug#37374: "Guix is too old and cannot be upgraded" (guix package -u)

[Jesse Gibbons]

On Tue, 2019-09-10 at 17:37 -0600, melon wrote:
> I was attempting to upgrade my Guix (binary, on Linux Mint)
> installation
> today using the 'guix package pull && guix package -u' commands, and
> Guix outputted the following error:
> 
> ERROR: In procedure raise:
> Wrong type (expecting exact integer): # "Guix is too old and cannot be upgraded"] 7528ac0>
> guix pull: error: You found a bug: the program
> '/gnu/store/y1kqj5ikxx9niyz2zx1gbikspi2xfmi4-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "7e143375d3649f3c0bd4c13958b26c086f364647"; system: "x86_64-linux";
> host version: "aa4818c33b6b2fd8d602ee93a2f53005d9472f41"; pull-
> version: 0).
> Please report it by email to .
> 
> I searched the Web and mailing list archives for this error but could
> not find anything. Maybe I used the wrong keywords.
> 
> Is there any way I can perform a "manual upgrade" to a newer Guix
> version?
> 

Wow, now I want to keep guix up-to-date all the time. How long has it
been since you pulled/upgraded guix?

The first thing I thought of is manually remove the guix binary run
install script. But that might get complicated.

I think you can look at the git repo on savannah and pull a few commits
after your current commit (run "guix describe" to get the commit, then
"guix pull --commit=COMMIT" where COMMIT is about a hundred commits
after your current commit), repeating until "guix pull" brings guix
fully up-to-date.

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

I have been trying to set up ardour, but jackd doesn't start in real-
time mode. I made an os definition that replicates this issue when I
use a VM[0].
[0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.html
I asked the gnome and gdm IRC and found out gdm loads the gdm-password
pam config, which seems untouched by pam-limits-service. My
/etc/pam.d/gdm-password (which should be the default) is attached.

Thanks!
-- 
-Jesseaccount required pam_unix.so 
auth required pam_unix.so nullok
password required pam_unix.so sha512 shadow
session required 
/gnu/store/90b3ypy5w6si4vd4b17i2nyzy0pfr5j2-elogind-241.3/lib/security/pam_elogind.so
 
session required pam_loginuid.so 
session required pam_env.so 
session required pam_unix.so 

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

On Wed, 2019-09-11 at 09:12 -0600, Jesse Gibbons wrote:
> I have been trying to set up ardour, but jackd doesn't start in real-
> time mode. I made an os definition that replicates this issue when I
> use a VM[0].
> [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.htm
> l
> I asked the gnome and gdm IRC and found out gdm loads the gdm-
> password
> pam config, which seems untouched by pam-limits-service. My
> /etc/pam.d/gdm-password (which should be the default) is attached.
> 
> Thanks!
I'm not sure how to resolve this issue. I tried appending "gdm-
password" to the list of pam configs modified by pam-limits-service[1]
but it doesn't fix anything when I use ./pre-inst-env to build the
vm. gdm-password still does not have a line to load pam_limits.

Whatever the solution, we will probably also want to implement it with
other graphical login services like slim and sddm (and eventually
lightdm and kdm).

[1] http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.sc
m#n1480
-- 
-Jesse

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

Thanks Ricardo,
On Wed, 2019-09-11 at 21:48 +0200, Ricardo Wurmus wrote:
> Hi Jesse,
> 
> > I have been trying to set up ardour, but jackd doesn't start in
> > real-
> > time mode. I made an os definition that replicates this issue when
> > I
> > use a VM[0].
> > [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.h
> > tml
> > I asked the gnome and gdm IRC and found out gdm loads the gdm-
> > password
> > pam config, which seems untouched by pam-limits-service. My
> > /etc/pam.d/gdm-password (which should be the default) is attached.
> 
> I can reproduce this.
> 
> (I’m sorry for accidentally misleading you earlier.  Turns out I used
> JACK a little longer ago than I initially realized.)
So was there a time when JACK worked realtime after logging in from gdm
on a GuixSD install?
> 
> I think it should be pretty easy to fix this:
> 
> 1) we should generate a single file that is used for generic session
> settings.
What should be this file's default contents? Should it be empty unless
the pam-limits-service is specified?
> 
> 2) all login programs (including gdm) should include that file in
> their
> PAM settings.
I suppose this could be done by adding
(pam-entry
 (control "include")
 (module "standard-session"))

I'm not sure "module" is a good word to describe the file.
> 
> 3) the pam-limits-service should extend that single file instead of
> attempting to update a bunch of PAM files for a selected list of
> programs.
Should this file be a part of base-services?
> --
> Ricardo
> 
I have to go to work soon, but I hope I can have this accomplished with
a patch series ready by Saturday. I'll check in with a status update
Saturday evening UTC -6.
-- 
-Jesse

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

On Wed, 2019-09-11 at 21:48 +0200, Ricardo Wurmus wrote:
> Hi Jesse,
> 
> > I have been trying to set up ardour, but jackd doesn't start in
> > real-
> > time mode. I made an os definition that replicates this issue when
> > I
> > use a VM[0].
> > [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.h
> > tml
> > I asked the gnome and gdm IRC and found out gdm loads the gdm-
> > password
> > pam config, which seems untouched by pam-limits-service. My
> > /etc/pam.d/gdm-password (which should be the default) is attached.
> 
> I can reproduce this.
> 
> (I’m sorry for accidentally misleading you earlier.  Turns out I used
> JACK a little longer ago than I initially realized.)
> 
> I think it should be pretty easy to fix this:
> 
> 1) we should generate a single file that is used for generic session
> settings.
> 
> 2) all login programs (including gdm) should include that file in
> their
> PAM settings.
> 
> 3) the pam-limits-service should extend that single file instead of
> attempting to update a bunch of PAM files for a selected list of
> programs.
> 
> --
> Ricardo
> 
Is all this best practice?

This solution would have patches for three files:
- gnu/system/pam.scm (adding the generic session settings file and
patching the "su" and "login" configurations)
- gnu/services/base.scm (patching pam-limits-service)
- gnu/services/desktop.scm (patching the graphical login
configurations).

All new login services would require a patch to just one file with
these steps implemented(to add the service), whereas they would each
need a patch to two files if they are not implemented (one to add the
service, another to have pam-limits-service modify the service's pam
config.

If you think this solution is better design than what we currently
have, and others in this mailing list agree, I will work to provide
these patches.

I previously said adding gdm-password to the list of pam configs
amended by pam-limits-service did not work. I then discovered the
changes in the environment will not work unless I run "make". I don't
know if this is a bug in guix or guile, or if it is intentionally this
way; the manual should be updated to clarify that guix needs to be
built in the environment for the changes to work.

I sent a patch (bug#37405) that fixes this issue for gdm-password. A
simple change can probably fix it for gdm-autologin (not added because
I haven't tested it) and whatever gdm loads when the user logs in with
biometric fingerprints (I don't know the name). When we add ldm and
kdm, I think we can do something similar.

-- 
-Jesse

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

On Sat, 2019-09-14 at 17:13 -0600, Jesse Gibbons wrote:
> On Wed, 2019-09-11 at 21:48 +0200, Ricardo Wurmus wrote:
> > Hi Jesse,
> > 
> > > I have been trying to set up ardour, but jackd doesn't start in
> > > real-
> > > time mode. I made an os definition that replicates this issue when
> > > I
> > > use a VM[0].
> > > [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.h
> > > tml
> > > I asked the gnome and gdm IRC and found out gdm loads the gdm-
> > > password
> > > pam config, which seems untouched by pam-limits-service. My
> > > /etc/pam.d/gdm-password (which should be the default) is attached.
> > 
> > I can reproduce this.
> > 
> > (I’m sorry for accidentally misleading you earlier.  Turns out I used
> > JACK a little longer ago than I initially realized.)
> > 
> > I think it should be pretty easy to fix this:
> > 
> > 1) we should generate a single file that is used for generic session
> > settings.
> > 
> > 2) all login programs (including gdm) should include that file in
> > their
> > PAM settings.
> > 
> > 3) the pam-limits-service should extend that single file instead of
> > attempting to update a bunch of PAM files for a selected list of
> > programs.
> > 
> > --
> > Ricardo
> > 
> 
> Is all this best practice?
> 
> This solution would have patches for three files:
> - gnu/system/pam.scm (adding the generic session settings file and
> patching the "su" and "login" configurations)
> - gnu/services/base.scm (patching pam-limits-service)
> - gnu/services/desktop.scm (patching the graphical login
> configurations).
> 
> All new login services would require a patch to just one file with
> these steps implemented(to add the service), whereas they would each
> need a patch to two files if they are not implemented (one to add the
> service, another to have pam-limits-service modify the service's pam
> config.
> 
> If you think this solution is better design than what we currently
> have, and others in this mailing list agree, I will work to provide
> these patches.
> 
> I previously said adding gdm-password to the list of pam configs
> amended by pam-limits-service did not work. I then discovered the
> changes in the environment will not work unless I run "make". I don't
> know if this is a bug in guix or guile, or if it is intentionally this
> way; the manual should be updated to clarify that guix needs to be
> built in the environment for the changes to work.
> 
> I sent a patch (bug#37405) that fixes this issue for gdm-password. A
> simple change can probably fix it for gdm-autologin (not added because
> I haven't tested it) and whatever gdm loads when the user logs in with
> biometric fingerprints (I don't know the name). When we add ldm and
> kdm, I think we can do something similar.
> 
ping

bug#37482: Guix fails to build libreoffice

[Jesse Gibbons]

On Sun, 2019-09-22 at 19:45 +0200, Tobias Geerinckx-Rice via Bug reports for
GNU Guix wrote:
> Jan,
> 
> Thanks for the report, and sorry you had to learn this the hard 
> way.
> 
> Jan Wielkiewicz 写道：
> > I've recently tried to reconfigure my system, but after about 3 
> > hours
> > of building libreoffice, the system froze for 2 hours and then 
> > guix
> > threw:
> 
> […]
> 
> > g++: internal compiler error: Killed (program cc1plus)
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> 
> This message and the freezing above is a tell-tale sign of OOM 
> (out-of-memory).  If you check your dmesg or /var/log/messages at 
> that time, I'm almost certain you'll see the OOM killer plot its 
> dastardly deeds.
> 
> > My system is an old ThinkPad with 2GB of RAM and Intel Centrino 
> > Duo
> > processor, but I'm unsure if this was the cause of the build 
> > failing.
> 
> You may be sure.
> 
> 2 GiB of RAM is simply not enough to build many packages these 
> days.  That's the world we live in.  There's nothing Guix can do 
> to change that.
> 
> You can restrict the number of parallel builds and jobs by 
> respectively passing --max-jobs=1 and --cores=1 to the daemon. 
> You can make this permanent by setting (extra-options …) in your 
> system configuration.
> 
> Even then, some complex executables will simply fail to link with 
> so little RAM.

You can get around too little RAM by using swap, correct? Partition ~8GB as
swap and add (swap-devices) in the configuration.

bug#37380: gdm doesn't load pam-limits

[Jesse Gibbons]

On Sat, 2019-09-14 at 17:13 -0600, Jesse Gibbons wrote:
> On Wed, 2019-09-11 at 21:48 +0200, Ricardo Wurmus wrote:
> > Hi Jesse,
> > 
> > > I have been trying to set up ardour, but jackd doesn't start in
> > > real-
> > > time mode. I made an os definition that replicates this issue when
> > > I
> > > use a VM[0].
> > > [0] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00065.h
> > > tml
> > > I asked the gnome and gdm IRC and found out gdm loads the gdm-
> > > password
> > > pam config, which seems untouched by pam-limits-service. My
> > > /etc/pam.d/gdm-password (which should be the default) is attached.
> > 
> > I can reproduce this.
> > 
> > (I’m sorry for accidentally misleading you earlier.  Turns out I used
> > JACK a little longer ago than I initially realized.)
> > 
> > I think it should be pretty easy to fix this:
> > 
> > 1) we should generate a single file that is used for generic session
> > settings.
> > 
> > 2) all login programs (including gdm) should include that file in
> > their
> > PAM settings.
> > 
> > 3) the pam-limits-service should extend that single file instead of
> > attempting to update a bunch of PAM files for a selected list of
> > programs.
> > 
> > --
> > Ricardo
> > 
> 
> Is all this best practice?
> 
> This solution would have patches for three files:
> - gnu/system/pam.scm (adding the generic session settings file and
> patching the "su" and "login" configurations)
> - gnu/services/base.scm (patching pam-limits-service)
> - gnu/services/desktop.scm (patching the graphical login
> configurations).
> 
> All new login services would require a patch to just one file with
> these steps implemented(to add the service), whereas they would each
> need a patch to two files if they are not implemented (one to add the
> service, another to have pam-limits-service modify the service's pam
> config.
> 
> If you think this solution is better design than what we currently
> have, and others in this mailing list agree, I will work to provide
> these patches.
> 
> I previously said adding gdm-password to the list of pam configs
> amended by pam-limits-service did not work. I then discovered the
> changes in the environment will not work unless I run "make". I don't
> know if this is a bug in guix or guile, or if it is intentionally this
> way; the manual should be updated to clarify that guix needs to be
> built in the environment for the changes to work.
> 
> I sent a patch (bug#37405) that fixes this issue for gdm-password. A
> simple change can probably fix it for gdm-autologin (not added because
> I haven't tested it) and whatever gdm loads when the user logs in with
> biometric fingerprints (I don't know the name). When we add ldm and
> kdm, I think we can do something similar.
> 
ping

bug#37583: Documentation needed: pam-services in operating-system structure

[Jesse Gibbons]

The manual has no documentation about how to use pam-services in the
operating-system configuration. Information about how to use the pam-service 
data structure and an example of how to use it would be helpful to
administrators who need to use non-default settings, and will help us squash
the bugs we find in the future related to how guix implements pam.

bug#37669: guile: warning: failed to install locale

[Jesse Gibbons]

On a GuixSD install, the following message began appearing today (I did not
record what time):
guile: warning: failed to install locale
It appears whenever I run `guix` regardless of the command-line arguments I
pass to it.
GUIX_LOCPATH looks like this:
~$ echo $GUIX_LOCPATH 
/run/current-system/locale
I have not today run "guix system reconfigure"
- Could this be related to the core-updates merge?
- Is there a work-around?
-- 
-Jesse

bug#37692: quaternion cannot get pages

[Jesse Gibbons]

1. launch quaternion
2. click on any subscribed page
The page display area remains blank. 
In the log it displays something like this

libqmatrixclient.jobs: GetContentThumbnailJob|
https://matrix.org/_matrix/media/r0/thumbnail/matrix.org/UBaeyhkNdbVVPeiEazXOtawx?width=16&height=16&allow_remote=true
libqmatrixclient.jobs:404  (tentative)
libqmatrixclient.jobs: "GetContentThumbnailJob" status 104: Unknown error
libqmatrixclient.jobs: GetContentThumbnailJob|
https://matrix.org/_matrix/media/r0/thumbnail/matrix.org/UBaeyhkNdbVVPeiEazXOtawx?width=16&height=16&allow_remote=true
libqmatrixclient.jobs:404  (final)
libqmatrixclient.jobs: "GetContentThumbnailJob" status 104: Error
transferring 
https://matrix.org/_matrix/media/r0/thumbnail/matrix.org/UBaeyhkNdbVVPeiEazXOtawx?width=16&height=16&allow_remote=true
- server replied: 
libqmatrixclient.jobs: "GetContentThumbnailJob" status 104: Not found
[b'matrix.org', b'UBaeyhkNdbVVPeiEazXOtawx']


I'm not sure how Matrix works. It could be something wrong with the API key,
with the server, or with the client. Matrix was working fine before I pulled
the core-updates merge.

bug#37669: guile: warning: failed to install locale

[Jesse Gibbons]

On Thu, 2019-10-10 at 16:41 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Gábor Boskovits  skribis:
> 
> > This is most probably a transient core-updates effect. Reconfigure
> > should
> > fix this, and this should be harmless.
> 
> Agreed.
> 
> Normally ‘guix pull --news’ should give you hints on how to address
> this, but otherwise see:
> 
>   https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Locales
> 
> for a “foreign distro”, or:
> 
>   
> https://guix.gnu.org/manual/en/html_node/Locales.html#Locale-Data-Compatibility-Considerations
> 
> on Guix System.
> 
> Let us know if it works for you!
> 
> Ludo’.
Reconfiguring fixed this. Thanks!

bug#37705: python-scikit-learn fails tests

[Jesse Gibbons]

I need python-scikit-learn for an ai project.

"guix build python-scikit-learn"
...
build of /gnu/store/wymxdfygbzij8hbz4gqkrwnb3jkicx76-python-scikit-learn-
0.20.3.drv failed
View build log at '/var/log/guix/drvs/wy/mxdfygbzij8hbz4gqkrwnb3jkicx76-
python-scikit-learn-0.20.3.drv.bz2'.


log tarball attached.

I'm working on fixing it, but help would be appreciated.


mxdfygbzij8hbz4gqkrwnb3jkicx76-python-scikit-learn-0.20.3.drv.bz2
Description: application/bzip

bug#37705: python-scikit-learn fails tests

[Jesse Gibbons]

On Fri, 2019-10-11 at 10:42 -0600, Jesse Gibbons wrote:
> I need python-scikit-learn for an ai project.
> 
> "guix build python-scikit-learn"
> ...
> build of /gnu/store/wymxdfygbzij8hbz4gqkrwnb3jkicx76-python-scikit-learn-
> 0.20.3.drv failed
> View build log at '/var/log/guix/drvs/wy/mxdfygbzij8hbz4gqkrwnb3jkicx76-
> python-scikit-learn-0.20.3.drv.bz2'.
> 
> 
> log tarball attached.
> 
> I'm working on fixing it, but help would be appreciated.
update:
python-scikit-learn is outdated. It can be updated to 0.20.4 
I am testing the build right now. I will send a patch if it builds.

I think we can also discuss what to do about python-scikit-learn dropping
python2 support beginning with 0.21; there is a thread on guix-devel titled
"the upcoming Great Python2 Purge™" we can revive. I would hate for guix
packages to fall too far behind.
-- 
-Jesse

bug#37705: bug#37433: bug#37705: python-scikit-learn fails tests

[Jesse Gibbons]

On Fri, 2019-10-11 at 21:27 +0200, Ricardo Wurmus wrote:
> Jesse Gibbons  writes:
> 
> > I need python-scikit-learn for an ai project.
> > 
> > "guix build python-scikit-learn"
> > ...
> > build of /gnu/store/wymxdfygbzij8hbz4gqkrwnb3jkicx76-python-scikit-
> > learn-
> > 0.20.3.drv failed
> > View build log at '/var/log/guix/drvs/wy/mxdfygbzij8hbz4gqkrwnb3jkicx76-
> > python-scikit-learn-0.20.3.drv.bz2'.
> > 
> > 
> > log tarball attached.
> > 
> > I'm working on fixing it, but help would be appreciated.
> 
> This is a duplicate of bug 37433.
> 
Ok.
I sent patch #37707 to fix it.

bug#37433: 37433 fixed

[Jesse Gibbons]

On Fri, 2019-10-11 at 13:48 -0600, Jesse Gibbons wrote:
> On Fri, 2019-10-11 at 21:27 +0200, Ricardo Wurmus wrote:
> > Jesse Gibbons  writes:
> > 
> > > I need python-scikit-learn for an ai project.
> > > 
> > > "guix build python-scikit-learn"
> > > ...
> > > build of /gnu/store/wymxdfygbzij8hbz4gqkrwnb3jkicx76-python-scikit-
> > > learn-
> > > 0.20.3.drv failed
> > > View build log at
> > > '/var/log/guix/drvs/wy/mxdfygbzij8hbz4gqkrwnb3jkicx76-
> > > python-scikit-learn-0.20.3.drv.bz2'.
> > > 
> > > 
> > > log tarball attached.
> > > 
> > > I'm working on fixing it, but help would be appreciated.
> > 
> > This is a duplicate of bug 37433.
> I sent patch #37707 to fix it.
> 
> 
> 
Fixed in patch d7e29a2b26
-- 
-Jesse

bug#37721: build failure: parted 3.3

[Jesse Gibbons]

This one prevents me from upgrading gnome-tweaks. It appears there is a
failure in applying "parted-glibc-compat.patch".

bug#37721: build failure: parted 3.3

[Jesse Gibbons]

On Sat, 2019-10-12 at 16:07 -0600, Jesse Gibbons wrote:
> This one prevents me from upgrading gnome-tweaks. It appears there is a
> failure in applying "parted-glibc-compat.patch".
> 
> 
> 
> 
Looks like a simple fix. I'll send the patch when I can confirm it builds.
Is it better to send bug fix patches in response to a bug or to the
"guix-patches" mailing list?

bug#37721: build failure: parted 3.3

[Jesse Gibbons]

On Sat, 2019-10-12 at 16:07 -0600, Jesse Gibbons wrote:
> This one prevents me from upgrading gnome-tweaks. It appears there is a
> failure in applying "parted-glibc-compat.patch".
> 
> 
> 
> 
Removed patch. It still fails to build in the pre-install environment.
Attached is the build log tarball.


44ik9his3phra4gsnvlbak4maadgz7-parted-3.3.drv.bz2
Description: application/bzip

bug#37721: build failure: parted 3.3

[Jesse Gibbons]

On Sun, 2019-10-13 at 14:15 +0200, Tobias Geerinckx-Rice via Bug reports for
GNU Guix wrote:
> Jesse,
> 
> Jesse Gibbons 写道：
> > This one prevents me from upgrading gnome-tweaks. It appears 
> > there is a
> > failure in applying "parted-glibc-compat.patch".
> 
> Yes, yes indeed…
> 
>   $ git show stash | grep '(patches'
>   - (patches (search-patches "parted-glibc-compat.patch"))
> 
> Sorry, and thanks for reporting & fixing this…
> 
>   $ git stash drop
> 
> > Looks like a simple fix. I'll send the patch when I can confirm 
> > it builds.
> > Is it better to send bug fix patches in response to a bug or to 
> > the
> > "guix-patches" mailing list?
> 
> The former.  They both share the same name^Wnumberspace anyway.
> 
> Kind regards,
> 
> T G-R, who won't use magit ‘because it's too magical’…
Looks like it builds now. Thanks.

bug#37692: quaternion not displaying anything

[Jesse Gibbons]

I removed everything related to quaternion from my $HOME directory tree and
logged back in. It still doesn't display any messages. Here's what it
outputs when I click on a different channel:


Opening room "#quotient:matrix.org"
Connected to room "!yBCfIaIJPwYXMoldTd:matrix.org" as "@jgibbons:matrix.org"
Filtering 100 user(s) in "Quotient (former QMatrixClient)" took 451 µs
100 user(s) in the room
Filtering 100 user(s) in "Quotient (former QMatrixClient)" took 369 µs
1 ms to  select room #quotient:matrix.org
libpng warning: iCCP: known incorrect sRGB profile

or

Opening room "#community-librem-5:talk.puri.sm"
Disconnected from "!aXWDJNTtEfhSXdPoQT:talk.puri.sm"
Connected to room "!BSqRHgvCtIsGittkBG:talk.puri.sm" as
"@jgibbons:matrix.org"
Filtering 24 user(s) in "community/librem-5" took 96 µs
24 user(s) in the room
Filtering 24 user(s) in "community/librem-5" took 53 µs
1 ms to  select room #community-librem-5:talk.puri.sm


Nothing wrong with the api. Probably something wrong with the app.

Someone on the Quotient matrix channel suggested it might be QT5 isn't setup
correctly. Any merit to that possibility?

bug#37775: Python 2.7 not configured for Tk

[Jesse Gibbons]

On Wed, 2019-10-16 at 00:38 -0700, Brian Leung wrote:
> Hi Guix,
> 
> Python 2.7 doesn't seem like it handles Tk properly right now, at least on
> my machine:
> 
> >>> import Tkinter
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/gnu/store/h2crv1mpc5qi05xdnn84fjp9g4gyicsl-python2-
> 2.7.16/lib/python2.7/lib-tk/Tkinter.py", line 39, in 
> import _tkinter # If this fails your Python may not be configured for
> Tk
> ImportError: No module named _tkinter
Python has a tk output to keep the python package small.
- If you're using tk for a personal script, you will probably need run 'guix
install python2:tk'
- If you need tk for a package input, you will need to use
'("python2-tk" ,python "tk")' or copy the input from one of the python
packages that uses tk.

bug#37917: Kernel Panic

[Jesse Gibbons]

On Fri, 2019-10-25 at 10:23 +0200, pelzflorian (Florian Pelz) wrote:
> On Fri, Oct 25, 2019 at 03:19:10AM -0400, Raghav Gururajan wrote:
> > Hello Guix!
> > 
> > Whenever I shutdown my system, 50% of the time, I end up with kernel
> > panic. Then I had to do cold restart.
> > 
> 
> I just wanted to say I have a kernel panic too sometimes (I do not
> know if the backtrace is the same and cannot easily reproduce the
> issue or provide a photo) on a 2010 Macbook though much less than 50%
> of the time.
> 
> 
> > Kernel Panic:
> > https://upload.disroot.org/r/B5Z3ofx_#/XTJVfcPxwYaDqzEGiQdv0Y6wQal34Oik77HlA7K7BE=
> > System Config:
> > https://bin.disroot.org/?a1ab3e3f7c3d38a5#SF5FHGGDC2+OYKbCrTCT+szeNvLFQbvN13OoimpDxng=
> 
> I do not see any kernel field, so you are using modern linux-libre.  I
> have to use
> 
> (kernel linux-libre-4.9)
> 
> I suppose it is a Shepherd bug then, maybe?
> 
> 
> 
> > Device: FSF's RYF-Certified TET-X200T (https://tehnoetic.com/tet-x200t)
> > a.k.a Lenovo ThinkPad X200 Tablet
> > 
> > Hardware Specs (Mods/Variants):
> > Intel® Core™2 Duo Processor SL9600 (2.13 GHz), Added Ericsson F3507g
> > Wireless WAN card,
> > Added Gemalto Compact Smart Card Reader Writer (ExpressCard),
> > Upgraded to Display with Wacom Pen+Finger Touch and Web Camera,
> > Upgraded to 8GB RAM,
> > and Upgraded to Atheros AR5BHB116 300Mbps Dual-Band WWAN.
> > 
> 
> My Macbook has none of these except the CPU is similar.
> 
> Intel(R) Core(TM)2 Duo CPU P8600  @ 2.40GHz
> 
> Maybe something is too slow?
> 
> Regards,
> Florian
> 
> 
> 
I also have a kernel panic often. The picture i took is too large for the
mailing list though :( The dump says something about trying to kill init.

I have successfully predicted one panic when some things stopped responding
and I was unable to open gnome-control-panel or gnome-system-monitor, but
that symptom might be coincidental.

My system: librem 15v3 w/o tpm, 32GB RAM
Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz

bug#37345: Icecat doesn't display numbers on Guix System

[Jesse Gibbons]

On Thu, 2019-10-31 at 10:00 +0100, Matias Jose Seco Baccanelli wrote:
> Hello!
> I confirm that installing font-dejavu also fixed the issue for me.
> Wondering if the problem arises on any system configuration setup or
> if it might be influenced by, for example, the locale; which mine is
> (locale "it_IT.utf8").
> 
> Blisfully,
> Matias
My locale is en_US and I have had general font problems for multiple
applications, including gimp, gourmet, and icecat, so I do not think it is
necessarily related to the locale. I think a lot of it is user-level
configuration. When I use gnome tweaks to change the fonts, I find that some
fonts work as expected, but some do not. In particular, I notice that if I
remove a font, it is not removed from the list of fonts I can select.
Perhaps there's a local database of available fonts that isn't modified when
a font is uninstalled with guix?

bug#38241: python-hy build failure

[Jesse Gibbons]

guix build python-hy fails with the message
error: [Errno 13] Permission denied: '/homeless-shelter'

It looks like the install step tries to access $HOME and fails. I am working
on a patch to fix this.

bug#38241: python-hy build failure

[Jesse Gibbons]

On Sat, 2019-11-16 at 17:26 -0700, Jesse Gibbons wrote:
> guix build python-hy fails with the message
> error: [Errno 13] Permission denied: '/homeless-shelter'
> 
> It looks like the install step tries to access $HOME and fails. I am
> working
> on a patch to fix this.
> 
> 
> 
> 
The patch is attached. I noticed it lets it build, but python-hy is still
broken. Python2-hy is not broken though.
From 15580fd77397d55ddc459c6ada58201ee61e8ec8 Mon Sep 17 00:00:00 2001
From: Jesse Gibbons 
Date: Sat, 16 Nov 2019 18:33:05 -0700
Subject: [PATCH] gnu: python-hy: Set HOME to /tmp before install

This fixes bug#38241

* gnu/packages/python-xyz.scm (python-hy)[arguments]: Add custom
'set-HOME phase before the 'install phase.
---
 gnu/packages/python-xyz.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index d2786e4826..5b8b33b87f 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -8745,6 +8745,9 @@ with a new public API, and RPython support.")
 (arguments
  '(#:phases
(modify-phases %standard-phases
+	 (add-before 'install 'set-HOME
+	   (lambda _
+	 (setenv "HOME" "/tmp")))
  (replace 'check
(lambda _
  ;; Tests require write access to HOME.
-- 
2.24.0

bug#38274: emacs doesn't open files

[Jesse Gibbons]

guix describe :
Generation 139  Nov 19 2019 08:11:32(current)
  guix 7b40d59
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7b40d59114e1462d6d8140f325a66b12e91db667

emacs --version :
GNU Emacs 26.3
Copyright (C) 2019 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

When I launch emacs from the command line, I get the following message:
split-string: Wrong type argument: stringp, nil

As a result, when I try `EDITOR=emacs guix edit hello` it doesn't work.
I can confirm this is not a problem with guix edit, because when EDITOR=vim
it opens the package in vim.

(Joke about guix turning to the dark side goes here.)

Since I do not know if it is a problem with guix or emacs, I'm starting with
guix. It could be related to bug#38261

bug#38274: emacs doesn't open files

[Jesse Gibbons]

On Tue, 2019-11-19 at 08:35 -0700, Jesse Gibbons wrote:
> guix describe :
> Generation 139Nov 19 2019 08:11:32(current)
>   guix 7b40d59
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 7b40d59114e1462d6d8140f325a66b12e91db667
> 
> emacs --version :
> GNU Emacs 26.3
> Copyright (C) 2019 Free Software Foundation, Inc.
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> You may redistribute copies of GNU Emacs
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING.
> 
> When I launch emacs from the command line, I get the following message:
> split-string: Wrong type argument: stringp, nil
> 
> As a result, when I try `EDITOR=emacs guix edit hello` it doesn't work.
> I can confirm this is not a problem with guix edit, because when
> EDITOR=vim
> it opens the package in vim.
> 
> (Joke about guix turning to the dark side goes here.)
> 
> Since I do not know if it is a problem with guix or emacs, I'm starting
> with
> guix. It could be related to bug#38261
> 
> 
> 
> 
I guess this was fixed for me by restarting my computer.

(joke about "turning it off and back on" working goes here)

bug#38273: emacs doesn't open files

[Jesse Gibbons]

I thought I closed this issue. Rebooting fixed it.