Come back and graphical installer

Come back and graphical installer

[Mathieu Othacehe]

Hi Guix !

First mail since a while ! I'm currently finishing a long bicycle trip,
and was able to start hacking again.

I picked up the "Graphical installer" task. After studying the branch
wip-installer-2, I choose to rewrite it for multiple reasons:

* I found the guile-ncurses approach too low level and think that many
  bugs in the current installer could be avoided with a higher level
  library.
* As suggested by Ludo[1], using a network manager seems to be a better
  idea that calling iw, ip and other low level tools.
* I prefer relying on a Guile-parted library rather than calling cfdisk
  and again interfacing with various partioning tools.

While a lot of work have been accomplished by John and Danny, fixing the
above issues mean rewrite it almost completely anyway.

So, I wrote Guile bindings for newt[2], which can be found here[3]. Newt
is the library used by Debian installer and the Anaconda installer
(RedHat, Centos, ...).

I choose to interface with Connman via connmanctl. It would have been
better to use DBus but it implies writing Guile-dbus and I did not have
the courage.

Based on this, I have a first draft for a new installer here[4]. I plan
to push it on a wip savannah branch soon. Most of the basic features are
implemented and the last missing part it the partioning one (also the
bigger ...).

I will soon share some iso files to have some feedbacks. Even if it
might be too late already, I think that releasing the 1.0 with a
graphical installer would be a big plus.

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01255.html
[2]: https://en.wikipedia.org/wiki/Newt_(programming_library)
[3]: https://gitlab.com/mothacehe/guile-newt
[4]: https://github.com/mothacehe/guix/tree/installer

Re: Come back and graphical installer

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

Hi Mathieu,

It's very nice that you picked up the task, I guess it's a very important step
for Guix!  Thanks for the hard work! :)

I'm a bit late to the discussion, so maybe this was discussed before, but what
about a graphical installer (X / Wayland)?  I think it would offer more appeal
to a wider audience.  People acquainted to curses-like interfaces are usually
also familiar with commandline, which is the current way of installing

For example, I think Antergos (https://antergos.com/) has a very nice and well
polished installer.

Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Come back and graphical installer

[Mathieu Othacehe]

Hi Pierre,

> I'm a bit late to the discussion, so maybe this was discussed before, but what
> about a graphical installer (X / Wayland)?  I think it would offer more appeal
> to a wider audience.  People acquainted to curses-like interfaces are usually
> also familiar with commandline, which is the current way of installing

I remember this topic has been discussed here:

http://lists.gnu.org/archive/html/guix-devel/2017-09/msg00247.html

To give you my opinion, I think that having a X/Wayland installer would
be really nice and totally agree. However, I also think it is important
to capitalize on the work already done. Plus, writting this kind of
installer is quite complicated because:

* Using Anaconda[1] as suggested by Harmut would mean interfacing a huge
  codebase in Python, written for FHS based distributions.
* To write this kind of installer in Guile, we need bindings for a nice
  high level graphical library and we have to be careful not to increase
  too much the installer footprint.

So this seems that something we want in the future but that is a bit out
of reach for the 1.0 release.

Mathieu

[1]: https://en.wikipedia.org/wiki/Anaconda_(installer)

Re: Come back and graphical installer

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Mathieu Othacehe <m.othacehe@gmail.com> writes:

> First mail since a while ! I'm currently finishing a long bicycle trip,
> and was able to start hacking again.

Welcome back.  I hope you had a great, refreshing trip!

> I picked up the "Graphical installer" task. After studying the branch
> wip-installer-2, I choose to rewrite it for multiple reasons:
>
> [...]
>
> Based on this, I have a first draft for a new installer here[4]. I plan
> to push it on a wip savannah branch soon. Most of the basic features are
> implemented and the last missing part it the partioning one (also the
> bigger ...).

Wow!  This is great to hear.  I'll look into trying this soon, and give
you feedback when I do.  Many thanks for working on it!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Come back and graphical installer

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]


> * To write this kind of installer in Guile, we need bindings for a nice
>   high level graphical library and we have to be careful not to increase
>   too much the installer footprint.

This could be a great opportunity to revamp Guile-gnome ;)

> So this seems that something we want in the future but that is a bit out
> of reach for the 1.0 release.

I'd be very interested to work on this at some point.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Come back and graphical installer

[Ludovic Courtès]

Hello!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> To give you my opinion, I think that having a X/Wayland installer would
> be really nice and totally agree. However, I also think it is important
> to capitalize on the work already done. Plus, writting this kind of
> installer is quite complicated because:
>
> * Using Anaconda[1] as suggested by Harmut would mean interfacing a huge
>   codebase in Python, written for FHS based distributions.
> * To write this kind of installer in Guile, we need bindings for a nice
>   high level graphical library and we have to be careful not to increase
>   too much the installer footprint.
>
> So this seems that something we want in the future but that is a bit out
> of reach for the 1.0 release.

Seconded.  To me the graphical installer is in the nice-to-have
category and not in the 1.0-blocker category.

Ludo’.

Re: Come back and graphical installer

[Ludovic Courtès]

Hello Mathieu!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> First mail since a while ! I'm currently finishing a long bicycle trip,
> and was able to start hacking again.

Welcome back, I hope you had a good time!

> I picked up the "Graphical installer" task. After studying the branch
> wip-installer-2, I choose to rewrite it for multiple reasons:
>
> * I found the guile-ncurses approach too low level and think that many
>   bugs in the current installer could be avoided with a higher level
>   library.
> * As suggested by Ludo[1], using a network manager seems to be a better
>   idea that calling iw, ip and other low level tools.
> * I prefer relying on a Guile-parted library rather than calling cfdisk
>   and again interfacing with various partioning tools.
>
> While a lot of work have been accomplished by John and Danny, fixing the
> above issues mean rewrite it almost completely anyway.
>
> So, I wrote Guile bindings for newt[2], which can be found here[3]. Newt
> is the library used by Debian installer and the Anaconda installer
> (RedHat, Centos, ...).
>
> I choose to interface with Connman via connmanctl. It would have been
> better to use DBus but it implies writing Guile-dbus and I did not have
> the courage.
>
> Based on this, I have a first draft for a new installer here[4]. I plan
> to push it on a wip savannah branch soon. Most of the basic features are
> implemented and the last missing part it the partioning one (also the
> bigger ...).

Woow, that’s an impressive comeback!  :-)

The installer you wrote does seem to be much more compact that the one
John and Danny wrote, which seems to confirm your argument in favor of
Newt rather than Ncurses.

I really like the clean interfaces you can came up with for networking,
keymaps, timezones, etc.

For Connman, I wonder if we could talk directly to the daemon without
going through ‘connmanctl’ (which could perhaps provide tighter control
over error reports, etc.), but that’s a minor issue.

> I will soon share some iso files to have some feedbacks. Even if it
> might be too late already, I think that releasing the 1.0 with a
> graphical installer would be a big plus.

Definitely.  I’m really happy that you took a stab at this and I’m
looking forward to running test images!

BTW, if your bicycle trip stops by Paris, do not miss
<https://libreplanet.org/wiki/Group:Guix/ParisGathering2018>: you’d have
nice stories to tell us about.  :-)

Cheers,
Ludo’.

Re: Come back and graphical installer

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 16189 bytes --]

Hi,

On Sat, 20 Oct 2018 21:48:34 +0600
Mathieu Othacehe <m.othacehe@gmail.com> wrote:

> * Using Anaconda[1] as suggested by Harmut would mean interfacing a huge
>   codebase in Python, written for FHS based distributions.

I just want to throw this over the fence... *runs away*:

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Danny Milosavljevic <dannym@scratchpost.org>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (wip anaconda)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (guix utils)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system python)
  #:use-module (gnu packages)
  #:use-module (gnu packages admin)
  #:use-module (gnu packages autotools)
  #:use-module (gnu packages backup)
  #:use-module (gnu packages base)
  #:use-module (gnu packages check)
  #:use-module (gnu packages curl)
  #:use-module (gnu packages databases)
  #:use-module (gnu packages disk)
  #:use-module (gnu packages flex)
  #:use-module (gnu packages gettext)
  #:use-module (gnu packages glib)
  #:use-module (gnu packages gnome)
  #:use-module (gnu packages gnuzilla)
  #:use-module (gnu packages gtk)
  #:use-module (gnu packages linux)
  #:use-module (gnu packages nettle)
  #:use-module (gnu packages networking)
  #:use-module (gnu packages time)
  #:use-module (gnu packages package-management)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages popt)
  #:use-module (gnu packages python)
  #:use-module (gnu packages python-web)
  #:use-module (gnu packages selinux)
  #:use-module (gnu packages textutils)
  #:use-module (gnu packages tls)
  #:use-module (gnu packages xml)
  #:use-module (gnu packages xorg))

(define-public python-blivet
  (package
    (name "python-blivet")
    (version "0.61.15")
    (source (origin
              (method url-fetch)
              (uri
               (string-append
                "https://github.com/storaged-project/blivet/archive/blivet-"
                version ".tar.gz"))
              (sha256
               (base32
                "0j01wjb2drz1r9f4006xn0g9r7hiqm679diczi4z7hsh850v85f7"))))
    (build-system python-build-system)
    (home-page "https://fedoraproject.org/wiki/Blivet")
    (synopsis "Installer")
    (description "Installer.")
    (license license:gpl2))) ; FIXME

(define-public python2-blivet
  (package-with-python2 python-blivet))

