bug#41120: uvesafb service is unsupported on aarch64

2022-08-05 Thread pelzflorian (Florian Pelz)
Pavel Shlyak  writes:
> 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-d...@debbugs.gnu.org.

Regards,
Florian





bug#41120: uvesafb service is unsupported on aarch64

2022-08-04 Thread Pavel Shlyak
This one is done with https://issues.guix.gnu.org/55806. I suggest closing it 
as resolved.




bug#41120: uvesafb service is unsupported on aarch64

2021-12-29 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix
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 
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(-)

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 
 ;;; Copyright © 2016 Andreas Enge 
 ;;; Copyright © 2017 Marius Bakke 
-;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice 
+;;; Copyright © 2017, 2019, 2021 Tobias Geerinckx-Rice 
 ;;; Copyright © 2020 Florian Pelz 
 ;;; Copyright © 2020 Efraim Flashner 
 ;;;
@@ -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



signature.asc
Description: PGP signature


bug#41120: uvesafb service is unsupported on aarch64

2021-12-29 Thread Efraim Flashner
On Tue, Dec 28, 2021 at 09:30:27PM -0500, Leo Famulari wrote:
> 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  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature


bug#41120: uvesafb service is unsupported on aarch64

2021-12-28 Thread Leo Famulari
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?





bug#41120: uvesafb service is unsupported on aarch64

2020-05-18 Thread Mathieu Othacehe


Hey Ludo,

> 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





bug#41120: uvesafb service is unsupported on aarch64

2020-05-15 Thread Ludovic Courtès
Hi Mathieu,

Mathieu Othacehe  skribis:

> 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’.





bug#41120: uvesafb service is unsupported on aarch64

2020-05-14 Thread Ludovic Courtès
Hi,

Mathieu Othacehe  skribis:

> 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’.





bug#41120: uvesafb service is unsupported on aarch64

2020-05-13 Thread Mathieu Othacehe

Hello,

> 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
>From dde0a1ca499a4ef0592d10158a00add16386bebb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Wed, 13 May 2020 14:34:17 +0200
Subject: [PATCH 1/2] gexp: Compilers can now return lowerable objects.

* guix/gexp.scm (lower-object): Iterate if LOWERED is a struct.
(lower+expand-object): New procedure.
(gexp->sexp): Use it.
(define-gexp-compiler): Adjust docstring.
---
 guix/gexp.scm | 71 ++-
 1 file changed, 48 insertions(+), 23 deletions(-)

diff --git a/guix/gexp.scm b/guix/gexp.scm
index 2a4b36519c..a9a4b89ab4 100644
--- a/guix/gexp.scm
+++ b/guix/gexp.scm
@@ -226,32 +226,59 @@ procedure to expand it; otherwise return #f."
 corresponding to OBJ for SYSTEM, cross-compiling for TARGET if TARGET is true.
 OBJ must be an object that has an associated gexp compiler, such as a
 ."
-  (match (lookup-compiler obj)
-(#f
- (raise (condition (&gexp-input-error (input obj)
-(lower
- ;; Cache in STORE the result of lowering OBJ.
- (mlet %store-monad ((target (if (eq? target 'current)
- (current-target-system)
- (return target)))
- (graft? (grafting?)))
-   (mcached (let ((lower (lookup-compiler obj)))
-  (lower obj system target))
-obj
-system target graft?)
+  (let loop ((obj obj))
+(match (lookup-compiler obj)
+  (#f
+   (raise (condition (&gexp-input-error (input obj)
+  (lower
+   ;; Cache in STORE the result of lowering OBJ.
+   (mlet* %store-monad
+   ((target (if (eq? target 'current)
+(current-target-system)
+(return target)))
+(graft? (grafting?))
+(lowered (mcached (let ((lower (lookup-compiler obj)))
+(lower obj system target))
+  obj
+  system target graft?)))
+ (if (and (struct? lowered) (not (eq? lowered obj)))
+ (loop lowered)
+ (return lowered)))
+
+(define* (lower+expand-object obj
+  #:optional (system (%current-system))
+  #:key target (output "out"))
+  "Return as a value in %STORE-MONAD the output of object OBJ expands to for
+SYSTEM and TARGET.  Object such as , , or 
+expand to file names, but it's possible to expand to a plain data type."
+  (let loop ((obj obj)
+ (expand (and (struct? obj) (lookup-expander obj
+(match (lookup-compiler obj)
+  (#f
+   (raise (condition (&gexp-input-error (input obj)
+  (lower
+   (mlet %store-monad ((lowered (lower obj system target)))
+ ;; LOWER might return something that needs to be further lowered.
+ (if (struct? lowered)
+ ;; If we lack an expander, delegate to that of LOWERED.
+ (if (not expand)
+ (loop lowered (lookup-expander lowered))
+ (return (expand obj lowered output)))
+ (return lowered)))   ;lists, vectors, etc.
 
 (define-syntax define-gexp-compiler
   (syntax-rules (=> compiler expander)
 "Define NAME as a compiler for objects matching PREDICATE encountered in
 gexps.
 
-In the simplest form of the macro, BODY must return a derivation for PARAM, an
-object that matches PREDICATE, for SYSTEM and TARGET (the latter of which is
-#f except when cross-compiling.)
+In the simplest form of the macro, BODY must return (1) a derivation for
+a record of the specified type, for SYSTEM and TARGET (the latter of which is
+#f except when cross-compiling), (2) another record that can itself be
+compiled down to a derivation, or (3) an object of a primitive data type.
 
 Th

bug#41120: uvesafb service is unsupported on aarch64

2020-05-08 Thread Mathieu Othacehe


Hello,

Thanks for working on that Florian & Efraim.

> +   (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:

--8<---cut here---start->8---
(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
--8<---cut here---end--->8---

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





bug#41120: uvesafb service is unsupported on aarch64

2020-05-07 Thread pelzflorian (Florian Pelz)
On Thu, May 07, 2020 at 04:55:13PM +0200, pelzflorian (Florian Pelz) wrote:
> 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 
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 .
Suggested by Efraim Flashner .

* 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(-)

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



bug#41120: uvesafb service is unsupported on aarch64

2020-05-07 Thread pelzflorian (Florian Pelz)
On Thu, May 07, 2020 at 11:12:34AM +0300, Efraim Flashner wrote:
> 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 
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 .
Suggested by Efraim Flashner .

* 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(-)

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



bug#41120: uvesafb service is unsupported on aarch64

2020-05-07 Thread Efraim Flashner
On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote:
> 
> 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  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature


bug#41120: uvesafb service is unsupported on aarch64

2020-05-07 Thread Efraim Flashner
On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote:
> 
> 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  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature


bug#41120: uvesafb service is unsupported on aarch64

2020-05-07 Thread Mathieu Othacehe


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?

Thanks,

Mathieu





bug#41120: uvesafb service is unsupported on aarch64

2020-05-06 Thread Efraim Flashner
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  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature