'./pre-inst-env guix build xxx' can not find packages in other channels.

[Feng Shu]

Hello, 

I use the below channel setting:

  (service
   home-channels-service-type
   (cons* (channel
   (name 'nonguix)
   (url "https://gitlab.com/nonguix/nonguix";)
   ;; Enable signature verification:
   (introduction
(make-channel-introduction
 "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
 (openpgp-fingerprint
  "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5"
  %default-channels))


but when I run 

  ./pre-inst-env guix build unrar


it can not find unrar, for unrar is a package in nonguix channel. use -L
seem to work:

  ./pre-inst-env guix build unrar -L /path/to/nonguix.git

my question is: how to let pre-inst-env work well with my channel
setting, and no need to use -L in every command.


-- 

Re: './pre-inst-env guix build xxx' can not find packages in other channels.

[Ian Eure]

Hi Feng,

Feng Shu  writes:

Hello, 


I use the below channel setting:

  (service
   home-channels-service-type
   (cons* (channel
   (name 'nonguix)
   (url "https://gitlab.com/nonguix/nonguix";)
   ;; Enable signature verification:
   (introduction
(make-channel-introduction
 "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
 (openpgp-fingerprint
  "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB 
  B2D5"

  %default-channels))


but when I run 


  ./pre-inst-env guix build unrar


it can not find unrar, for unrar is a package in nonguix 
channel.


The pre-inst-env runs a different Guix than your user (or system) 
Guix, so it won’t know about things like your channel 
configuration.  Running `./pre-inst-env guix describe' will show 
you what I mean.


my question is: how to let pre-inst-env work well with my 
channel

setting, and no need to use -L in every command.


The pre-inst-env is for developing Guix itself, and isn’t needed 
to build packages from other channels.  A simple `guix build 
unrar' will build whatever version of unrar your current Guix 
knows about.  If you want to edit a package in a third-party 
channel, `guix build -L. unrar' inside the nonguix source tree is 
the best way to do that.


 -- Ian

Re: Guix on the MNT/Reform Status Update

[Vagrant Cascadian]

On 2025-03-26, Andreas Enge wrote:
> Am Sun, Mar 23, 2025 at 04:54:15PM -0700 schrieb Vagrant Cascadian:
>> Tested on MNT Reform2 with rk3588 module (other variants *might* work too!)
>
> I own an original Reform with the imx8mq module (I think)
...
> Would you mind sending me a configuration file and line-by-line
> instructions on what to do? I suppose it is a "guix system image"
> followed by a "dd" to the SD card?

I originally used "guix system init" to install mine from the booted
Debian system. "guix system image" at least used to assume
cross-compilation, so I have not tried it, but maybe that would work to
cross-build an image from an x86_64 system that you could then DD to the
SD card.

You could adapt:

  
https://codeberg.org/vagrantc/mnt-reform-guix-config/src/branch/main/config-mnt-reform.scm

First I would boot your MNT Reform with whatever OS you have now. You
will need to make some changes to kernel-arguments (check the contents
of /proc/cmdline) and initrd-modules (check lsmod output).

My guess for kernel-arguments:

  (kernel-arguments '("no_console_suspend"
  "cryptomgr.notests"
  "loglevel=3"
  "console=ttymxc0,115200"
  "cma=512M"
  "pci=nomsi"))

For the initrd-modules, you should be able to just add all the modules
you get from lsmod. Probably overkill, but hopefully will work! :)

You should also probably adjust the hostname, username, and probably
remove the file-system entry for /tmp, and definitely the file-system
entry for / rootfs. This is all standard guix system stuff so I am not
going to get into specifics. :)

Remove the u-boot-mnt-reform-rk3588 to save yourself some useless build
time, since that is for a different platform anyways!


> Hm, but where would the uboot come from then?

You might need to manually install u-boot on the SD card, unless you are
lucky and it is installed on the eMMC built into the imx8mq module:

  https://source.mnt.re/reform/reform-handbook/-/issues/2

Let us hope you are lucky. :)

Otherwise, you will need to download or build an appropriate u-boot
image and then manually dd to the SD card at a specific offset I do not
recall off the top of my head, but luckily it is documented:

  https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/flash.sh

If there is a flash.bin in your current /boot, you might be able to use
that, either installing it to eMMC or installing it to the new SD card.


When you try to boot it, you will probably want to connect to the serial
console, unless you are even luckier and need to do no further
debugging!


Hopefully that is enough to get started. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: emacs-next periodic updates

[Gabriel Santos]

Greetings,

My e-mail provider is still having issues with spam.

To circumvent this, I created a new Gmail account,
viz. gabriel.santos.s...@gmail.com, and
sent a patch from it.

Here is a link to the patch thread, this new message
should arrive soon:


Regards,

-- 
Gabriel Santos

Fwd: Security issues with grub?

[Leo Famulari]

This was sent to guix-security a few weeks ago. However, the issues it 
describes are public, so I'm forwarding it to this mailing list.

The guix-security mailing list is only for reports of secret problems.

- Original message -
From: Efraim Flashner 
To: guix-secur...@gnu.org
Subject: Security issues with grub?
Date: Wednesday, March 05, 2025 07:45

Forwarding along an email I received.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
--- Begin Message ---
Hi,

I forgot to contact you about security vulnerabilities in GRUB.

In a nutshell there is[1]:
- Secure boot bypass. Guix is marginally affected. 
  It affects all flavor of secure boot: 
  - 100% encrypted disks + passphrase to access GRUB
  - any form of gpg based secure boot
  - UEFI secure boot.
  While Guix doesn't support UEFI secure boot and (2) Guix probably
  doesn't support the other flavors of secure boot either through its
  configuration system, it is still possible to (re-)use Guix to build
  GRUB images that are involved in secure boot. It however require a
  custom grub.cfg not provided by Guix. 

- Arbitrary execution of code may be doable through the filesystem,
  but it's unclear if a file not owned by root could do that as of few
  days ago there were no known exploits for these CVEs.

- It might also possible to craft JPEG files to gain arbitrary
  execution of code, but that might need to be included in a GRUB theme
  somehow by users.

It is however really messy to fix as the only way to fix is to use the
latest git revision due to the lack of resources of the GRUB
maintainers / package[2], and in Guix that means that we need to
unbundle gnulib at least.

In any case if you are interested, I've started working on it[3] but the
patches I came with have several issues:

- We can't merge them as-is because building an image stops working. I'm
  not familiar enough with the non-package code to really understand the
  issue.

- GRUB builds fine on x86_64 computers but not on i686 computers
  (tested on a core duo), but it builds fine on x86_64 with
  --system=i686-linux. I'll try to reproduce in a standalone VM somehow
  as I didn't manage to create a 'build-vm' with a core duo, and I would
  need to find a way to tell Guix to build the rootfs for i686 anyway.

I've already tested this change with grub-coreoot on real hardware
though.

References:
---
[1]https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html
[2]https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00124.html
[3]https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76208

Denis.


pgpjTHt_QWTll.pgp
Description: OpenPGP digital signature
--- End Message ---


signature.asc
Description: PGP signature

Pretty-printing configuration files

[Development of GNU Guix and the GNU System distribution.]

Hi,

Any chance we can start pretty-printing configuration files?

They are easier to read, and M-x debpaste is less likely to reject them
as spam because they contain at least two line breaks. [1]

Kind regards
Felix

[1] 
https://github.com/formorer/paste.pl/blob/32e7f1e4a92a6a71fe16e2dea9b30aefb72ae010/lib/Paste.pm#L217