(define-public python-ordered-set
(package
  (name "python-ordered-set")
  (version "2.0.2")
  (source
    (origin
      (method url-fetch)
      (uri (pypi-uri "ordered-set" version))
      (sha256
        (base32
          "1swh7b75qz9d2179z36ll4n41vf2b8wgngg9rgan01svgmfssb4l"))))
  (build-system python-build-system)
  (native-inputs
   `(("python-nose" ,python-nose)))
  (home-page "http://github.com/LuminosoInsight/ordered-set")
  (synopsis "MutableSet that remembers its order in Python")
  (description
    "A MutableSet that remembers its order, so that every entry has an index.")
  (license #f)))

(define-public python2-ordered-set
  (package-with-python2 python-ordered-set))

(define-public python-pykickstart
(package
  (name "python-pykickstart")
  (version "3.7")
  (source
    (origin
      (method url-fetch)
      (uri (pypi-uri "pykickstart" version))
      (sha256
        (base32
          "09fp4n8sz8xvcljhhs09w9m1gca0bbcxbcmyd0bdc9xxp0sy4576"))))
  (build-system python-build-system)
  (propagated-inputs
   `(("python-ordered-set" ,python-ordered-set)))
  (home-page
    "http://fedoraproject.org/wiki/pykickstart")
  (synopsis
    "Python module for manipulating kickstart files")
  (description
    "Python module for manipulating kickstart files")
  (license #f))) ; FIXME

(define-public python2-pykickstart
  (package-with-python2 python-pykickstart))

(define-public python-langtable
  (package
    (name "python-langtable")
    (version "0.0.38")
    (source (origin
              (method url-fetch)
              (uri
               (string-append "https://github.com/mike-fabian/langtable/archive/" version ".tar.gz"))
              (sha256
               (base32
                "00634x2hjrvf45a3wsjb38cni7rc2bdb39a86rvzyz8syv9igxy1"))))
    (build-system python-build-system)
    (home-page "https://fedoraproject.org/wiki/Anaconda")
    (synopsis "Langtable")
    (description "Langtable.")
    (license license:gpl3+))) ; FIXME and MIT

(define-public python2-langtable
  (package-with-python2 python-langtable))

;; FIXME make an independent package.
(define-public python2-selinux
  (package (inherit libselinux)
    (name "python2-selinux")
    (native-inputs
     (cons* `("flex" ,flex) `("python-2" ,python-2)
            (package-native-inputs libselinux)))
    (inputs
     `())
    (arguments
     (substitute-keyword-arguments (package-arguments libselinux)
       ((#:make-flags flags)
        `(cons* "PYTHON=python2"
                (string-append "LIBSEPOLA="
                              (assoc-ref %build-inputs "libsepol")
                              "/lib/libsepol.a")
                (string-append "PYSITEDIR="
                               (assoc-ref %outputs "out")
                               "/lib/python"
                               ,(version-major+minor (package-version python-2))
                               "/site-packages/")
                       (let ((out (assoc-ref %outputs "out")))
         (list (string-append "PREFIX=" out)
               (string-append "DESTDIR=" out)
               (string-append "MAN3DIR=" out "/share/man/man3")
               (string-append "MAN5DIR=" out "/share/man/man5")
               (string-append "MAN8DIR=" out "/share/man/man8")
               (string-append "LDFLAGS=-Wl,-rpath=" out "/lib")
               "CC=gcc"))
))))))

(define-public python-ntplib
(package
  (name "python-ntplib")
  (version "0.3.3")
  (source
    (origin
      (method url-fetch)
      (uri (pypi-uri "ntplib" version))
      (sha256
        (base32
          "1piy4x71lp6ra8vligcbh6zzn1mgnjh1p9yrkcflds8bsmj1nqn4"))))
  (build-system python-build-system)
  (home-page "http://code.google.com/p/ntplib/")
  (synopsis "NTP client library for Python")
  (description "This package provides an Network Time Protocol client.")
  (license license:expat)))

(define-public python2-ntplib
  (package-with-python2 python-ntplib))

(define-public python-urlgrabber
(package
  (name "python-urlgrabber")
  (version "3.10.2")
  (source
    (origin
      (method url-fetch)
      (uri (pypi-uri "urlgrabber" version))
      (sha256
        (base32
          "0w1h7hlsq406bxfy2pn4i9bd003bwl0q9b7p03z3g6yl0d21ddq5"))))
  (build-system python-build-system)
  (propagated-inputs
   `(("python2-pycurl" ,python2-pycurl)))
  (home-page "http://urlgrabber.baseurl.org/")
  (synopsis
    "A high-level cross-protocol url-grabber")
  (description
    "A high-level cross-protocol url-grabber")
  (license #f)))

(define-public python2-urlgrabber
  (package-with-python2 python-urlgrabber))

(define-public python-meh
  (package
    (name "python-meh")
    (version "1.2.1")
    (source
    (origin
      (method url-fetch)
      (uri (pypi-uri "Meh" version))
      (sha256
        (base32
          "0hwg3vqpiqb80ff7is3v202cz98b764nizlizpq9h2m2xn99vpf1"))))
    (build-system python-build-system)
    (arguments
     `(#:tests? #f))
    (home-page
      "https://github.com/PhilipTrauner/Meh")
    (synopsis
      "Python configuration files in Python.")
    (description
      "Python configuration files in Python.")
    (license #f)))

(define-public python2-meh
  (package-with-python2 python-meh))

(define-public python-rpmfluff
  (package
    (name "python-rpmfluff")
    (version "0.5.4")
    (source
    (origin
      (method url-fetch)
      (uri (string-append "https://releases.pagure.org/rpmfluff/rpmfluff-" version ".tar.xz"))
      (sha256
        (base32
          "16q38v575yn3m8nf417sfhnhfj856c1wxghhngkzlbcjqkv1lj90"))))
    (build-system python-build-system)
    (arguments
     `(#:tests? #f))
    (home-page
      "https://github.com/PhilipTrauner/Meh")
    (synopsis
      "Python configuration files in Python.")
    (description
      "Python configuration files in Python.")
    (license #f)))

(define-public python2-rpmfluff
  (package-with-python2 python-rpmfluff))

(define-public anaconda
  (package
    (name "anaconda")
    (version "21.48.22.133-1")
    (source (origin
              (method url-fetch)
              (uri
               (string-append "https://github.com/rhinstaller/anaconda/archive/"
                              name "-" version ".tar.gz"))
              (sha256
               (base32
                "186sp1j9n31r147nh2b5iv5sj22qmxbaz3p2lmsllanp42129akd"))))
    (build-system gnu-build-system)
    (arguments
     `(#:make-flags '("V=1")
       #:phases
       (modify-phases %standard-phases
        (add-before 'bootstrap 'patch-bootstrapper
          (lambda* (#:key inputs #:allow-other-keys)
            (substitute* "widgets/autogen.sh"
             (("/bin/bash") (which "bash"))
             (("/usr/share/gettext")
              (string-append (assoc-ref inputs "gettext") "/share/gettext")))
            #t))
        (add-after 'unpack 'patch-out-rpm
          (lambda _
            (substitute* "tests/glade/run_glade_tests.sh"
             ((" rpm -q ") " true "))
            #t))
        (add-after 'configure 'configure-widgets
          (lambda* (#:key outputs #:allow-other-keys)
            (chdir "widgets")
            (setenv "CONFIG_SHELL" (which "sh"))
            (invoke (which "sh") "./configure" (string-append "CONFIG_SHELL=" (which "sh"))
             (string-append "--prefix=" (assoc-ref outputs "out")))
            (chdir "..")
            #t))
        (add-after 'configure-widgets 'msginit
          (lambda* (#:key inputs #:allow-other-keys)
             (define (filter-environment! filter-predicate
                                          environment-variable-names)
               (for-each
                (lambda (env-name)
                  (let* ((env-value (getenv env-name))
                         (search-path (search-path-as-string->list env-value))
                         (new-search-path (filter filter-predicate
                                                  search-path))
                         (new-env-value (list->search-path-as-string
                                         new-search-path ":")))
                    (setenv env-name new-env-value)))
                environment-variable-names))
            (substitute* "utils/dd/Makefile"
             ;(("LDFLAGS =") (string-append "LDFLAGS=-Wl,-rpath=" (assoc-ref inputs "nss") "/lib/nss"))
             ;; It's using $(LDFLAGS) before setting LDFLAGS.
             (("[$][(]LDFLAGS[)]") (string-append "-R " (assoc-ref inputs "nss") "/lib/nss"
                                                  " -L" (assoc-ref inputs "nss") "/lib/nss")))
            (substitute* "tests/pylint/runpylint.sh"
             ((" /bin/sh ") " sh "))
            (substitute* "tests/pyanaconda_tests/iutil_test.py"
             (("\"/bin/sh\"") "\"sh\"")
             (("\"/bin/true\"") "\"true\"")
             (("\"/bin/echo\"") "\"echo\""))
            ;; Someone injects enum34 - and that's incompatible with Python3.6.
            (filter-environment! (lambda (name) (not (string-contains name "enum34"))) '("PYTHONPATH"))
            ;; FIXME: hardcode it in pyanaconda somehow.
            (setenv "TZDIR"
                     (string-append (assoc-ref inputs "tzdata")
                                    "/share/zoneinfo"))
            (chdir "po")
            ;; FIXME: Fetch those files.
            (for-each
              (lambda (x)
                (invoke "msginit" "--no-translator" "-o" x))
              '("af.po" "am.po" "ar.po" "as.po" "ast.po" "be.po" "bg.po" "bn.po" "bn_IN.po" "bs.po" "ca.po" "cs.po" "cy.po" "da.po" "de.po" "de_CH.po" "el.po" "en_GB.po" "es.po" "et.po" "eu.po" "fa.po" "fi.po" "fr.po" "gl.po" "gu.po" "hi.po" "hr.po" "hu.po" "ia.po" "id.po" "ilo.po" "is.po" "it.po" "ja.po" "ka.po" "kk.po" "kn.po" "ko.po" "lt.po" "lv.po" "ne.po" "nl.po" "nso.po" "or.po" "pa.po" "pl.po" "pt.po" "pt_BR.po" "ro.po" "ru.po" "si.po" "sk.po" "sl.po" "sq.po" "sr.po" "sr@latin.po" "sv.po" "ta.po" "te.po" "tg.po" "th.po" "tr.po" "uk.po" "ur.po" "vi.po" "zh_CN.po" "zh_TW.po" "zu.po" "mai.po" "mk.po" "mr.po" "ml.po" "mr.po" "ms.po" "nb.po"))
            (chdir "..")
            #t))
          (add-before 'check 'set-typelib-path
            (lambda* (#:key inputs #:allow-other-keys)
              (setenv "GI_TYPELIB_PATH" (string-append (assoc-ref inputs "gtk+") "/share/gir-1.0:"
                                        (string-append (assoc-ref inputs "network-manager") "/share/gir-1.0")))
              #t))
          (add-after 'install 'install-widgets
            (lambda _
              #t)))))
    (inputs
     `(("audit" ,audit)
       ("bdb" ,bdb)
       ("gettext" ,gettext-minimal) ; widgets
       ("glade3" ,glade3) ; widgets
       ("glib" ,glib)
       ("gtk+" ,gtk+) ; widgets
       ("gobject-introspection" ,gobject-introspection)
       ("libarchive" ,libarchive)
       ("libx11" ,libx11)
       ("libxklavier" ,libxklavier)
       ("libxml2" ,libxml2)
       ("nettle" ,nettle)
       ("network-manager" ,network-manager)
       ("nss" ,nss)
       ("popt" ,popt)
       ("python-2" ,python-2)
       ("tzdata" ,tzdata)
       ("rpm" ,rpm)))
    (propagated-inputs
     `(("python2-blivet" ,python2-blivet)
       ("python2-dbus" ,python2-dbus)
       ("python2-ipy" ,python2-ipy)
       ("python2-urlgrabber" ,python2-urlgrabber)
       ("python2-ntplib" ,python2-ntplib)
       ("python2-parted" ,python2-parted)
       ("python2-pytz" ,python2-pytz)
       ("python2-requests" ,python2-requests)
       ("python2-meh" ,python2-meh)
       ("libostree" ,libostree)
       ("python2-pygobject" ,python2-pygobject))) ; FIXME regular inputs.
    (native-inputs
     `(("autoconf" ,autoconf)
       ("automake" ,automake)
       ("gettext" ,gettext-minimal)
       ("glib-bin" ,glib "bin")
       ("gnome-icon-theme" ,gnome-icon-theme)
       ("gtk-doc" ,gtk-doc)
       ("intltool" ,intltool)
       ("libtool" ,libtool)
       ("pkg-config" ,pkg-config)
       ("python-2" ,python-2)
       ("python2-lxml" ,python2-lxml)
       ("python2-pylint" ,python2-pylint)
       ("python2-polib" ,python2-polib)
       ("python2-nose" ,python2-nose)
       ("python2-mock" ,python2-mock)
       ("python2-pykickstart" ,python2-pykickstart)
       ("python2-selinux" ,python2-selinux)
       ("python2-langtable" ,python2-langtable)
       ("python2-rpmfluff" ,python2-rpmfluff)
       ; FIXME add gi.repository: NetworkManager Gtk Gdk TimezoneMap Pango NMClient GdkPixbuf Keybinder AnacondaWidgets GdkX11 Xkl NM
       ("cppcheck" ,cppcheck)))
    (home-page "https://fedoraproject.org/wiki/Anaconda")
    (synopsis "Installer")
    (description "Installer.")
    (license license:gpl2)))

; libuser blivet.util pwquality[runpath problems]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Come back and graphical installer

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

Hi Mathieu,

welcome back!

> I picked up the "Graphical installer" task. After studying the branch
> wip-installer-2, I choose to rewrite it for multiple reasons:
> 
> * I found the guile-ncurses approach too low level and think that many
>   bugs in the current installer could be avoided with a higher level
>   library.

Yeah, it's also why I didn't really continue it except for finishing
what's already there.  It's just to low-level.

I mean it can be done the low-level way, but widget libraries are a solved
problem and the "redraw it only now" stuff is seriously 1980s.

> * As suggested by Ludo[1], using a network manager seems to be a better
>   idea that calling iw, ip and other low level tools.

I agree.  Note that back then network-manager was not used in guix.

> * I prefer relying on a Guile-parted library rather than calling cfdisk
>   and again interfacing with various partioning tools.

I agree.  I've been meaning to write parted bindings for guile, but
I got side-tracked with https://github.com/daym/guile-gcc-unit which
can extract prototypes out of gcc source files (in order to automate
wrapper generation).  Now I'm motivated to pick it up again.

Maybe I should just have written the bindings manually - I would have
been done a long time ago ;-)

> Based on this, I have a first draft for a new installer here[4]. I plan
> to push it on a wip savannah branch soon. Most of the basic features are
> implemented and the last missing part it the partioning one (also the
> bigger ...).

Cool!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Come back and graphical installer

[bill-auger]

FWIW, i will add that the bulk of effort required to have a pretty
user-friendly mouse-centric installer for guixsd is not with the
installer itself, but in making a liveISO that boots a graphical
environment - i would not consider ncurses to be "graphical" and most
casual users would not either - if non-technical people are ever going
to try guixsd, then a fully graphical liveISO X desktop environment
with a mouse-centric installer will be essential

i have experience with the calamares installer which is
very much a ready-made, modular, distro-agnostic solution - all that
would be required for calamares is to write a new module that scripts a
standard command line install procedure and everything else (the GUI,
partitioning, a pretty slideshow) is included for free and maintained
upstream - about a year ago i discussed this with rekado and offered
that i would be willing to adapt it for guix but it was seen then
(as it apparently still is now) to be low-priority, so i left it at that

Re: Come back and graphical installer

[bill-auger]

On Mon, 22 Oct 2018 22:47:29 -0400 bill-auger wrote:
> if non-technical people are ever going
> to try guixsd, then a fully graphical liveISO X desktop environment
> with a mouse-centric installer will be essential

i should qualify that statement as well to note that a graphical
package manager would be just as essential for non-technical users - if
there is not yet any graphical package manager, then there is little
need for a graphical installer either, as the distro is clearly
targeting only "power users" and very much excluding the largest
group of potential users which are not so comfortable on the command
line

Re: Come back and graphical installer

[Mathieu Othacehe]

Hi Ludo!

> Woow, that’s an impressive comeback!  :-)

Thank you :)

> BTW, if your bicycle trip stops by Paris, do not miss
> <https://libreplanet.org/wiki/Group:Guix/ParisGathering2018>: you’d have
> nice stories to tell us about.  :-)

Haha, it would have been with pleasure, but I'll still be in
Japan. However, I should be able to attend Fosdem this year!

Thanks,

Mathieu

Re: Come back and graphical installer

[Mathieu Othacehe]

Hey Danny,

> welcome back!

Thank you :)

> I agree.  I've been meaning to write parted bindings for guile, but
> I got side-tracked with https://github.com/daym/guile-gcc-unit which
> can extract prototypes out of gcc source files (in order to automate
> wrapper generation).  Now I'm motivated to pick it up again.

I was thinking of writing Guile FFI based bindings in the same spirit as
for Guile-git or Guile-newt. However, if we can write a nice higher
level abstraction above generated bindings, I guess it would be ok too.

Pyparted which was mainly written for Anaconda adopted the strategy of
exporting libparted functions in Python via 1:1 function mapping and
then writting a higher level abstraction built on that.

Anyway, your help would be much appreciated on this part that will be
the trickier :)

Thank you,

Mathieu

Re: Come back and graphical installer

[Björn Höfling]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Tue, 23 Oct 2018 12:39:54 +0900
Mathieu Othacehe <m.othacehe@gmail.com> wrote:

> Hi Ludo!
> 
> > Woow, that’s an impressive comeback!  :-)  
> 
> Thank you :)
> 
> > BTW, if your bicycle trip stops by Paris, do not miss
> > <https://libreplanet.org/wiki/Group:Guix/ParisGathering2018>: you’d
> > have nice stories to tell us about.  :-)  
> 
> Haha, it would have been with pleasure, but I'll still be in
> Japan. However, I should be able to attend Fosdem this year!

I would doubt that. But would be nice to see you in the beginning of
2019 :-)

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Come back and graphical installer

[Ludovic Courtès]

Hello Danny!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I agree.  I've been meaning to write parted bindings for guile, but
> I got side-tracked with https://github.com/daym/guile-gcc-unit which
> can extract prototypes out of gcc source files (in order to automate
> wrapper generation).  Now I'm motivated to pick it up again.

Fun, and an interesting approach!

In a similar vein, did you read about Matt Wette’s “FFI helper” that
comes with Nyacc?  It shares the same goal of automatic generation of
Guile bindings and apparently it works well enough that Matt has been
able to use it for pretty large and non-trivial libraries.

> Maybe I should just have written the bindings manually - I would have
> been done a long time ago ;-)

Heheh, talk about shaving yaks.  :-)

Personally I’m not entirely sure automatic binding generation is worth
the effort in general, because “good” bindings necessarily require
manual intervention, at least to provide an API that meshes well with
the target language and its conventions.

Parted has a streamlined consistent object-oriented API, so I think it
Shouldn’t Be Hard (ah ha!) to write bindings, with or without automatic
generation tools.

Ludo’.

Re: Come back and graphical installer

[Mathieu Othacehe]

Hello,

I updated the wip-newt-installer, with a first testable version of the
installer. As it requires to rebuild the world and it is not built by
berlin yet, here's an iso version of the installer.

https://drive.google.com/file/d/1OoVhlok1QMRcItwGBZfYn8Ocma-h2oGL/view?usp=sharing

It can be tested with Qemu with the command line:

qemu-system-x86_64 -m 1024 -smp 1 -boot menu=on -drive file=<iso-path> -vga std

Or, on a real hardware, for the bravest :p

Note that remains to be done:
* The partitioning page
* The page to select a desktop environment (gnome, xfce, ...)
* The final step of system reconfiguration

Since my last email, I also added an abstraction layout (in the
gnu/bootloader.scm idea), so that if we want to add a new (gtk3?)
installer in the future, we can still use the same grounds.

I feel that now is a good time to gather remarks/ideas/patches before
diving into the last part. Plus, I'm terrible UI design so any help
tuning logo, colors and button placement would be much appreciated :)

Thanks,

Mathieu

Re: Come back and graphical installer

[Ludovic Courtès]

Hello!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> I updated the wip-newt-installer, with a first testable version of the
> installer. As it requires to rebuild the world and it is not built by
> berlin yet, here's an iso version of the installer.
>
> https://drive.google.com/file/d/1OoVhlok1QMRcItwGBZfYn8Ocma-h2oGL/view?usp=sharing

Arf, sorry we haven’t set up berlin yet.  Now there’s no risk of having
a disk space shortage there so we should really do it.

Now, is the full rebuild caused by the installation of the
i18n/SUPPORTED file in the glibc package?

If the answer is yes, what about creating a separate package (or simply
a ‘computed-file’) that would contain nothing but that file?  That would
allow us to avoid the full rebuild this time, and thus we could push the
new interface out sooner.  (Also, we wouldn’t have to connect to Google
Drive.  :-))

WDYT?

> Since my last email, I also added an abstraction layout (in the
> gnu/bootloader.scm idea), so that if we want to add a new (gtk3?)
> installer in the future, we can still use the same grounds.

Sounds really nice!

> I feel that now is a good time to gather remarks/ideas/patches before
> diving into the last part. Plus, I'm terrible UI design so any help
> tuning logo, colors and button placement would be much appreciated :)

Minor issue: I think ‘configure.ac’ should not abort when Newt is
missing; in general, I think we’ll want to build Guix without Newt and
without building the installer.  Likewise, in (guix self), we should
create a special “node” containing (gnu installer …) and arrange so that
it’s not compiled; it makes no sense to have it compiled here, except
for testing.

WDYT?

Thank you!

Ludo’, who’d like to give it a try soon!

Re: Come back and graphical installer

[Mathieu Othacehe]

Hello,

> Now, is the full rebuild caused by the installation of the
> i18n/SUPPORTED file in the glibc package?

Yes.

>
> If the answer is yes, what about creating a separate package (or simply
> a ‘computed-file’) that would contain nothing but that file?  That would
> allow us to avoid the full rebuild this time, and thus we could push the
> new interface out sooner.  (Also, we wouldn’t have to connect to Google
> Drive.  :-))
>
> WDYT?

Done, I re-created wip-newt-installer without the glibc patch
dependency, it can now be built much faster :)

For people not used to create disk-images, the commands I use are:

./pre-inst-env guix system disk-image gnu/system/install.scm
-> /gnu/store/xxx-disk-image

sudo cp /gnu/store/xxx-disk-image /tmp/iso
sudo chmod o+rw /tmp/iso
qemu-system-x86_64 -m 1024 -smp 1   -net user -net nic,model=virtio -boot menu=on   -drive file=/tmp/iso -vga std

> Minor issue: I think ‘configure.ac’ should not abort when Newt is
> missing; in general, I think we’ll want to build Guix without Newt and
> without building the installer.  Likewise, in (guix self), we should
> create a special “node” containing (gnu installer …) and arrange so that
> it’s not compiled; it makes no sense to have it compiled here, except
> for testing.
>
> WDYT?

Yes, it makes sense, I'll remove this dependency.

Thanks for your fast answer :),

Mathieu

Re: Come back and graphical installer

[Mathieu Othacehe]

Hey,

Thanks for trying to test :)

> "ERROR: In procedure scm-error:
> no code for module (gnu installer keymap)"

Was it with the iso-image from google-drive or did you build the
installer from wip-installer-branch ?

Mathieu

Re: Come back and graphical installer

[L p R n d n]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]


Hello,

Tryed to test the installer this morning, like instructed in Matthieu's
message but I'm getting an error.
The message is cycling (showing/unshowing) so here are the last lines.

"ERROR: In procedure scm-error:
no code for module (gnu installer keymap)"

Couldn't interact with the vm so I join a *nicely* timed screenshot
whit the full error.

Lprndn


[-- Attachment #2: 2018-11-17 13-24-25.png --]
[-- Type: image/png, Size: 80065 bytes --]

Re: Come back and graphical installer

[Mathieu Othacehe]

> I built the disk image from the wip-newt-installer branch.

Ok so could you run:

guix gc -R /gnu/store/xxx-your-disk-image | grep installer

It should return you the installer script in store
(/gnu/store/xxx-installer). Replying to this email with this file in
attachment would maybe help me understand what's going wrong.

Thanks,

Mathieu

Re: Come back and graphical installer

[L p R n d n]

Hey,

I built the disk image from the wip-newt-installer branch.

Lprndn

Re: Come back and graphical installer

[Mathieu Othacehe]

> Here it is!

Thanks, it seems pretty ok. One last request, could you execute those
two commands and send me the result?

tree /gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import
tree /gnu/store/g967vsq3dix4w5zjhpcp9p4f30hcmnsm-module-import-compiled 

Sorry for the hassle,

Mathieu

Re: Come back and graphical installer

[L p R n d n]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Mathieu Othacehe <m.othacehe@gmail.com> writes:

>> I built the disk image from the wip-newt-installer branch.
>
> Ok so could you run:
>
> guix gc -R /gnu/store/xxx-your-disk-image | grep installer
>
> It should return you the installer script in store
> (/gnu/store/xxx-installer). Replying to this email with this file in
> attachment would maybe help me understand what's going wrong.
>
> Thanks,
>
> Mathieu

Here it is!

Thanks,

Lprndn

[-- Attachment #2: installer --]
[-- Type: application/octet-stream, Size: 4302 bytes --]

#!/gnu/store/1mr5izrbxwd7cbq8m1xrqm45rzkibpsj-guile-2.2.3/bin/guile --no-auto-compile
!#
(eval-when (expand load eval) (set! %load-path (cons "/gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import" (append (map (lambda (extension) (string-append extension "/share/guile/site/" (effective-version))) (quote ("/gnu/store/qbzw2ygy1nq2h0nq6sl9cgg1c5mq5g8z-guile-gcrypt-0.1.0" "/gnu/store/dks0d1f20n2md5vww523g5f14z5nxlc0-guile-newt-0-3.f19b02d12" "/gnu/store/sw3wxk3ylxd1kc2z4z4kb5191x9pf17n-guile-json-1.2.0"))) %load-path))) (set! %load-compiled-path (cons "/gnu/store/g967vsq3dix4w5zjhpcp9p4f30hcmnsm-module-import-compiled" (append (map (lambda (extension) (string-append extension "/lib/guile/" (effective-version) "/site-ccache")) (quote ("/gnu/store/qbzw2ygy1nq2h0nq6sl9cgg1c5mq5g8z-guile-gcrypt-0.1.0" "/gnu/store/dks0d1f20n2md5vww523g5f14z5nxlc0-guile-newt-0-3.f19b02d12" "/gnu/store/sw3wxk3ylxd1kc2z4z4kb5191x9pf17n-guile-json-1.2.0"))) %load-compiled-path))))(begin (use-modules (gnu installer keymap) (gnu installer steps) (gnu installer locale) (newt) (gnu installer newt page) (gnu installer newt utils) (gnu installer newt wifi) (guix i18n) (guix build utils) (ice-9 match)) (begin (bindtextdomain "guix" (string-append "/gnu/store/v5lad91n9wsnxqfqdy76mmsjc1fm8v0c-guix-0.15.0-7.f5a2724" "/share/locale")) (textdomain "guix")) (let* ((inputs (quote ("/gnu/store/q4b3s9y4i0da36drp7zfq9yqcf43s47v-bash-4.4.19" "/gnu/store/vjmmcq0s5z7s0pgdcw6p3gfn0a8a5fl6-connman-1.36" "/gnu/store/1g9r9lk412srqwggv1wv33j4fby7jpg1-shadow-4.6" "/gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29")))) (with-output-to-port (%make-void-port "w") (lambda () (set-path-environment-variable "PATH" (quote ("bin" "sbin")) inputs)))) (begin (newt-init) (clear-screen) (set-screen-size!)) (catch #t (lambda () (run-installer-steps #:rewind-strategy (quote menu) #:menu-proc (lambda (steps) (run-menu-page steps)) #:steps (list (installer-step (id (quote welcome)) (compute (lambda _ (run-welcome-page "/gnu/store/36h59r4pb7nw3wk9k0ipar3hgf3cqlnx-logo.txt")))) (installer-step (id (quote locale)) (description (G_ "Locale selection")) (compute (lambda _ (let ((result ((lambda* (#:key supported-locales iso639-languages iso3166-territories) (run-locale-page #:supported-locales supported-locales #:iso639-languages iso639-languages #:iso3166-territories iso3166-territories)) #:supported-locales (load-compiled (string-append "/gnu/store/lbxg6l6yj6xh7yr1avlja1mm9lpxsf34-locales" "/" "locales" ".go")) #:iso639-languages (load-compiled (string-append "/gnu/store/rn3vhgkbr132xs4vpwm6pxp0p2i51rl0-iso639-languages" "/" "iso639-languages" ".go")) #:iso3166-territories (load-compiled (string-append "/gnu/store/s3vazy50fvc1r24lcfi0cssy70zamibf-iso3166-territories" "/" "iso3166-territories" ".go"))))) ((lambda (locale-name) (false-if-exception (setlocale LC_ALL locale-name))) result))))) (installer-step (id (quote timezone)) (description (G_ "Timezone selection")) (compute (lambda _ ((lambda* (zonetab) (run-timezone-page zonetab)) (string-append "/gnu/store/2b2md66fbzyspsmd5dj6zkj9hilac40r-tzdata-2018e" "/share/zoneinfo/zone.tab"))))) (installer-step (id (quote keymap)) (description (G_ "Keyboard mapping selection")) (compute (lambda _ (let ((result (call-with-values (lambda () (xkb-rules->models+layouts (string-append "/gnu/store/ypc2xp67lxc1hpznajcpcwzqb4pw9p1v-xkeyboard-config-2.23.1" "/share/X11/xkb/rules/base.xml"))) (lambda (models layouts) ((lambda* (#:key models layouts) (run-keymap-page #:models models #:layouts layouts)) #:models models #:layouts layouts))))) ((match-lambda ((model layout variant) (kmscon-update-keymap model layout variant))) result))))) (installer-step (id (quote hostname)) (description (G_ "Hostname selection")) (compute (lambda _ (run-hostname-page)))) (installer-step (id (quote network)) (description (G_ "Network selection")) (compute (lambda _ (run-network-page)))) (installer-step (id (quote hostname)) (description (G_ "User selection")) (compute (lambda _ (run-user-page))))))) (const #f) (lambda (key . args) ((lambda (key args) (newt-finish)) key args) (call-with-output-file "/tmp/error" (lambda (port) (display-backtrace (make-stack #t) port) (print-exception port (stack-ref (make-stack #t) 1) key args))) (primitive-exit 1))) (begin (newt-finish)))

Re: Come back and graphical installer

[L p R n d n]

No problem. ;)

Here they are:

/gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import
├── gnu
│   └── installer
│       ├── connman.scm
│       ├── newt
│       │   ├── page.scm
│       │   ├── utils.scm
│       │   └── wifi.scm
│       ├── steps.scm
│       └── utils.scm
└── guix
    ├── build
    │   └── utils.scm
    ├── config.scm
    ├── i18n.scm
    └── records.scm

5 directories, 10 files

and

/gnu/store/g967vsq3dix4w5zjhpcp9p4f30hcmnsm-module-import-compiled
├── gnu
│   └── installer
│       ├── connman.go
│       ├── newt
│       │   ├── page.go
│       │   ├── utils.go
│       │   └── wifi.go
│       ├── steps.go
│       └── utils.go
└── guix
    ├── build
    │   └── utils.go
    ├── config.go
    ├── i18n.go
    └── records.go

5 directories, 10 files

Lprndn

Re: Come back and graphical installer

[Mathieu Othacehe]

Hey,

> Here they are:
>
> /gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import
> ├── gnu
> │ └── installer

Ok, so its where the problem is, somehow scheme-modules in the 'modules'
procedure of (gnu installer newt) fails to load most of the modules. I
don't really understand why, plus I can't reproduce it :(

I replaced scheme-modules -> scheme-modules* in 0c4dcc187. If you could
fetch the branch and try to build a new disk-image, it would be great!

Thanks in advance,

Mathieu

Re: Come back and graphical installer

[swedebugia]

On 2018-11-18 04:21, Mathieu Othacehe wrote:
> 
> Hey,
> 
>> Here they are:
>>
>> /gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import
>> ├── gnu
>> │ └── installer
> 
> Ok, so its where the problem is, somehow scheme-modules in the 'modules'
> procedure of (gnu installer newt) fails to load most of the modules. I
> don't really understand why, plus I can't reproduce it :(
> 
> I replaced scheme-modules -> scheme-modules* in 0c4dcc187. If you could
> fetch the branch and try to build a new disk-image, it would be great!
> 

It works now :)
Congratulations!

Took half an hour to build (in guixsd guest in qemu on a 2ghz machine 
using 1 cpu)

-- 
Cheers Swedebugia

Re: Come back and graphical installer

[Thorsten Wilms]

Hi Guix!

On 16/11/2018 14.20, Mathieu Othacehe wrote:
> I feel that now is a good time to gather remarks/ideas/patches before
> diving into the last part. Plus, I'm terrible UI design so any help
> tuning logo, colors and button placement would be much appreciated :)

Ah, this reminds me of 2007, when I worked my way through Ubuntu's 
installation and made a presentation about issues and suggestions with a 
few mockups.

I know what's there right now didn't fall from the sky and there's 
effort to every little change. If any of the following reads like a 
demand or demanding to you, please be assured that I just tried to get 
straight to the point in what essentially are just suggestions.


Dialog buttons:

Note that I come to this textmode interface with expectations and habits 
shaped by graphical interfaces. That will be true of other users, too, 
though.

There is "Cancel", but no "Select"/"OK"/"Forward", not even a hint like 
"Press Enter to select". "Cancel Installation" would be clearer, but 
maybe a bit long. Maybe "Exit"?

There should be a "Back" button (bound to left-arrow and maybe also 
Escape). Having a "Back" button would also emphasize that "Cancel" is 
not just that.

Dialog buttons should be right-aligned, with [ Cancel | OK/default ] 
order (GNOME and Apple style).


"Language selection":

Lists like this are so much nicer to use if you know that you can type a 
letter to jump to the first item that starts with it. In this sense, a 
hint about this feature would be great, though it's tricky to explain 
this short and clear enough.

Would it be feasible to change this to a completion-list instead of 
working on initials only?

"English" should probably be preselected. As odd as the list scrolled 
down a good bit right from the start may look, this is the one choice 
that may speed things up for the largest group of users. Unlike "Afar".

Is it possible to detect the BIOS language settings? Any other way to 
make an informed guess?

Language names should be localized, e.g. "Deutsch" instead of "German". 
There may be issues regarding character set and list navigation, though.


"Location selection":

A shortlist based on language selection is not acceptable. You just made 
me relocate to the United Kingdom as nearest choice ;)


"Code selection":

A few more words what this is about should help, assuming Guix is meant 
to reach less technical users (at some point).


"Timezone selection":

This should happen after Location selection. The text should explain 
that selection happens in 2 steps, via a region, then a city. Along the 
lines of: "First select a region, then a city (next page), to set a 
timezone".

It may be better to use one list of timezones, each with the UTC offset, 
followed by a list of major cities.


"Keyboard model selection":

Hmm, Ubuntu's graphical installer gets away with just layout and 
variant, no mention of model. Some graphical installers have a test box 
and/or a detection scheme (asking the user to press certain keys).


"Technology selection":

Should be "Internet access". It seems like with "technology" a bit of 
the implementation language slipped through?


"User selection":

This could start right in "User creation" for the first, required user. 
Actually, I wonder if the installer should even offer creation of 
several users? In general, don't do what can easily be done after 
installation.


Consider to leave "selection" out of all page titles.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Come back and graphical installer

[swedebugia]

Hi

On 2018-11-18 20:43, Thorsten Wilms wrote:

snip

+1 to all Thorstens suggestions.

In addition I was reminded of the debian installer. Could we change the 
colors from blue/red to something more outstanding? black/yellow? :)

GuixSD really stands out to me so having the colors reflect this would 
be nice :)

-- 
Cheers Swedebugia

Re: Come back and graphical installer

[Ludovic Courtès]

Hi Mathieu,

I gave the installer a try in ‘guix system vm’ from commit
2bc8f10a35f24ecfa9f0be6b1e26b4f7af0a275c: impressive piece of work!

I agree with most of Thorsten’s suggestions, but I think we can address
them incrementally.  It’s already nice IMO.

In ‘guix system vm’ the process stopped after trying to use “wired”
network.  At that point I realized I couldn’t switch to other VCs using
Alt-F2 & co.  Is that something specific to kmscon?  Anything we can do
about it?

I think it’d be nice to have the new installer UI on tty1 and yet be
able to just switch to root terminals or the manual on the other VCs.

Thank you!

Ludo’.

Re: Come back and graphical installer

[Mathieu Othacehe]

Hi Thorsten,

> I know what's there right now didn't fall from the sky and there's
> effort to every little change. If any of the following reads like a
> demand or demanding to you, please be assured that I just tried to get
> straight to the point in what essentially are just suggestions.

Thanks a lot taking the time to test the installer and writting down all
those suggestions. Most of them are reasonable, some are made difficult
by technical limitations, but I'll discuss them one by one below.

> There is "Cancel", but no "Select"/"OK"/"Forward", not even a hint
> like "Press Enter to select". "Cancel Installation" would be clearer,
> but maybe a bit long. Maybe "Exit"?

The newt API offers one "help-line" at the bottom of the screen for a
help text. It might be the place to indicate that <Enter> selects.

>
> There should be a "Back" button (bound to left-arrow and maybe also
> Escape). Having a "Back" button would also emphasize that "Cancel" is
> not just that.

Ok adding a "Back" button and turning "Cancel" into "Exit" seams like a
good idea.

> Lists like this are so much nicer to use if you know that you can type
> a letter to jump to the first item that starts with it. In this sense,
> a hint about this feature would be great, though it's tricky to
> explain this short and clear enough.
>
> Would it be feasible to change this to a completion-list instead of
> working on initials only?

You're right, the "initial jump" feature has to be advertised. About the
"completion-list" it would be great but it requires a patch to newt
library that is not trivial.

>
> "English" should probably be preselected. As odd as the list scrolled
> down a good bit right from the start may look, this is the one choice
> that may speed things up for the largest group of users. Unlike
> "Afar".

Sure!

> Is it possible to detect the BIOS language settings? Any other way to
> make an informed guess?

I'm not aware of such a possibility I agree it would be nice.

>
> Language names should be localized, e.g. "Deutsch" instead of
> "German". There may be issues regarding character set and list
> navigation, though.

I took the language name from the ISO639 standard where it is not
localized. However, I see that Wikipedia has an ISO language <-> Native
name (endonym) correspondance. Maybe we could copy this table somewhere
and display language endonyms (or both like the Debian installer)?

> "Location selection":
>
> A shortlist based on language selection is not acceptable. You just
> made me relocate to the United Kingdom as nearest choice ;)

Aha sadly, the glibc only has a small subset of supported locales. If
you speak Dutch, only those locales are supported:

nl_AW UTF-8
nl_BE.UTF-8 UTF-8
nl_BE ISO-8859-1
nl_BE@euro ISO-8859-15
nl_NL.UTF-8 UTF-8
nl_NL ISO-8859-1
nl_NL@euro ISO-8859-15

Which means you can not select a "territory" different from Aruba,
Belgium or Nederlands. I'm not sure how to overcome this, maybe an
explicative text, what do you think?

> "Code selection":
>
> A few more words what this is about should help, assuming Guix is
> meant to reach less technical users (at some point).
>

Ok!

> "Timezone selection":
>
> This should happen after Location selection. The text should explain
> that selection happens in 2 steps, via a region, then a city. Along
> the lines of: "First select a region, then a city (next page), to set
> a timezone".
>
> It may be better to use one list of timezones, each with the UTC
> offset, followed by a list of major cities.

Even though it is harder to implement, it would be better I agree. The
tricky part is to gather a list of cities representing the timezone.

>
> "Keyboard model selection":
>
> Hmm, Ubuntu's graphical installer gets away with just layout and
> variant, no mention of model. Some graphical installers have a test
> box and/or a detection scheme (asking the user to press certain keys).

Well now "pc105" is the standard and other models are mostly relics from
the past. I think I'll just assume the model to be pc105 and let user
select a layout and variant then.

>
>
> "Technology selection":
>
> Should be "Internet access". It seems like with "technology" a bit of
> the implementation language slipped through?

You're right ;) I'll rename it.

> "User selection":
>
> This could start right in "User creation" for the first, required
> user. Actually, I wonder if the installer should even offer creation
> of several users? In general, don't do what can easily be done after
> installation.

Well I was hesitating too as multiple user adds complexity to the
form. What do other people think, one or multiple users selection :)?

>
>
> Consider to leave "selection" out of all page titles.

Ok.

Thanks again for your suggestions, it is really appreciated!

Mathieu

Re: Come back and graphical installer

[Mathieu Othacehe]

Hi swedebugia,

Thanks for your feedback.

> In addition I was reminded of the debian installer. Could we change
> the colors from blue/red to something more outstanding? black/yellow?
> :)

Yes I use the same library (newt) so the look is really close. Yes it is
totally possible to customize colors for most elements. But as I said
before, I'm terrible at this little game so I'll pass, but you're very
welcome to give it a try :)

Mathieu

Re: Come back and graphical installer

[Mathieu Othacehe]

Hi Ludo,

> I gave the installer a try in ‘guix system vm’ from commit
> 2bc8f10a35f24ecfa9f0be6b1e26b4f7af0a275c: impressive piece of work!

Thanks a lot :)

> In ‘guix system vm’ the process stopped after trying to use “wired”
> network.  At that point I realized I couldn’t switch to other VCs using
> Alt-F2 & co.  Is that something specific to kmscon?  Anything we can do
> about it?

It might be a bug because the last step is supposed to be "User
selection". Currently after this step, the program exits and is
restarted (as the installer is the shell of the root process).

For me it is possible to switch tty with ctrl-alt-fx on real hardware
and with alt-f2, sendctrlkey ctrl-alt-fx on Qemu. However, besides tty2
which I kept as documentation, other tty are also root kmscon terminals
spawning the installer.

>
> I think it’d be nice to have the new installer UI on tty1 and yet be
> able to just switch to root terminals or the manual on the other VCs.

You mean, switching from

tty1: installer
tty2: documentation
tty3-6: installer

to,

tty1: installer
tty2: documentation
tty3-6: plain root terminals

right?

That would require to find a new solution to spawn the installer on
tty1. I tried the 'login-program' way but I don't like it because the
installer does not have access to PAM env variables. Any other idea?

Thanks for your feedback :)

Mathieu

Re: Come back and graphical installer

[Thorsten Wilms]

On 19/11/2018 03.10, Mathieu Othacehe wrote:

> The newt API offers one "help-line" at the bottom of the screen for a
> help text. It might be the place to indicate that <Enter> selects.

Some graphical interface dialogs put emphasis on the button that is 
currently bound to Enter, but this convention isn't followed everywhere 
and there are probably many users being unaware. Since long ago I have 
been thinking that actually drawing a enter-key-icon in the button might 
be an improvement. Since we don't have such options here, "Press Enter 
to select and continue" should do.


> You're right, the "initial jump" feature has to be advertised. About the
> "completion-list" it would be great but it requires a patch to newt
> library that is not trivial.

As expected. I always look for ways to improve the user experience, but 
since this would only help some users once in a while, it may not be 
worth your time.


>> Is it possible to detect the BIOS language settings? Any other way to
>> make an informed guess?
> 
> I'm not aware of such a possibility I agree it would be nice.

All a quick search brought up is dmidecode:

$: sudo dmidecode --type 13
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.

Handle 0x0030, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Abbreviated
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1


dmidecode reads the information provided by the Linux kernel, which 
contains a SMBIOS decoder. I guess most systems are never configured 
away from a default en|US, anyway ...


>> Language names should be localized, e.g. "Deutsch" instead of
>> "German". There may be issues regarding character set and list
>> navigation, though.
> 
> I took the language name from the ISO639 standard where it is not
> localized. However, I see that Wikipedia has an ISO language <-> Native
> name (endonym) correspondance. Maybe we could copy this table somewhere
> and display language endonyms (or both like the Debian installer)?

Looks like the Fedora installer does that, too:
https://www.linuxtechi.com/wp-content/uploads/2014/12/select-installation-fedora-21.jpg

Either installer source might include a hint where the data comes from?


>> "Location selection":
>>
>> A shortlist based on language selection is not acceptable. You just
>> made me relocate to the United Kingdom as nearest choice ;)
> 
> Aha sadly, the glibc only has a small subset of supported locales. If
> you speak Dutch, only those locales are supported:
> 
> nl_AW UTF-8
> nl_BE.UTF-8 UTF-8
> nl_BE ISO-8859-1
> nl_BE@euro ISO-8859-15
> nl_NL.UTF-8 UTF-8
> nl_NL ISO-8859-1
> nl_NL@euro ISO-8859-15
> 
> Which means you can not select a "territory" different from Aruba,
> Belgium or Nederlands. I'm not sure how to overcome this, maybe an
> explicative text, what do you think?

There was a misunderstanding here, of which I think it may happen to 
others, too. I took this in the sense of "where am I", not "which 
locale", though with a bit more thinking, I should have made the 
connection! Presented with anything of the pattern as exemplified in 
"nl_NL.UTF-8 UTF-8", or the keyword "locale", I would have known.

For less informed users, we may want to explain the implications in 
short, but still correct, fashion. Something like "Please Select a 
locale. This is a regional variant of your language, encompassing 
number, date and currency format, among other details.". (I'm not too 
happy about "regional variant".)

https://en.wikipedia.org/wiki/Locale_(computer_software)

BTW, if the installer doesn't have translations for all languages that 
Guix can be installed with, language selection will have to be split up, 
installer and system.


>> "Timezone selection":

>> It may be better to use one list of timezones, each with the UTC
>> offset, followed by a list of major cities.
> 
> Even though it is harder to implement, it would be better I agree. The
> tricky part is to gather a list of cities representing the timezone.

Best I found is
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Though I wouldn't know how to "fold" that list.

Here's how it's done for tzdata, with pretty good language:
https://www.digitalocean.com/community/tutorials/additional-recommended-steps-for-new-ubuntu-14-04-servers#configure-timezones-and-network-time-protocol-synchronization


> Thanks again for your suggestions, it is really appreciated!

I'm happy to help!


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Come back and graphical installer

[Ludovic Courtès]

Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> In ‘guix system vm’ the process stopped after trying to use “wired”
>> network.  At that point I realized I couldn’t switch to other VCs using
>> Alt-F2 & co.  Is that something specific to kmscon?  Anything we can do
>> about it?
>
> It might be a bug because the last step is supposed to be "User
> selection". Currently after this step, the program exits and is
> restarted (as the installer is the shell of the root process).
>
> For me it is possible to switch tty with ctrl-alt-fx on real hardware
> and with alt-f2, sendctrlkey ctrl-alt-fx on Qemu. However, besides tty2
> which I kept as documentation, other tty are also root kmscon terminals
> spawning the installer.

Oh indeed, it’s ctrl-alt instead of alt.  Perhaps this should be written
on the welcome page of the installer?

>> I think it’d be nice to have the new installer UI on tty1 and yet be
>> able to just switch to root terminals or the manual on the other VCs.
>
> You mean, switching from
>
> tty1: installer
> tty2: documentation
> tty3-6: installer
>
> to,
>
> tty1: installer
> tty2: documentation
> tty3-6: plain root terminals
>
> right?

Right.

> That would require to find a new solution to spawn the installer on
> tty1. I tried the 'login-program' way but I don't like it because the
> installer does not have access to PAM env variables. Any other idea?

I was going to suggest the ‘login-program’ way.  :-)  What’s the story
with PAM env variables?

Thanks,
Ludo’.

Re: Come back and graphical installer

[Mathieu Othacehe]

Hey,

> Oh indeed, it’s ctrl-alt instead of alt.  Perhaps this should be written
> on the welcome page of the installer?

Yes, I'll add it!

> I was going to suggest the ‘login-program’ way.  :-)  What’s the story
> with PAM env variables?

The LANG env variable is important so that the installer can install the
right locale at start. However, it is not available yet when using
login-program. Any idea how to overcome this?

Thanks,

Mathieu

Re: Come back and graphical installer

[swedebugia]

Hi :)

On 2018-11-19 03:10, Mathieu Othacehe wrote:
> 
> Hi Thorsten,

snip

>>
>> "Keyboard model selection":
>>
>> Hmm, Ubuntu's graphical installer gets away with just layout and
>> variant, no mention of model. Some graphical installers have a test
>> box and/or a detection scheme (asking the user to press certain keys).
> 
> Well now "pc105" is the standard and other models are mostly relics from
> the past. I think I'll just assume the model to be pc105 and let user
> select a layout and variant then.

Sounds good. The manual install is for all the special weird cases.

snip

> 
>> "User selection":
>>
>> This could start right in "User creation" for the first, required
>> user. Actually, I wonder if the installer should even offer creation
>> of several users? In general, don't do what can easily be done after
>> installation.
> 
> Well I was hesitating too as multiple user adds complexity to the
> form. What do other people think, one or multiple users selection :)?

Single user is preferred.
You can hide al the group name and stuff too and just focus on the username.

Ubuntu makes it possible to choose a hostname. I never used that to 
anything so I would just set it to the username or just "guixsd".

-- 
Cheers Swedebugia

Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> I was going to suggest the ‘login-program’ way.  :-)  What’s the story
>> with PAM env variables?
>
> The LANG env variable is important so that the installer can install the
> right locale at start. However, it is not available yet when using
> login-program. Any idea how to overcome this?

If you add it to /etc/environment (through
‘session-environment-service-type’) it should be fine no?

I’d like to make a release within 10 days, meaning ‘core-updates’ is
merged by then.

Do we go ahead and use the installer in the image as well?  That would
get real-world testing.  The conditions for this IMO would be that:

  1. ./configure and (guix self) are adjusted to not build the
     installer, at least by default.

  2. The “old” installation method remains prominently available, either
     by making it clear people can use ctrl-alt-f2 & co. to switch to a
     terminal, and maybe adding a message on the welcome page stating
     that the installer is “beta” or something.

  3. The manual is updated to at least mention the new installer, maybe
     not in detail.

How does that sound?

It seems to me that it’s OK to push it quickly because it looks pretty
good already and if it happens to be buggy, people can always use the
old method.

WDYT?

Thanks,
Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey Ludo,

> If you add it to /etc/environment (through
> ‘session-environment-service-type’) it should be fine no?

LANG is already part of /etc/environment variables which are loaded by
the login program which is PAM aware. The installer isn't PAM aware and
it replaces the login program thus LANG is never loaded.

>   1. ./configure and (guix self) are adjusted to not build the
>      installer, at least by default.
>
>   2. The “old” installation method remains prominently available, either
>      by making it clear people can use ctrl-alt-f2 & co. to switch to a
>      terminal, and maybe adding a message on the welcome page stating
>      that the installer is “beta” or something.
>
>   3. The manual is updated to at least mention the new installer, maybe
>      not in detail.
>
> How does that sound?

I agree it would be great :), I'm currently focusing on parted support
but, I'll shift to the 3 points you described above so that it can be
merged on time.

> It seems to me that it’s OK to push it quickly because it looks pretty
> good already and if it happens to be buggy, people can always use the
> old method.

Sure, it is a big addition to the codebase, so its important people can
start debugging it as soon as possible.

Mathieu

Re: Come back and graphical installer

[L p R n d n]

Hello,

Sorry for the late answer. I can confirm it works for me too. ;)
I won't add any suggestions for now. Thorsten already did a great job.
(Replacing the Guix logo by the GuixSD one could be nice tho. To avoid
propagating terms misconceptions.)

But I think we could already start talking about how we want the
installer to evolve.
I found Architect[1], an installer for Arch which, I think, is a good
example for us as it probably targets a user base close to Guixs'. 
A seen in another thread, we could make use of a non-maillinglist and
collaborative space to think/comment every steps of the user journey.
Does Guix already has/use something like this?

Have a nice day,

Lprndn

Re: Come back and graphical installer

[L p R n d n]

L  p R n  d n    <guix@lprndn.info> writes:

> Hello,
>
> Sorry for the late answer. I can confirm it works for me too. ;)
> I won't add any suggestions for now. Thorsten already did a great job.
> (Replacing the Guix logo by the GuixSD one could be nice tho. To avoid
> propagating terms misconceptions.)
>
> But I think we could already start talking about how we want the
> installer to evolve.
> I found Architect[1], an installer for Arch which, I think, is a good
> example for us as it probably targets a user base close to Guixs'. 
> A seen in another thread, we could make use of a non-maillinglist and
> collaborative space to think/comment every steps of the user journey.
> Does Guix already has/use something like this?
>
> Have a nice day,
>
> Lprndn


Hmmff... The link:
[1] http://landoflinux.com/linux_install_architect_linux.html

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hello!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> If you add it to /etc/environment (through
>> ‘session-environment-service-type’) it should be fine no?
>
> LANG is already part of /etc/environment variables which are loaded by
> the login program which is PAM aware. The installer isn't PAM aware and
> it replaces the login program thus LANG is never loaded.

Oh, got it.

Now, why does the default value of LANG matter anyway?  I mean, the
installer starts out with a default language, presumably English, right?
So you can simply add, say, (setenv "LC_ALL" "en_US.utf8") when starting
the installer, can’t you?

>>   1. ./configure and (guix self) are adjusted to not build the
>>      installer, at least by default.
>>
>>   2. The “old” installation method remains prominently available, either
>>      by making it clear people can use ctrl-alt-f2 & co. to switch to a
>>      terminal, and maybe adding a message on the welcome page stating
>>      that the installer is “beta” or something.
>>
>>   3. The manual is updated to at least mention the new installer, maybe
>>      not in detail.

Also:

  4. The installation system tests still work (e.g.,
     “make check-system TESTS=installed-os”.)  Normally they won’t
     require any modifications since they just run a Bash installation
     script directly through the marionette.

>> How does that sound?
>
> I agree it would be great :), I'm currently focusing on parted support
> but, I'll shift to the 3 points you described above so that it can be
> merged on time.

Awesome.

When do you think we could merge?  I’d like to release by the end of
next week or the week after at the latest.  (If you think you can’t make
it, that’s fine too, no pressure!)

Thanks!

Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey!

> Now, why does the default value of LANG matter anyway?  I mean, the
> installer starts out with a default language, presumably English, right?
> So you can simply add, say, (setenv "LC_ALL" "en_US.utf8") when starting
> the installer, can’t you?

Yup its a way, but in the higly improbable case we want to distribute
install images with the 'locale' field of 'installation-os' set to
something else than en_US.utf8, then LANG matters. I found a hack
consisting in loading everything in /etc/environment just before
starting the installer but I'm not very proud of it!

>   4. The installation system tests still work (e.g.,
>      “make check-system TESTS=installed-os”.)  Normally they won’t
>      require any modifications since they just run a Bash installation
>      script directly through the marionette.

Yup, I'll check!

> When do you think we could merge?  I’d like to release by the end of
> next week or the week after at the latest.  (If you think you can’t make
> it, that’s fine too, no pressure!)

I just pushed to wip-newt-installer some commits. Most of what you
described in points 1, 2 and 3 should be ok. The part, I'm not sure
about and I would like you to have a look is the (guix self) part. I'm
not sure I understand the point of having a *installer-modules*
scheme-node if we don't want to build and distribute the installer via
(guix self).

So what I did is removing (gnu system install) from *system-modules* so
that, all references to the installer is absent from (guix self), but
maybe it's not the right thing to do.

Thanks,

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> Now, why does the default value of LANG matter anyway?  I mean, the
>> installer starts out with a default language, presumably English, right?
>> So you can simply add, say, (setenv "LC_ALL" "en_US.utf8") when starting
>> the installer, can’t you?
>
> Yup its a way, but in the higly improbable case we want to distribute
> install images with the 'locale' field of 'installation-os' set to
> something else than en_US.utf8, then LANG matters. I found a hack
> consisting in loading everything in /etc/environment just before
> starting the installer but I'm not very proud of it!

Heheh.  Another option would be to pass the locale name to the installer
right from (gnu system install).  That way, if people want to build an
image with a different default locale, they can do it.

Fundamentally though, it’s the installer’s job to offer a choice of
languages early on, which it does pretty well already!

> I just pushed to wip-newt-installer some commits. Most of what you
> described in points 1, 2 and 3 should be ok. The part, I'm not sure
> about and I would like you to have a look is the (guix self) part. I'm
> not sure I understand the point of having a *installer-modules*
> scheme-node if we don't want to build and distribute the installer via
> (guix self).
>
> So what I did is removing (gnu system install) from *system-modules* so
> that, all references to the installer is absent from (guix self), but
> maybe it's not the right thing to do.

I think we want to distribute (gnu installer …) modules, just not build
them.  The thing is, they should be “build-side only” modules, and thus
we don’t need to compile them; it’s like (guix man-db), for instance.

So I think gnu/installer/*.scm could go in the *system-modules* node as
#:extra-files.

Does that make sense?

Thanks,
Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hi,

> Heheh.  Another option would be to pass the locale name to the installer
> right from (gnu system install).  That way, if people want to build an
> image with a different default locale, they can do it.
>
> Fundamentally though, it’s the installer’s job to offer a choice of
> languages early on, which it does pretty well already!

Ok you convinced me, I'll just call 'setlocale' at installer start, this
is less dirty.

> I think we want to distribute (gnu installer …) modules, just not build
> them.  The thing is, they should be “build-side only” modules, and thus
> we don’t need to compile them; it’s like (guix man-db), for instance.
>
> So I think gnu/installer/*.scm could go in the *system-modules* node as
> #:extra-files.
>
> Does that make sense?

Yes I understand now. The idea of using only build code is quite nice,
it simplifies a lot of things. So now, (gnu install) is the tip of the
iceberg and everything under gnu/installer/ is build side code (and set
as #:extra-files of *system-modules* in (guix self)). I pushed
a new commit on the branch to fix all of this, it seems ok now.

Thanks for your help,

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hi,

I just pushed one commit on the branch to fix install tests. They now
seem to all pass with success.

Tell me if you see any remaining stuff to be done before merging :)

Thanks,

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Hello Mathieu,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> I just pushed one commit on the branch to fix install tests. They now
> seem to all pass with success.
>
> Tell me if you see any remaining stuff to be done before merging :)

I stumbled upon a typo leading to an unbound variable error after the
last step (patch attached; I let you apply it.)

Other than that, something I hadn’t realized earlier (sorry for being
foolish!): the installer actually stops after the user account selection
and does nothing more, right?  It doesn’t generate a config file nor
does it run ‘guix system init’, does it?

If this is correct, we should probably delay merging until after the
release as people may be confused when they realize the installer has no
effect.  WDYT?

Thanks, and apologies for not following closely enough so far!

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 567 bytes --]

diff --git a/gnu/installer.scm b/gnu/installer.scm
index b3eb2a6b08..d64a66e09d 100644
--- a/gnu/installer.scm
+++ b/gnu/installer.scm
@@ -289,8 +289,8 @@ selected keymap."
                       (print-exception port
                                        (stack-ref (make-stack #t) 1)
                                        key args)))
-                  (primitive-exit 1))))
-            ((installer-exit current-installer))))))
+                  (primitive-exit 1)))
+              ((installer-exit current-installer)))))))
 
   (program-file
    "installer"

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey Ludo!

> Other than that, something I hadn’t realized earlier (sorry for being
> foolish!): the installer actually stops after the user account selection
> and does nothing more, right?  It doesn’t generate a config file nor
> does it run ‘guix system init’, does it?

Nope you're correct, for now it does nothing more.

> If this is correct, we should probably delay merging until after the
> release as people may be confused when they realize the installer has no
> effect.  WDYT?

Sure, I though I would be able to add config generation part before the
release, but the partition step keeps me quite busy!

Thanks for your patch :)

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Brett Gilio]

Mathieu Othacehe writes:

> Hey Ludo!
>
>> Other than that, something I hadn’t realized earlier (sorry for being
>> foolish!): the installer actually stops after the user account selection
>> and does nothing more, right?  It doesn’t generate a config file nor
>> does it run ‘guix system init’, does it?
>
> Nope you're correct, for now it does nothing more.
>
>> If this is correct, we should probably delay merging until after the
>> release as people may be confused when they realize the installer has no
>> effect.  WDYT?
>
> Sure, I though I would be able to add config generation part before the
> release, but the partition step keeps me quite busy!
>
> Thanks for your patch :)
>
> Mathieu

Thank you for your work here, Mathieu. I will be looking forward to
testing it after the merge.

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> Other than that, something I hadn’t realized earlier (sorry for being
>> foolish!): the installer actually stops after the user account selection
>> and does nothing more, right?  It doesn’t generate a config file nor
>> does it run ‘guix system init’, does it?
>
> Nope you're correct, for now it does nothing more.

Cool, that’s already a lot anyway!

>> If this is correct, we should probably delay merging until after the
>> release as people may be confused when they realize the installer has no
>> effect.  WDYT?
>
> Sure, I though I would be able to add config generation part before the
> release, but the partition step keeps me quite busy!

Understood.  Let’s keep it as a nice present for the next release then.
Thanks for all the work!

Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hello,

I pushed a few commits to the branch. All main features are now
implemented. The only important stuff missing (in my opinion) is the
encryption support during partitioning (as well as RAID and LVM I
guess). I also took most of Thorsten remarks into account.

I'll keep tinkering the branch in the next few days, but it is now
possible to have a complete experience and install a real system!

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[swedebugia]

On 2018-12-05 14:23, Mathieu Othacehe wrote:
> Hello,
> 
> I pushed a few commits to the branch. All main features are now
> implemented. The only important stuff missing (in my opinion) is the
> encryption support during partitioning (as well as RAID and LVM I
> guess). I also took most of Thorsten remarks into account.
> 
> I'll keep tinkering the branch in the next few days, but it is now
> possible to have a complete experience and install a real system!

Wow! Nice. What a comeback+delivery it was indeed. Thanks for keeping up
the steam on this. I look forward to test it soon. :D

I will have to repartition my devpc to make it possible to have a 2-3 GB
test-init partition for testing it.

-- 
Cheers 
Swedebugia

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> I pushed a few commits to the branch. All main features are now
> implemented. The only important stuff missing (in my opinion) is the
> encryption support during partitioning (as well as RAID and LVM I
> guess). I also took most of Thorsten remarks into account.
>
> I'll keep tinkering the branch in the next few days, but it is now
> possible to have a complete experience and install a real system!

Sorry for the long delay!

I gave it a try with ‘guix system vm gnu/system/install.scm’ and overall
it looks really nice to me!  A few random things:

  • On the first screen, should “Graphical install” come first?

  • Should the choice of a locale come before the welcome screen?

  • Should the keyboard layout default to “English (US)” rather than
    “Afghani”?  Likewise for the layout variant.

  • s/Ok/OK/  :-)

  • For the partition encryption passphrase, we should probably ask for
    confirmation, no?

  • There’s a debug dialog box called “user-partitions” that pops up
    after hitting “Ok” on the partition choice.  :-)

  • In the “Desktop environments” screen, we should we allow for no
    desktop environments, and then (or before?) have a second screen
    where users can choose between a headless server kind of install or
    a lightweight-X11-desktop kind of install?

  • At the end, after seeing the complete OS definition, I got “execlp:
    cryptsetup: Operation not permitted” written at the top of the
    “Congratulations” screen, and it looks like nothing was actually
    installed (I had chosen the encrypted-root setup).  After that I
    got:

      ERROR: pty: failed to exec child /gnu/store/…-installer: Operation not permitted (exec_child() in src/pty.c:299)

    in a loop and the VM became unusable.  Not sure what happened!

So what are the next steps?  IMO we should consider merging real soon
and get people to test.  WDYT?

Thanks!

Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey Ludo!

Thanks for your review. My comments below.

>   • On the first screen, should “Graphical install” come first?

Done in 0cc05606ddae0ec0bf6244418571ffc1478eeb9.
>
>   • Should the choice of a locale come before the welcome screen?

I'm not sure about this one. I prefer to welcome the user and expose
available options directly, instead of diving directly into locale
selection.

>   • Should the keyboard layout default to “English (US)” rather than
>     “Afghani”?  Likewise for the layout variant.

Sure, done in e4be764186be7638d7d4bf0a94998d1e4fd694d4.
>
>   • s/Ok/OK/  :-)

Done in 23d30dcad7baaeaa0fd4a7835e69137bc3c8dfb2.

>
>   • For the partition encryption passphrase, we should probably ask for
>     confirmation, no?

Done in 86f86f5a8029cd4d00360d6251891486f0eca5ed.
>
>   • There’s a debug dialog box called “user-partitions” that pops up
>     after hitting “Ok” on the partition choice.  :-)

Removed in d1b52bdb6fb270bc5dbad54c165e781888114276.
>
>   • In the “Desktop environments” screen, we should we allow for no
>     desktop environments, and then (or before?) have a second screen
>     where users can choose between a headless server kind of install or
>     a lightweight-X11-desktop kind of install?

Seems like a good idea, I add it to my todo list :)
>
>   • At the end, after seeing the complete OS definition, I got “execlp:
>     cryptsetup: Operation not permitted” written at the top of the
>     “Congratulations” screen, and it looks like nothing was actually
>     installed (I had chosen the encrypted-root setup).  After that I
>     got:
>
>       ERROR: pty: failed to exec child /gnu/store/…-installer: Operation not permitted (exec_child() in src/pty.c:299)
>
>     in a loop and the VM became unusable.  Not sure what happened!

Hmm at least I can reproduce this issue, not sure what's
happening. This error does not happend when creating a disk-image and
running qemu manually. I'll try to investigate it soon.

>
> So what are the next steps?  IMO we should consider merging real soon
> and get people to test.  WDYT?

Sure, it would be great to merge this branch, so that we can move
forward, and hopefully have everything ready for 1.0 release.

Anyway, I plan to give a short talk about this installer and its future
at fosdem.

Sorry for my late answer,

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey,

>>       ERROR: pty: failed to exec child /gnu/store/…-installer: Operation not permitted (exec_child() in src/pty.c:299)
>>
>>     in a loop and the VM became unusable.  Not sure what happened!
>
> Hmm at least I can reproduce this issue, not sure what's
> happening. This error does not happend when creating a disk-image and
> running qemu manually. I'll try to investigate it soon.

The problem seem to be related to cow-store on VM produced by guix
system vm. I can reproduce it on "master" by running:

guix system vm /gnu/system/install.scm and appending -drive
format=raw,file=/home/mathieu/vm-test.img to the produced script.

Then,

mount /dev/sda1 /mnt
herd start cow-store /mnt

-> Every command (like ls ou mount) fails because /gnu/store does not
seem to be reachable anymore.

Is this a known issue, or am I missing something?

Thanks,

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>>>       ERROR: pty: failed to exec child /gnu/store/…-installer: Operation not permitted (exec_child() in src/pty.c:299)
>>>
>>>     in a loop and the VM became unusable.  Not sure what happened!
>>
>> Hmm at least I can reproduce this issue, not sure what's
>> happening. This error does not happend when creating a disk-image and
>> running qemu manually. I'll try to investigate it soon.
>
> The problem seem to be related to cow-store on VM produced by guix
> system vm. I can reproduce it on "master" by running:
>
> guix system vm /gnu/system/install.scm and appending -drive
> format=raw,file=/home/mathieu/vm-test.img to the produced script.
>
> Then,
>
> mount /dev/sda1 /mnt
> herd start cow-store /mnt
>
> -> Every command (like ls ou mount) fails because /gnu/store does not
> seem to be reachable anymore.

Oh indeed.  I think that’s because / is already an overlayfs in ‘guix
system vm’, so somehow we can’t just stack another overlayfs there.

I should test in a standalone image produced by ‘guix system vm-image’
instead.

Sorry for the confusion!

Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi!

I’ve done some more testing, this time using a full-blown ISO image.

Upon a failed install, I noticed that restarting the installer doesn’t
go far because we hit:

  (error "Unable to locate keymap update file")

Indeed, /tmp lacks the kmscon file, which I think is because cow-store
bind-mounts /tmp to /mnt/tmp.

I’m not sure how to address this.  Ideas?

Thanks,
Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey Ludo,

Sadly I think its kind of the same problem as the one I described here:
https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00161.html.

As we are not able to undo what's done by the cow-store service,
once restarted, the installer can't be used properly anymore.

So I guess the solution to both of these problems would be to force a
reboot if the installer fails after the cow-store service has been
started.

WDYT?

Thanks,

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi again!

I pushed a few commits to ‘wip-newt-installer’.

I was able to test it with (roughly):

  guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
  qemu-img create -f qcow2  /tmp/t.img 2100M
  qemu-system-x86_64 -enable-kvm -m 512 -cdrom /gnu/store/…-image.iso \
    -hda /tmp/t.img

The config file was properly generated (hurray!).  The actual
installation eventually failed because substitutes are taken from
hydra.gnu.org, and somehow at one point it would try to download
linux-libre, which would fail (quite surprisingly: I’d expected the
download fallback to work, dunno what happened.)

Anyway, can we rebase the branch on ‘master’?

It seems to me that it’s in a good shape.  The installer is really
pleasant to use!

Thanks,
Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[John Soo]

Hi all!

I was working on adding more configuration options to the kmscon service. Do you think the service can take advantage of the config file, too?

Thanks!

John

> On Jan 16, 2019, at 10:25 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> Hi again!
> 
> I pushed a few commits to ‘wip-newt-installer’.
> 
> I was able to test it with (roughly):
> 
>  guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
>  qemu-img create -f qcow2  /tmp/t.img 2100M
>  qemu-system-x86_64 -enable-kvm -m 512 -cdrom /gnu/store/…-image.iso \
>    -hda /tmp/t.img
> 
> The config file was properly generated (hurray!).  The actual
> installation eventually failed because substitutes are taken from
> hydra.gnu.org, and somehow at one point it would try to download
> linux-libre, which would fail (quite surprisingly: I’d expected the
> download fallback to work, dunno what happened.)
> 
> Anyway, can we rebase the branch on ‘master’?
> 
> It seems to me that it’s in a good shape.  The installer is really
> pleasant to use!
> 
> Thanks,
> Ludo’.
> 

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey again,

> The config file was properly generated (hurray!).  The actual
> installation eventually failed because substitutes are taken from
> hydra.gnu.org, and somehow at one point it would try to download
> linux-libre, which would fail (quite surprisingly: I’d expected the
> download fallback to work, dunno what happened.)

Good that you were able to generate a config file :)

> Anyway, can we rebase the branch on ‘master’?

Fine with me, the rebase shouldn't be too painful. Please go ahead if
it's ok for you :)

> It seems to me that it’s in a good shape.  The installer is really
> pleasant to use!

Thanks, I'm really happy of your feedback!

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> I was able to test it with (roughly):
>
>   guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
>   qemu-img create -f qcow2  /tmp/t.img 2100M
>   qemu-system-x86_64 -enable-kvm -m 512 -cdrom /gnu/store/…-image.iso \
>     -hda /tmp/t.img

That's helpful instruction!  I got a different lucky ISO number, but
getting a config.scm generated worked very nicely.

Impressive work!
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hi!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> Sadly I think its kind of the same problem as the one I described here:
> https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00161.html.
>
> As we are not able to undo what's done by the cow-store service,
> once restarted, the installer can't be used properly anymore.

True, that’s indeed what you described before.

> So I guess the solution to both of these problems would be to force a
> reboot if the installer fails after the cow-store service has been
> started.

Hmm yes, maybe?  Or maybe we can unshare(2) the installer process so it
still sees the original file system layout?  Or, conversely, run the
installation process in a separate name space?

Needs more thought…

Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Hello,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> Anyway, can we rebase the branch on ‘master’?
>
> Fine with me, the rebase shouldn't be too painful. Please go ahead if
> it's ok for you :)

Done!

I think we can now merge on ‘master’.  There might still be rough edges
but the guts of it is in good shape AFAICS so we can polish it on
‘master’.

Mathieu, Ricardo, WDYT?

Thanks,
Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Ricardo Wurmus]

> I think we can now merge on ‘master’.  There might still be rough edges
> but the guts of it is in good shape AFAICS so we can polish it on
> ‘master’.

No objections from me.  Thank you, Mathieu, for the great work!

-- 
Ricardo

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]


Hey,

> I think we can now merge on ‘master’.  There might still be rough edges
> but the guts of it is in good shape AFAICS so we can polish it on
> ‘master’.

Yes I think we can continue the polishing on master :). Here's a small
patch to the TODO file with some suggestions made by Björn and you.

Mathieu


[-- Attachment #2: TODO --]
[-- Type: application/octet-stream, Size: 4113 bytes --]

-*- mode: org; coding: utf-8; -*-

#+TITLE: What's left to do?
#+STARTUP: content hidestars

Copyright © 2012, 2013, 2014 Ludovic Courtès <ludo@gnu.org>

  Copying and distribution of this file, with or without modification,
  are permitted in any medium without royalty provided the copyright
  notice and this notice are preserved.

* MAYBE Add a substituter that uses the GNUnet DHT or [[http://libswift.org][libswift]]

Would be neat if binaries could be pushed to and pulled from the GNUnet DHT or
rather libswift (since DHTs aren’t suited for large payloads).  Guix users
would sign their binaries, and define which binaries they trust.

Use UPnP and similar to traverse NAT, like ‘filegive’ does.

* user interface
** add guile-ncurses interface

* extend <package>
** add ‘recommends’ field

For instance, glibc, binutils, gcc, and ld-wrapper would recommend each other.
‘guix package -i’ could ask interactively (?), or allow users to follow all or
none of the recommendations.

** add a ‘user-environment-hook’

This should specify builder code to be run when building a user
environment with ‘guix-package’.  For instance, Texinfo’s hook would
create a new ‘dir’.

** extend ‘propagated-build-inputs’ with support for multiple outputs

#+BEGIN_SRC scheme
  (outputs '("out" "include"))
  (propagated-build-inputs
    `(((("i1" ,p1 "o1")
        ("i2" ,p2))
       => "include")
      ("i3" ,p3)))
#+END_SRC

* synchronize non-GNU package descriptions with the [[http://directory.fsf.org][FSD]]

Meta-data for GNU packages, including descriptions and synopses, can be
dumped from the FSD:
http://directory.fsf.org/wiki?title=GNU/Export&action=purge .
We could periodically synchronize with that.

* add a guildhall build system

The Guildhall is Guile’s packaging system.  It should be easy to add a
‘guildhall-build-system’ that does the right thing based on guildhall
recipes.

* union

Support sophisticated collision handling when building a union: honor
per-package priorities, etc.

* add GUIX_ALLOW_EXPENSIVE_TESTS

Tests that need to download stuff or otherwise take a long time would only be
run when that is defined.

* guix build utils
** MAYBE Change ‘ld-wrapper’ to add RPATH for libs passed by file name

** MAYBE Add equivalent to chrpath that uses [[https://gitorious.org/guile-dlhacks/guile-dlhacks/][guile-dlhacks]]

** MAYBE Add a hash-rewriting thing for deep dependency replacement without rebuild

See [[https://github.com/NixOS/nixpkgs/commit/d1662d715514e6ef9d3dc29f132f1b3d8e608a18][Shea Levy's `replace-dependency' in Nixpkgs]].

* distro
** port to GNU/Hurd, aka. ‘i686-gnu’

Problems include that current glibc releases do not build on GNU/Hurd.
In addition, there haven’t been stable releases of GNU Mach, MiG, and
Hurd, which would be a pre-condition.
* Installer
** Fix impossibility to restart on error after cow-store has been started
See https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00161.html.
- Force reboot upon installer failure
- Unshare the installer process
- Run the installer process in a separate namespace
** Partitioning
*** Add RAID support
*** Add more partitioning schemes
The actual schemes are taken from Debian Installer but some are not
implemented yet: like "Separate partitions for /home /var and /tmp".
*** Replace wait page "Partition formating is in progress, please wait"
Create a new waiting page describing what's being done:

[              20%              ]
Running mkfs.ext4 on /dev/sda2 ...

[              40%              ]
Running mkfs.ext4 on /dev/sda3 ...

** Desktop environments
*** Allow for no desktop environments
Propose to choose between "headless server" and "lightweight X11" in a new
page.
*** Add services selection feature
Add a services page to the configuration. Ask for services to be installed
like SSH, bluetooth, TLP in a checkbox list?
** Locale and keymap
*** Try to guess user locale and keymap by probing BIOS or HW (dmidecode)
** Timezone
*** Regroup everything in one single page
Under the form:
(UTC + 1) Europe/Paris
(UTC + 2) Africa/Cairo
...

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Heya!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> I think we can now merge on ‘master’.  There might still be rough edges
>> but the guts of it is in good shape AFAICS so we can polish it on
>> ‘master’.
>
> Yes I think we can continue the polishing on master :). Here's a small
> patch to the TODO file with some suggestions made by Björn and you.

Pushed to ‘master’, along with the TODO update on your behalf.

I realize that rebasing probably wasn’t so wise for a long-lived branch
like this after all, especially since it led me to resign all your
commits.  Oh well.

To everyone: please test, hack, and have fun with the installer!

Ludo’.

Re: Merging ‘wip-newt-installer’ in master?

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

I've had a quick go and I must say I like it a lot!  Great job, Mathieu!

A few things:

- When booting on my desktop with a RX580 GPU, I end up with a blank screen.
Turns out that only the display is somehow failing (still investigating), but
pressing Ctrl-Alt-F2 brings me to the documentation!

I suggest we add a 10 second-timeout to the graphical installer so that if there
is no user interaction, it automatically switches back to TTY3 with an
explanatory message, e.g.

--8<---------------cut here---------------start------------->8---
There was no user activity on the graphical installer which may be due to a
display issue.  You can proceed with the installation via command line from
here.
Press Ctrl-Alt-F2 to go to the documentation screen.
Press Ctrl-Alt-F1 to go back to the graphical installer screen.
--8<---------------cut here---------------end--------------->8---

- Add and extra warning before partitioning!  I did it wrong at first but I did
  not expect the installer to proceed straight away, I thought I would have a
  second chance at reviewing the changes before proceeding.

- More generally, I like the idea of a two-stage process: first collect the
  details from the user (without actually performing any change), then show a
  summary of the changes, ask for confirmation and only then apply all the
  changes in one go.

Thanks again for the great contribution!

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

Hey!

> I've had a quick go and I must say I like it a lot!  Great job, Mathieu!

Thanks Pierre :)

> - Add and extra warning before partitioning!  I did it wrong at first but I did
>   not expect the installer to proceed straight away, I thought I would have a
>   second chance at reviewing the changes before proceeding.
>
> - More generally, I like the idea of a two-stage process: first collect the
>   details from the user (without actually performing any change), then show a
>   summary of the changes, ask for confirmation and only then apply all the
>   changes in one go.

I added both of your suggestions to the "Installer" section of the TODO
file!

Thanks for your feedback,

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]


> I added both of your suggestions to the "Installer" section of the TODO
> file!

Thanks!  But what about the first one with the timeout and incompatible
displays? ;)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Merging ‘wip-newt-installer’ in master?

[Mathieu Othacehe]

> Thanks!  But what about the first one with the timeout and incompatible
> displays? ;)

Well no clue for where this display issue comes from, it might be
related to kmscon/framebuffer support on your GPU.

Your fallback timeout message seems like a good idea to me, even though
I'm not sure how to implement it yet.

I added an entry in the TODO/Installer section about it.

Mathieu

Re: Merging ‘wip-newt-installer’ in master?

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 57 bytes --]

Thanks!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Merging ‘wip-newt-installer’ in master?

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

I confirm that the RX580 does not have framebuffer/KMS support with the ATI
driver.
There is KMS support with the AMDGPU driver, sadly it requires some proprietary
blob :(

During the Guix days you mentioned that you went for KMSCON because of encoding
issues if I recall correctly.  So what about this: on startup, test if KMS is
supported.  If not, fall back to the default TTY, and too bad for the limited
encoding :p  Would that work?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Merging ‘wip-newt-installer’ in master?

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> I confirm that the RX580 does not have framebuffer/KMS support with the ATI
> driver.
> There is KMS support with the AMDGPU driver, sadly it requires some proprietary
> blob :(

I’d expect the framebuffer to always work, at least through VESA, no?

> During the Guix days you mentioned that you went for KMSCON because of encoding
> issues if I recall correctly.  So what about this: on startup, test if KMS is
> supported.  If not, fall back to the default TTY, and too bad for the limited
> encoding :p  Would that work?

That would be a reasonable workaround.

Ludo’.