Error in install-efi + build with graft freezes

2021-10-05 Thread phodina
Hi Guix,

I've attempted to build image for beaglebone black based on the example found 
in gnu/system/examples/beaglebone-black.tmpl. To build the image I run the 
following command:

time guix system image --no-grafts --system=armhf-linux 
examples/beaglebone-black.tmpl -v3
The following derivations will be built:
   /gnu/store/1ivscl4dkmw65lgl3s7ml8qgx8dgj6zv-disk-image.drv
   /gnu/store/dydpw2nvm8yq330bs7gcqicl2fb6qd21-genimage.cfg.drv
   /gnu/store/i271lgxhafnb7kgp8kr1pc81bng0ys6q-partition.img.drv
   /gnu/store/riiw4lrrh73slwa4dihkfnpssshn5wf0-partition.img.drv
building /gnu/store/i271lgxhafnb7kgp8kr1pc81bng0ys6q-partition.img.drv...
Backtrace:
   3 (primitive-load "/gnu/store/ha96i5s8bvx7zcdnp3sqnr03gvf…")
In ice-9/eval.scm:
    619:8  2 (_ #(# # …))
In ./gnu/build/bootloader.scm:
 99:4  1 (install-efi-loader "/gnu/store/y5c7xy8gn5maimw3nvksvm…" …)
    78:35  0 (install-efi _ "grub.cfg" _)

./gnu/build/bootloader.scm:78:35: In procedure install-efi:
In procedure car: Wrong type argument in position 1 (expecting pair): 
#
environment variable `PATH' set to 
`/gnu/store/62c83bc4a6vnx94cmgn0h37j3mj8nif8-e2fsprogs-1.45.6/bin:/gnu/store/62c83bc4a6vnx94cmgn0h37j3mj8nif8-e2fsprogs-1.45.6/sbin:/gnu/store/fk1gaqga9rkq2g4pxnjlxxmy6xv0994m-fakeroot-1.25.3/bin:/gnu/store/6mz29a52531f6529455gscxsrcm9q0wb-dosfstools-4.2/sbin:/gnu/store/ryx6nf7cqsqvi2cwrv6mkj7nbb5gpc0f-mtools-4.0.35/bin'
builder for `/gnu/store/i271lgxhafnb7kgp8kr1pc81bng0ys6q-partition.img.drv' 
failed with exit code 1
build of /gnu/store/i271lgxhafnb7kgp8kr1pc81bng0ys6q-partition.img.drv failed
View build log at 
'/var/log/guix/drvs/i2/71lgxhafnb7kgp8kr1pc81bng0ys6q-partition.img.drv.bz2'.
cannot build derivation 
`/gnu/store/dydpw2nvm8yq330bs7gcqicl2fb6qd21-genimage.cfg.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/1ivscl4dkmw65lgl3s7ml8qgx8dgj6zv-disk-image.drv': 1 dependencies 
couldn't be built
guix system: error: build of 
`/gnu/store/1ivscl4dkmw65lgl3s7ml8qgx8dgj6zv-disk-image.drv' failed

real 0m3.055s
user 0m2.297s
sys 0m0.113s

Based on the backtrace the issue is in install-efi-loader calling install-efi 
with incorrect parameter. I checked also the gnu/build/bootloader.scm where 
these function are defined.

Unfortunately, I'm not that skilled in Guile to debug the code, set breakpoint 
and view/modify the arguments.

Could you recommend me some guide how to debug the Guile code in order to learn 
how to fix this issue?

Also one more question related to the Guix. I had to use the argument 
--no-graft. When I measure the time it takes to build the system with grafts 
the process freezes for like a half day so I kill it. Without the grafts I at 
least get to the partition error above.

Could someone please explain the reason or point me in the right direction why 
grafts freeze or is it normal it takes that long?
(for cross-compilation, when building native system for my laptop I don't see 
this issue)

Petr



Re: Help-Guix Digest, Vol 71, Issue 7

2021-10-05 Thread jgart
On Tue, 05 Oct 2021 12:00:46 -0400 help-guix-requ...@gnu.org wrote:
> Send Help-Guix mailing list submissions to
>   help-guix@gnu.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.gnu.org/mailman/listinfo/help-guix
> or, via email, send a message with subject or body 'help' to
>   help-guix-requ...@gnu.org
> 
> You can reach the person managing the list at
>   help-guix-ow...@gnu.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Help-Guix digest..."
> 
> 
> Today's Topics:
> 
>1. Re: Am I allowed to make package requests? (Luis Felipe)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 05 Oct 2021 13:09:39 +
> From: Luis Felipe 
> To: Tim Lee 
> Cc: help-guix@gnu.org
> Subject: Re: Am I allowed to make package requests?
> Message-ID:
>   
> 
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Hi, Tim.
> 
> On Tuesday, October 5th, 2021 at 4:31 AM, Tim Lee  
> wrote:
> 
> > What is GNU Guix's policy on package requests?
> > 
> 
> > I am able to package simple software (e.g. software with minimal
> > 
> 
> > dependencies that use the gnu-build-system), but some complicated
> > 
> 
> > software are too difficult for me. I know that something is too
> > 
> 
> > complicated when I look at how the package is built in Debian and NixOS.
> > 
> 
> > If the package requires lots of special build steps and lots of patches,
> > 
> 
> > I know that it is too difficult.
> > 
> 
> > Am I allowed to make package requests? If so, where should I post my
> > 
> 
> > request?
> 
> There is a packages wish list on LibrePlanet wiki:
> 
> https://libreplanet.org/wiki?title=Group:Guix/Wishlist

I got inspired and packaged catgirl just now (I saw it on the libreplanet 
Wishlist):

https://issues.guix.gnu.org/51042

> ------ next part --
> A non-text attachment was scrubbed...
> Name: publickey - luis.felipe...@protonmail.com - 0x12DE1598.asc
> Type: application/pgp-keys
> Size: 1815 bytes
> Desc: not available
> URL: 
> <https://lists.gnu.org/archive/html/help-guix/attachments/20211005/c8b18f0b/attachment.key>
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 509 bytes
> Desc: OpenPGP digital signature
> URL: 
> <https://lists.gnu.org/archive/html/help-guix/attachments/20211005/c8b18f0b/attachment.sig>
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> Help-Guix mailing list
> Help-Guix@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-guix
> 
> 
> --
> 
> End of Help-Guix Digest, Vol 71, Issue 7
> 

3B1D 7F19 E36B B60C 0F5B 2CA9 A52A A2B4 77B6 DD35



Python gi module not found

2021-10-05 Thread phodina via
Hi Guix,

I've put together package definition for postmarketos-tweaks. This issue comes 
up when I attempt to run the pmos-tweaks. I get this message reagrding missing 
Python module gi:

$ guix environment --pure bash
[env]$ 
/gnu/store/zsybq9wphfckhph4f6fizzs31kjsd04x-postmarketos-tweaks-0.7.3/bin/pmos-tweaks
Traceback (most recent call last):
File 
"/gnu/store/zsybq9wphfckhph4f6fizzs31kjsd04x-postmarketos-tweaks-0.7.3/bin/pmos-tweaks",
 line 17, in 
import gi
ModuleNotFoundError: No module named 'gi'

If I check for the module I do see it in the PYTHON_PATH:

$ environment --pure bash --ad-hoc python-pygobject python-pyyaml python

$ printenv
...
PYTHONPATH=/gnu/store/qhg0djz37c2c884v64m6287d62xsqbz2-profile/lib/python3.8/site-packages
...
$ ls 
/gnu/store/qhg0djz37c2c884v64m6287d62xsqbz2-profile/lib/python3.8/site-packages/
PyGObject-3.34.0.egg-info pip
PyYAML-5.4.1-py3.8.egg-info pip-19.2.3.dist-info
README.txt pkg_resources
__pycache__ pygtkcompat
_yaml setuptools
easy_install.py setuptools-41.2.0.dist-info
gi yaml

Any tips what to change so that the modules are imported correctly?

Petr

--8<---cut here---start->8---

Subject: [PATCH] gnu: Add postmarketos-tweaks.

* gnu/packages/gnome.scm (postmarketos-tweaks): New variable.

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 4a311a379c..afd185480c 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -11345,6 +11345,47 @@ integrate seamlessly with the GNOME desktop.")
(home-page "https://wiki.gnome.org/Apps/Polari;)
(license license:gpl2+)))

+(define-public postmarketos-tweaks
+ (package
+ (name "postmarketos-tweaks")
+ (version "0.7.3")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://gitlab.com/postmarketOS/postmarketos-tweaks;)
+ (commit version)))
+ (file-name (string-append name "-" version ".tar.gz"))
+ (sha256
+ (base32
+ "05110x0y1pvzdgzmz66fhq9bnlyym1nd7zgn61knihzp4dx3acf5"
+ (build-system meson-build-system)
+ (arguments
+ `(#:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'fix-install-dir
+ (lambda* _
+ (substitute* "data/meson.build"
+ (("/etc/init.d") (string-append %output "/etc/init.d"
+ (native-inputs `(("pkg-config" ,pkg-config)
+ ("gtk+:bin"
+ ,gtk+ "bin") ; for gtk-update-icon-cache
+ ("glib:bin"
+ ,glib "bin") ; glib-compile-schemas, etc.
+ ("desktop-file-utils"
+ ,desktop-file-utils) ; for update-desktop-database
+ ("cmake" ,cmake)))
+ (inputs `(("libhandy" ,libhandy)
+ ("gtk+" ,gtk+)
+ ("python" ,python)
+ ("python-pygobject" ,python-pygobject)
+ ("python-pyyaml" ,python-pyyaml)))
+ (home-page "https://gitlab.com/postmarketOS/postmarketos-tweaks;)
+ (synopsis "Extra settings on mobile platforms")
+ (description "Postmarket tweaks is an application for tweaking settings
+on desktop environments supported by postmarketOS.")
+ (license license:lgpl3)))
+
(define-public gnome-boxes
(package
(name "gnome-boxes")
--
2.32.0

Re: Certificates in pure and containerized environments

2021-10-05 Thread Maxim Cournoyer
Hi,

Wiktor Żelazny  writes:

> On Thu, Sep 30, 2021 at 12:08:53PM +0200, Konrad Hinsen wrote:
>
>>guix environment --pure \
>>--ad-hoc python nss-certs -- \
>>python3 -c 'import urllib.request; 
>> print(urllib.request.urlopen("http://wwwbis.sidc.be/DATA/uset/Wlight/2003/11/UPH20031109112104.FTS;))'
>>
>> but this doesn't work - same error as initially.
>
> Hi Konrad,
>
> For some reason, it works for me with
>
>--ad-hoc python nss-certs guix -- \
>
> . I’m neither sure if this is going to work on all machines (it works
> when isolated with
>
>guix environment -C -N
>
> , so there’s some hope), nor whether this solution is acceptable to you.
> Perhaps, it’s abusing Guix. Maybe somebody more knowledgeable will
> comment on this.

The key thing here is whether the certs are required by OpenSSL vs
GnuTLS.  The former honors SSL_CERT_DIR, while the later does not (I
opened an issue because I think it'd be nice to have them both honor it
the same here: [0]).  GnuTLS on Guix gets its certifications from the
hard coded location /etc/ssl/certs/.  This need to be bound in the
container; on a Guix System, it's also not enough to simply pass
/etc/ssl/certs/ as is, as these are symlinks to the store; you must also
expose the store or bind the etc/ssl/certs/ directory of the nss-certs
package directly.

I hope that helps!

Maxim

[0]  https://issues.guix.gnu.org/46779



Re: Crates versions and their replacement

2021-10-05 Thread Hartmut Goebel

Am 03.10.21 um 09:02 schrieb phodina:

   Now comes the question. How often should it be use and what are the
   pros and cons?


I suggest to use this only if required, since versions are defined to 
strict.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |




Re: Am I allowed to make package requests?

2021-10-05 Thread Luis Felipe
Hi, Tim.

On Tuesday, October 5th, 2021 at 4:31 AM, Tim Lee  
wrote:

> What is GNU Guix's policy on package requests?
> 

> I am able to package simple software (e.g. software with minimal
> 

> dependencies that use the gnu-build-system), but some complicated
> 

> software are too difficult for me. I know that something is too
> 

> complicated when I look at how the package is built in Debian and NixOS.
> 

> If the package requires lots of special build steps and lots of patches,
> 

> I know that it is too difficult.
> 

> Am I allowed to make package requests? If so, where should I post my
> 

> request?

There is a packages wish list on LibrePlanet wiki:

https://libreplanet.org/wiki?title=Group:Guix/Wishlist

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


What should ~/.profile look like after running "guix pull"?

2021-10-05 Thread Tim Lee
I installed GNU Guix 1.3.0 binary using the tarball downloaded from
https://guix.gnu.org/download/
After the installation process, I added these lines to my ~/.profile:

GUIX_PROFILE="$HOME/.guix-profile"
[ -d "$GUIX_PROFILE" ] && \
. "$GUIX_PROFILE/etc/profile"

I recently ran "guix pull" to upgrade my packages. At the end of
"guix pull", there is an informative message that asks me to run
something like:

GUIX_PROFILE="/home/myusername/.config/guix/current"
. "$GUIX_PROFILE/etc/profile"

However, the documentation about "guix pull" in the Guix manual
(https://guix.gnu.org/manual/en/html_node/Invoking-guix-pull.html) says
that I should add this to ~/.profile:

export PATH="$HOME/.config/guix/current/bin:$PATH"
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"

I have some questions:

1. What exactly should I place in ~/.profile to accommodate Guix?
2. Is the answer to question (1) the same before and after running
   "guix pull"?
   (By "before", I mean a version of Guix binary downloaded from
   https://guix.gnu.org/download/. By "after", I mean the latest
   version of Guix obtained by running "guix pull").



Am I allowed to make package requests?

2021-10-05 Thread Tim Lee
What is GNU Guix's policy on package requests?

I am able to package simple software (e.g. software with minimal
dependencies that use the gnu-build-system), but some complicated
software are too difficult for me. I know that something is too
complicated when I look at how the package is built in Debian and NixOS.
If the package requires lots of special build steps and lots of patches,
I know that it is too difficult.

Am I allowed to make package requests? If so, where should I post my
request?



Re: Meaning of "~@" in the format procedure

2021-10-05 Thread André A . Gomes
Hi Tobias,

Thank you for the examples and clear explanations.


--
André A. Gomes
"Free Thought, Free World"



Re: repair broken boot record

2021-10-05 Thread pelzflorian (Florian Pelz)
On Tue, Oct 05, 2021 at 11:28:50AM +0200, Thomas Danckaert wrote:
> Hello Florian,
> 
> thank you for your help.  I managed to chroot into my system, and re-run
> 'guix system reconfigure' (very useful mailing list discussion on chrooting,
> I also vote for including it in documentation :) ).

I’m glad it helped so far, although I don’t know all the details about
chroot nor EFI.  (For example which directories from the live system
should be mounted in the chroot and why.)  So I won’t attempt to write
documentation.


> In one of the final
> steps, where guix tries to install the bootloader, I get the error:
> 
> /gnu/store/.../grub/i386-pc/modinfo.sh doesn't exist. Please specify
> --target or --directory.

This is strange.  When you reconfigure, Guix should print the
grub-install command that was used, which should include both --target
and --directory.

However, perhaps the chroot is at fault: Before chrooting to, let’s
say, /mnt with chroot /mnt, you need to have mounted the /dev/sdXy
file system with EFI on it (that which is declared in your config.scm)
to /mnt/boot/efi.

What I write below you will probably not need; you can ignore it if
the above works:

> Indeed my system uses grub-efi.  Could that be related?  Can you point me to
> some specific instructions on how to check/solve efivar issues?

If you have made available efivar (by installing it or by `guix
environment --ad-hoc efivar` or similar), and if you have booted from
an EFI bootloader, then you can run `efivar -l` to see all variables
stored on your motherboard/mainboard.  The motherboard NVRAM can
become full.  However I’m not sure how to delete such variables; I
think the program efibootmgr can do it.  Hopefully and likely it will
not be necessary.


> Not sure if I need grub-efi, or if it might also work using grub-pc.  Until
> now I've always used grub-efi.

Some systems need EFI (and others don’t work with EFI).  It is
probably better to stick with EFI.


> (Another thing I noticed (maybe a side effect of chroot?): when I re-run
> 'guix system reconfigure' it tries to rebuild derivations that are already
> there in the store from last time, I think.)

Maybe they just have the same package name but are different versions,
so a rebuild is necessary.  But maybe also the running guix-daemon is
the one from the live USB and not from the installed system.

guix-daemon stores information about what is installed in a sqlite
database.  Now I wonder if the chroot can make changes to the wrong
database and interfere with the already installed guix-daemon, making
the store inconsistent.  Anyway, this should not cause trouble with
reconfiguring and if some inconsistency in the installed system causes
trouble later on, guix gc --verify can fix it.  It is not important now.

Hope it helps.

Regards,
Florian



Re: repair broken boot record

2021-10-05 Thread Thomas Danckaert

Hello Florian,

thank you for your help.  I managed to chroot into my system, and re-run 
'guix system reconfigure' (very useful mailing list discussion on 
chrooting, I also vote for including it in documentation :) ).  In one 
of the final steps, where guix tries to install the bootloader, I get 
the error:


/gnu/store/.../grub/i386-pc/modinfo.sh doesn't exist. Please specify 
--target or --directory.


Indeed my system uses grub-efi.  Could that be related?  Can you point 
me to some specific instructions on how to check/solve efivar issues?


Not sure if I need grub-efi, or if it might also work using grub-pc.  
Until now I've always used grub-efi.


(Another thing I noticed (maybe a side effect of chroot?): when I re-run 
'guix system reconfigure' it tries to rebuild derivations that are 
already there in the store from last time, I think.)


thank you!

Thomas

On 2021-10-01 08:53, pelzflorian (Florian Pelz) wrote:

On Thu, Sep 30, 2021 at 09:43:18AM +0200, Thomas Danckaert wrote:

Hello guix-help,

my system does not boot anymore after a guix pull and system 
reconfigure
(which did show a warning, see below).  It does not even enter the 
GRUB
stage, I get a "Reboot and Select proper Boot device" instead.  I 
think the
MBR might not have been written correctly (just a hunch, I'm no 
expert...).


If this system uses no old grub-bootloader but instead EFI
(grub-efi-bootloader), maybe writing the bootloader to the mainboard
failed (it is not only written to disk), perhaps because the mainboard
NVRAM is full and needs to be cleaned with efibootmgr/efivar/such
utilities.


During reconfigure, I did get a warning that my bootloader 
configuration
used 'target', which is apparently deprecated in favor of 'targets'.  
I
wasn't paying too much attention, and ignored the warning I don't 
know
if that could be the cause of a missing or incorrect boot record?  (In 
that

case, I suggest this warning should be an ERROR ;-) )


No, the old target would fall back to targets.  The warning is only a
warning that you should switch to (targets (list "…")).



I checked using a live USB, and it seems the whole system is still 
there on
the hard drive.  Is there a way to restore my system, keeping the 
existing
/gnu/store?  Or do I have to reinstall from scratch, remove the 
existing
/gnu/store and rebuild everything (shouldn't be too much work using 
Guix,

but way less elegant :) )

Thank you!

Thomas


I search on Duckduckgo for “site:lists.gnu.org guix chroot”, you
should read there how to chroot into your system so you can
reconfigure.

Regards,
Florian