uvesafb service is unsupported on aarch64

Done

Details

8 participants

Efraim Flashner
Leo Famulari
Ludovic Courtès
Mathieu Othacehe
Tobias Geerinckx-Rice
Mathieu Othacehe
Pavel Shlyak
pelzflorian (Florian Pelz)

Owner: unassigned

Submitted by: Efraim Flashner

Severity: normal

Merged with

48393

Efraim Flashner wrote on 7 May 2020 07:40

Recipients:(address . bug-guix@gnu.org)

Message-ID:20200507054015.GG2359@E5400

the uvesafb-service which was added to the installation image isn't

supported on aarch64 (or probably any non-x86 system) and causes the

creation of an installation image to fail.

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Mathieu Othacehe wrote on 7 May 2020 09:06

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 41120@debbugs.gnu.org)

Message-ID:87wo5ody1e.fsf@gmail.com

Hello Efraim,

Toggle quote (4 lines)

> the uvesafb-service which was added to the installation image isn't

> supported on aarch64 (or probably any non-x86 system) and causes the

> creation of an installation image to fail.

Thanks for reporting. There's this small snippet in uvesafb-service:

Toggle snippet (5 lines)

(or (not (and (string-suffix? "linux-gnu" %host-type)

(or (string-prefix? "x86_64" %host-type)

(string-prefix? "i686" %host-type))))

which must then fail? Do you have a specific error message?

Thanks,

Mathieu

Efraim Flashner wrote on 7 May 2020 10:05

Recipients:(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 41120@debbugs.gnu.org)

Message-ID:20200507080522.GI2359@E5400

On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote:

Toggle quote (18 lines)> 
> Hello Efraim,
> 
> > the uvesafb-service which was added to the installation image isn't
> > supported on aarch64 (or probably any non-x86 system) and causes the
> > creation of an installation image to fail.
> 
> Thanks for reporting. There's this small snippet in uvesafb-service:
> 
> --8<---------------cut here---------------start------------->8---
>   (or (not (and (string-suffix? "linux-gnu" %host-type)
>                 (or (string-prefix? "x86_64" %host-type)
>                     (string-prefix? "i686" %host-type))))
> --8<---------------cut here---------------end--------------->8---
> 
> which must then fail? Do you have a specific error message?
> 

It fails while building v86d. Looking at the or statement, it should
probably close after (file-exists? "/dev/fb0") and then the whole thing
wrapped in a when or an if. I checked and /dev/fb0 doesn't exist on my
machine.

Actually that didn't make a difference, it still tried to build v86d.
Even changing the '(or (not' to '(if (and (and' it still tries to build
v86d. My guess is that it's not evaluating the conditionals until it's
time to run the service so it makes sure v86d is there.

-- 
Efraim Flashner   <efraim@flashner.co.il>   ????? ?????
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Efraim Flashner wrote on 7 May 2020 10:12

Recipients:(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 41120@debbugs.gnu.org)

Message-ID:20200507081234.GJ2359@E5400

On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote:

Toggle quote (18 lines)> 
> Hello Efraim,
> 
> > the uvesafb-service which was added to the installation image isn't
> > supported on aarch64 (or probably any non-x86 system) and causes the
> > creation of an installation image to fail.
> 
> Thanks for reporting. There's this small snippet in uvesafb-service:
> 
> --8<---------------cut here---------------start------------->8---
>   (or (not (and (string-suffix? "linux-gnu" %host-type)
>                 (or (string-prefix? "x86_64" %host-type)
>                     (string-prefix? "i686" %host-type))))
> --8<---------------cut here---------------end--------------->8---
> 
> which must then fail? Do you have a specific error message?
> 

I haven't tested the produced image, but the following builds without
trying to also build v86d

         (start
           (if (and (and (string-suffix? "linux-gnu" %host-type)
                         (or (string-prefix? "x86_64" %host-type)
                             (string-prefix? "i686" %host-type)))
                    (file-exists? "/dev/fb0"))
             #~(lambda ()
                 ;; uvesafb is only supported on x86 and x86_64.
                 (invoke #+(file-append kmod "/bin/modprobe")
                         "uvesafb"
                         (string-append "v86d=" #$v86d "/sbin/v86d")
                         "mode_option=1024x768"))
             #~(lambda () #t)))

-- 
Efraim Flashner   <efraim@flashner.co.il>   ????? ?????
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

pelzflorian (Florian Pelz) wrote on 7 May 2020 16:55

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:20200507145511.zfw5474uzecs2oum@pelzflorian.localdomain

On Thu, May 07, 2020 at 11:12:34AM +0300, Efraim Flashner wrote:

Toggle quote (16 lines)> I haven't tested the produced image, but the following builds without
> trying to also build v86d
> 
>          (start
>            (if (and (and (string-suffix? "linux-gnu" %host-type)
>                          (or (string-prefix? "x86_64" %host-type)
>                              (string-prefix? "i686" %host-type)))
>                     (file-exists? "/dev/fb0"))
>              #~(lambda ()
>                  ;; uvesafb is only supported on x86 and x86_64.
>                  (invoke #+(file-append kmod "/bin/modprobe")
>                          "uvesafb"
>                          (string-append "v86d=" #$v86d "/sbin/v86d")
>                          "mode_option=1024x768"))
>              #~(lambda () #t)))

This way uvesafb is started unconditionally on x86_64, even when it is

not needed, leading to video corruption on some boots in QEMU.

I have more success with moving the file-exists check into the

#~(lambda …) like the attached patch. But I’m not sure it really

fixes ARM builds.

I tested via

qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm -nic user,model=virtio-net-pci -boot menu=on,order=d -drive media=cdrom,file=/gnu/store/0cgbp4y7awk4spg49ajw077xyzk24fi0-iso9660-image

and on hardware. With QEMU, uvesafb is needed if and only if

nomodeset is passed as a kernel parameter.

Now how to build an ARM image for QEMU?

Sorry I left such a mess with uvesafb.

Regards,

Florian

From 13fd2b590e37095ed4213d7bb85422b48deab9c6 Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Thu, 7 May 2020 13:26:19 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] installer: Do not load uvesafb on non-x86 install images.

Fixes https://bugs.gnu.org/41120.
Suggested by Efraim Flashner <efraim@flashner.co.il>.

* gnu/system/install.scm (uvesafb-shepherd-service): Do not build x86-only
v86d helper unconditionally.
---
 gnu/system/install.scm | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

Toggle diff (35 lines)diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 6435c1bff4..ad8a84091c 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -299,16 +299,18 @@ the user's target storage device rather than on the RAM disk."
          (documentation "Load the uvesafb kernel module if needed.")
          (provision '(maybe-uvesafb))
          (requirement '(file-systems))
-         (start #~(lambda ()
-                    ;; uvesafb is only supported on x86 and x86_64.
-                    (or (not (and (string-suffix? "linux-gnu" %host-type)
-                                  (or (string-prefix? "x86_64" %host-type)
-                                      (string-prefix? "i686" %host-type))))
-                        (file-exists? "/dev/fb0")
-                        (invoke #+(file-append kmod "/bin/modprobe")
-                                "uvesafb"
-                                (string-append "v86d=" #$v86d "/sbin/v86d")
-                                "mode_option=1024x768"))))
+         (start
+           (if (and (and (string-suffix? "linux-gnu" %host-type)
+                         (or (string-prefix? "x86_64" %host-type)
+                             (string-prefix? "i686" %host-type)))
+                    (file-exists? "/dev/fb0"))
+             #~(lambda ()
+                 ;; uvesafb is only supported on x86 and x86_64.
+                 (invoke #+(file-append kmod "/bin/modprobe")
+                         "uvesafb"
+                         (string-append "v86d=" #$v86d "/sbin/v86d")
+                         "mode_option=1024x768"))
+             #~(lambda () #t)))
          (respawn? #f)
          (one-shot? #t))))
 
-- 
2.26.1

pelzflorian (Florian Pelz) wrote on 7 May 2020 16:58

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:20200507145801.nmedsi44wtparffh@pelzflorian.localdomain

On Thu, May 07, 2020 at 04:55:13PM +0200, pelzflorian (Florian Pelz) wrote:

Toggle quote (3 lines)

> I have more success with moving the file-exists check into the

> #~(lambda …) like the attached patch.

Sorry I forgot to git add. This is the patch.

From f88b1b487d48c959a7ed00d6032ccfe05aa81f0e Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Thu, 7 May 2020 13:26:19 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] installer: Do not load uvesafb on non-x86 install images.

Fixes https://bugs.gnu.org/41120.
Suggested by Efraim Flashner <efraim@flashner.co.il>.

* gnu/system/install.scm (uvesafb-shepherd-service): Do not build x86-only
v86d helper unconditionally.
---
 gnu/system/install.scm | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

Toggle diff (35 lines)diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 6435c1bff4..952dee464f 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -299,16 +299,18 @@ the user's target storage device rather than on the RAM disk."
          (documentation "Load the uvesafb kernel module if needed.")
          (provision '(maybe-uvesafb))
          (requirement '(file-systems))
-         (start #~(lambda ()
-                    ;; uvesafb is only supported on x86 and x86_64.
-                    (or (not (and (string-suffix? "linux-gnu" %host-type)
-                                  (or (string-prefix? "x86_64" %host-type)
-                                      (string-prefix? "i686" %host-type))))
-                        (file-exists? "/dev/fb0")
-                        (invoke #+(file-append kmod "/bin/modprobe")
-                                "uvesafb"
-                                (string-append "v86d=" #$v86d "/sbin/v86d")
-                                "mode_option=1024x768"))))
+         (start
+           (if (and (string-suffix? "linux-gnu" %host-type)
+                    (or (string-prefix? "x86_64" %host-type)
+                        (string-prefix? "i686" %host-type)))
+               #~(lambda ()
+                   ;; uvesafb is only supported on x86 and x86_64.
+                   (or (file-exists? "/dev/fb0")
+                       (invoke #+(file-append kmod "/bin/modprobe")
+                               "uvesafb"
+                               (string-append "v86d=" #$v86d "/sbin/v86d")
+                               "mode_option=1024x768")))
+               #~(lambda () #t)))
          (respawn? #f)
          (one-shot? #t))))
 
-- 
2.26.1

Mathieu Othacehe wrote on 8 May 2020 11:09

Recipients:(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)

Message-ID:875zd6lro0.fsf@gmail.com

Hello,

Thanks for working on that Florian & Efraim.

Toggle quote (14 lines)> +           (if (and (string-suffix? "linux-gnu" %host-type)
> +                    (or (string-prefix? "x86_64" %host-type)
> +                        (string-prefix? "i686" %host-type)))
> +               #~(lambda ()
> +                   ;; uvesafb is only supported on x86 and x86_64.
> +                   (or (file-exists? "/dev/fb0")
> +                       (invoke #+(file-append kmod "/bin/modprobe")
> +                               "uvesafb"
> +                               (string-append "v86d=" #$v86d "/sbin/v86d")
> +                               "mode_option=1024x768")))
> +               #~(lambda () #t)))
>           (respawn? #f)
>           (one-shot? #t))))

The issue with using %host-type at build time is that it won't support

system build with --system and --target. For instance if cross-compiling

for aarch64-linux-gnu on a x86_64 system, %host-type will be

"x86_64-..." and we will try to build v86d for aarch64.

We could maybe do something like that:

Toggle snippet (17 lines)(define (operating-system-hardware-specific-services)
  #~(let-system (system target)
                (cond
                 ((target-arm? system target)
                  '())
                 ((target-intel? system target)
                  (list uvesafb-shepherd-service)))))

(define (operating-system-kernel-specific-services)
  #~(let-system (system target)
                (cond
                 ((target-linux? system target)
                  linux-specific-services)
                 ((target-hurd? system target)
                  hurd-specific-services))))

This way, uvesafb-shepherd-service would be built and installed only

when producing a system targeting an Intel CPU. We could also extend

this mechanism to have kernel specific services.

That would mean, we need to dig out Ludo patch introducing

let-system[1], but I think it was almost ready.

Adding janneke, Danny and Ludo to the discussion.

WDYT?

Thanks,

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-patches/2017-11/msg00274.html

Mathieu Othacehe wrote on 13 May 2020 14:50

Recipients:(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)

Message-ID:87blms3snh.fsf@gnu.org

Hello,

Toggle quote (25 lines)> We could maybe do something like that:
>
> (define (operating-system-hardware-specific-services)
>   #~(let-system (system target)
>                 (cond
>                  ((target-arm? system target)
>                   '())
>                  ((target-intel? system target)
>                   (list uvesafb-shepherd-service)))))
>
> (define (operating-system-kernel-specific-services)
>   #~(let-system (system target)
>                 (cond
>                  ((target-linux? system target)
>                   linux-specific-services)
>                  ((target-hurd? system target)
>                   hurd-specific-services))))
>
> This way, uvesafb-shepherd-service would be built and installed only
> when producing a system targeting an Intel CPU. We could also extend
> this mechanism to have kernel specific services.
>
> That would mean, we need to dig out Ludo patch introducing
> let-system[1], but I think it was almost ready.

Here's a rebased version of Ludo's patch. I'm not sure about the merge

resolution in "lower-object", but otherwise it works fine!

Ludo, would it be of to push it?

Thanks,

Mathieu

Attachment: 0001-gexp-Compilers-can-now-return-lowerable-objects.patch

Attachment: 0002-gexp-Add-let-system.patch

Ludovic Courtès wrote on 14 May 2020 10:16

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:873683vsm9.fsf@gnu.org

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (5 lines)

> Here's a rebased version of Ludo's patch. I'm not sure about the merge

> resolution in "lower-object", but otherwise it works fine!

> Ludo, would it be of to push it?

I’d like to think a bit more about it. In particular, ‘let-system’ is

not great because we’d also want to know the target in many cases.

Sorry for the delay, I need to swap that in!

Ludo’.

Ludovic Courtès wrote on 16 May 2020 00:43

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:87sgg0stt5.fsf@gnu.org

Hi Mathieu,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (3 lines)

> Here's a rebased version of Ludo's patch. I'm not sure about the merge

> resolution in "lower-object", but otherwise it works fine!

I took another look, and you’re right, it does the job. There were a

couple of issues: returning a self-quoting value as in

(let-system s s)

wouldn’t work, and also caching wasn’t quite right (could be seen by

comparing GUIX_PROFILING="add-data-to-store-cache object-cache" before

and after).

Anyway, it took me much more time than I thought, but it’s here now:

502f609d05 vm: Use 'let-system'.

300a54bb98 utils: 'target-arm32?' & co. take an optional parameter.

644cb40cd8 gexp: Add 'let-system'.

d03001a31a gexp: Compilers can now return lowerable objects.

Let me know how it goes!

Ludo’.

Mathieu Othacehe wrote on 18 May 2020 14:16

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87o8qlfnff.fsf@gnu.org

Hey Ludo,

Toggle quote (9 lines)

> Anyway, it took me much more time than I thought, but it’s here now:

> 502f609d05 vm: Use 'let-system'.

> 300a54bb98 utils: 'target-arm32?' & co. take an optional parameter.

> 644cb40cd8 gexp: Add 'let-system'.

> d03001a31a gexp: Compilers can now return lowerable objects.

> Let me know how it goes!

Thanks a lot, it's a great addition. I plan to use it soon to have

kernel/architecture specific services, as I proposed earlier in this

thread.

Mathieu

Leo Famulari wrote on 20 Aug 2021 20:10

(no subject)

Recipients:(address . control@debbugs.gnu.org)

Message-ID:YR/v+wtIB2vWVVCk@jasmine.lan

merge 41120 48393

Leo Famulari wrote on 29 Dec 2021 03:30

Re: bug#41120: uvesafb service is unsupported on aarch64

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 41120@debbugs.gnu.org)

Message-ID:YcvIQ5IdeWIYzcuF@jasmine.lan

On Thu, May 07, 2020 at 08:40:15AM +0300, Efraim Flashner wrote:

Toggle quote (4 lines)

> the uvesafb-service which was added to the installation image isn't

> supported on aarch64 (or probably any non-x86 system) and causes the

> creation of an installation image to fail.

This is still an issue, right?

Efraim Flashner wrote on 29 Dec 2021 09:20

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 41120@debbugs.gnu.org)

Message-ID:YcwaZERAhd6CL6ZF@3900XT

On Tue, Dec 28, 2021 at 09:30:27PM -0500, Leo Famulari wrote:

Toggle quote (7 lines)

> On Thu, May 07, 2020 at 08:40:15AM +0300, Efraim Flashner wrote:

> > the uvesafb-service which was added to the installation image isn't

> > supported on aarch64 (or probably any non-x86 system) and causes the

> > creation of an installation image to fail.

> This is still an issue, right?

I believe so. Borrowing from the manual I tried the following command

and it showed that it was going to build v86d.

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

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Tobias Geerinckx-Rice wrote on 29 Dec 2021 23:03

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:87pmpfdpwd.fsf@nckx

I wrote the attached quick fix, then noticed that this bug is

paired with #29296 which seems to propose a whole 'nother

mechanism?

I'm not sure I grok the latter's advantage yet.

Kind regards,

T G-R

From 29d6ce59a0f3953de627d110adaa7978051ca077 Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice <me@tobias.gr>
Date: Wed, 29 Dec 2021 23:01:11 +0100
Subject: [PATCH] install: Add uvesafb service only on x86.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/system/install.scm (%installation-services): Turn into…
(installation-services): …this procedure.  Adjust sole user.
Add the uvesafb-service-type only when targetting x86.
---
 gnu/system/install.scm | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

Toggle diff (74 lines)diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 073d7df1db..36c24992bd 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -3,7 +3,7 @@
 ;;; Copyright © 2015 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2016 Andreas Enge <andreas@enge.fr>
 ;;; Copyright © 2017 Marius Bakke <mbakke@fastmail.com>
-;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
+;;; Copyright © 2017, 2019, 2021 Tobias Geerinckx-Rice <me@tobias.gr>
 ;;; Copyright © 2020 Florian Pelz <pelzflorian@pelzflorian.de>
 ;;; Copyright © 2020 Efraim Flashner <efraim@flashner.co.il>
 ;;;
@@ -33,6 +33,7 @@ (define-module (gnu system install)
   #:use-module (guix modules)
   #:use-module ((guix packages) #:select (package-version))
   #:use-module ((guix store) #:select (%store-prefix))
+  #:use-module (guix utils)
   #:use-module (gnu installer)
   #:use-module (gnu system locale)
   #:use-module (gnu services avahi)
@@ -303,7 +304,7 @@ (define uvesafb-service-type
     "Load the @code{uvesafb} kernel module with the right options.")
    (default-value #t)))
 
-(define %installation-services
+(define (installation-services)
   ;; List of services of the installation system.
   (let ((motd (plain-file "motd" "
 \x1b[1;37mWelcome to the installation of GNU Guix!\x1b[0m
@@ -320,7 +321,9 @@ (define (normal-tty tty)
     (define bare-bones-os
       (load "examples/bare-bones.tmpl"))
 
-    (list (service virtual-terminal-service-type)
+    (append
+        (list
+          (service virtual-terminal-service-type)
 
           (service kmscon-service-type
                    (kmscon-configuration
@@ -426,13 +429,15 @@ (define bare-bones-os
                           glibc-utf8-locales
                           texinfo
                           guile-3.0)
-                    %default-locale-libcs))
+                    %default-locale-libcs)))
 
-          ;; Machines without Kernel Mode Setting (those with many old and
-          ;; current AMD GPUs, SiS GPUs, ...) need uvesafb to show the GUI
-          ;; installer.  Some may also need a kernel parameter like nomodeset
-          ;; or vga=793, but we leave that for the user to specify in GRUB.
-          (service uvesafb-service-type))))
+        (if (or (target-x86-32?) (target-x86-64?))
+            ;; x86 machines without Kernel Mode Setting (those with many old and
+            ;; current AMD GPUs, SiS GPUs, ...) need uvesafb to show the GUI
+            ;; installer.  Some may also need a kernel parameter like nomodeset
+            ;; or vga=793, but we leave that for the user to specify in GRUB.
+            (list (service uvesafb-service-type))
+            '()))))
 
 (define %issue
   ;; Greeting.
@@ -496,7 +501,7 @@ (define installation-os
                   (comment "Guest of GNU"))))
 
     (issue %issue)
-    (services %installation-services)
+    (services (installation-services))
 
     ;; We don't need setuid programs, except for 'passwd', which can be handy
     ;; if one is to allow remote SSH login to the machine being installed.
-- 
2.34.0

-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYczcog0cbWVAdG9iaWFz

LmdyAAoJEA2w/4hPVW15XssBAIHTtskPeLlO0Move9HIgNOeVlY6csO8KIR1je48

poz/AQDCu1+x67VvQoOot0UU1hYESmzXYeR9/c0M4Y3YoAj9Cg==

=rKtj

-----END PGP SIGNATURE-----

Pavel Shlyak wrote on 5 Aug 2022 01:03

uvesafb service is unsupported on aarch64

Recipients:(address . 41120@debbugs.gnu.org)

Message-ID:A5431DF0-3E65-435A-B31F-41B419F84045@pantherx.org

This one is done with https://issues.guix.gnu.org/55806.I suggest closing it as resolved.

pelzflorian (Florian Pelz) wrote on 5 Aug 2022 14:59

Recipients:(address . 41120-done@debbugs.gnu.org)(name . Pavel Shlyak)(address . p.shlyak@pantherx.org)

Message-ID:87czdej17o.fsf@pelzflorian.de

Pavel Shlyak <p.shlyak@pantherx.org> writes:

Toggle quote (2 lines)

> This one is done with https://issues.guix.gnu.org/55806.I suggest closing it as resolved.

Indeed.  With 55806, the uvesafb is added if (supported-package? v86d
system), avoiding the need to check the system.  I’m Closing by sending
a mail to 41120-done@debbugs.gnu.org.

Regards,
Florian

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 41120@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 41120

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date