bug#55006: First time boot hangs after "watchdog hardware is disabled"

[crodges]

On Tuesday, April 19, 2022 1:23:50 P.M. PDT pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 19, 2022 at 06:55:11PM +0200, raingloom wrote:
> > Also IMHO this further proves my point that we need a "safe graphics
> > mode" boot option, see issue 54945.
> 
> Well the uvesafb in the installer image worked for crodges, I suppose,
> so in the AMDGPU case there is no need for another boot option in the
> installer image.
> 
> I’m not sure what to do about the installed system.  There are
> multiple choices and all are bad.  Currently by default after install
> you get a broken system unless nomodeset is added.  The other libre
> options are not to use most of the expensive and powerful GPU.
> 
> Regards,
> Florian
Well the issue was solved, I now have a bootable guix system. I'll consider my 
options regarding the gpu. Thank you very much florian and raingloom. I 
learned quite a few things!

crodges

signature.asc
Description: This is a digitally signed message part.

bug#54779: guix home reconfigure throw error after Shepherd updata

[Aleksandr Vityazev]

Hi,

it seems that the attached patch should fix this.

-- 
Best regards,
Aleksandr Vityazev

diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm
index df6bbb30e6..cbb7b17987 100644
--- a/gnu/home/services/shepherd.scm
+++ b/gnu/home/services/shepherd.scm
@@ -84,6 +84,8 @@ (define config
 services
 (if (defined? 'start-in-the-background)
 (start-in-the-background services-to-start)
-(for-each start services-to-start)
+(for-each start services-to-start))
+(redirect-port (open-input-file "/dev/null")
+   (current-input-port)

 (scheme-file "shepherd.conf" config)))

bug#55006: First time boot hangs after "watchdog hardware is disabled"

[pelzflorian (Florian Pelz)]

On Tue, Apr 19, 2022 at 06:55:11PM +0200, raingloom wrote:
> Also IMHO this further proves my point that we need a "safe graphics
> mode" boot option, see issue 54945.

Well the uvesafb in the installer image worked for crodges, I suppose,
so in the AMDGPU case there is no need for another boot option in the
installer image.

I’m not sure what to do about the installed system.  There are
multiple choices and all are bad.  Currently by default after install
you get a broken system unless nomodeset is added.  The other libre
options are not to use most of the expensive and powerful GPU.

Regards,
Florian

bug#55006: First time boot hangs after "watchdog hardware is disabled"

[pelzflorian (Florian Pelz)]

Hi crodges,

On Tue, Apr 19, 2022 at 09:40:20AM -0700, crodges wrote:
> Noticed that the kernel was updated to linux-libre 5.16.20. Tried to reboot 
> without editing arguments in the kernel. I got to another freeze, and clearly 
> it seems to be the amd gpu, as in the new attached image. Is it possible, 
> considering that this gpu has free software drivers?

I proposed removing quiet so more messages would get printed to the
screen, but your photo already shows everything.

So this is bad news.  Technically the amdgpu drivers themselves are
free software, but they require nonfree firmware, and linux-libre
removes it.

With linux-libre, there is therefore no way to use the GPU for 3D
acceleration, I believe.

In your original post, you said you succeeded in installing Guix
System with the installer image.  The installer image uses
uvesafb-service-type when amdgpu fails, so you could do the same.

See the installer’s configuration file at:

~/.config/guix/current/share/guile/site/3.0/gnu/system/install.scm

The workaround I suggested at

On Tue, Apr 19, 2022 at 10:50:47AM +0200, pelzflorian (Florian Pelz) wrote:
> (If it AMD turns out to be the issue, Denis 'GNUtoo' Carikli suggested
> to partially fix them , while I
> suggested to work around them .
> Manjaro would not have these issues because it uses a nonfree linux
> package.  But your bug may be something completely different.)

is a more concise way to unconditionally load uvesafb, even for
graphical desktops.  Denis’ suggestion to fix the driver is a more
proper solution but more work, if it works.  Either way you won’t be
able to use accelerated 3D with linux-libre.

I’m merging this bug with 48343.

Regards,
Florian

bug#54929: Acknowledgement (./pre-inst-env recompiling files)

[Andreas Enge]

The mysterious problem disappeared mysteriously after making a new git
checkout and bootstrapping. Closing the bug.

Andreas

bug#54893: [PATCH] guix: git-download: Set locale to deal with Unicode in git metadata.

[Attila Lendvai]

Without this the git-fetch GEXP is run in an environment that uses ASCII
character encoding when strings are crossing the Guile - C boundary.  It means
that e.g. tag names that have Unicode chars in them will cause problems,
e.g. when walking and deleting the .git directory.

An example in the wild: https://github.com/klauspost/pgzip/tags

For more details see: https://issues.guix.gnu.org/54893

* guix/git-download.scm (git-fetch): Call setlocale to set it to en_US.utf8.
---

thanks Maxime, this indeed seems to work! and i have successfully
guix pull'ed it, too.

 guix/git-download.scm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/guix/git-download.scm b/guix/git-download.scm
index 5e624b9ae9..2fc5a06490 100644
--- a/guix/git-download.scm
+++ b/guix/git-download.scm
@@ -104,6 +104,9 @@ (define guile-zlib
   (define gnutls
 (module-ref (resolve-interface '(gnu packages tls)) 'gnutls))
 
+  (define glibc-locales
+(module-ref (resolve-interface '(gnu packages base)) 'glibc-locales))
+
   (define modules
 (delete '(guix config)
 (source-module-closure '((guix build git)
@@ -121,6 +124,13 @@ (define build
  (guix build download-nar)
  (guix swh)
  (ice-9 match))
+;; We must set the locale to something/anything that will make the
+;; Guile FFI use a character encoding that is idempotent through a
+;; bytes->string string->bytes roundtrip.  Otherwise e.g. git tags
+;; with Unicode characters would break things.  For more details
+;; and an example see https://issues.guix.gnu.org/54893
+(setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale"))
+(setlocale LC_ALL "en_US.utf8")
 
 (define recursive?
   (call-with-input-string (getenv "git recursive?") read))
-- 
2.35.1

bug#55006: First time boot hangs after "watchdog hardware is disabled"

[raingloom]

On Tue, 19 Apr 2022 09:40:20 -0700
crodges  wrote:

> On Tuesday, April 19, 2022 1:50:47 A.M. PDT pelzflorian (Florian
> Pelz) wrote:
> > On Mon, Apr 18, 2022 at 10:32:53AM -0700, crodges wrote:  
> > > Hello,
> > > 
> > > I'm installing guix in a recent desktop that I build (little more
> > > than a year). After being suggested to use latest iso on cuirass,
> > > I was able to install guix. The boot then hanged looking for
> > > iwlwifi firmware; someone in
> > > the help list suggested me to edit boot options and blacklist
> > > iwlwifi, then
> > > reconfigure guix once in.
> > > 
> > > I did that and now booting process hangs in a new place, "Watchdog
> > > hardware is disabled". I include an image of the point.
> > > 
> > > Thanks,
> > > 
> > > crodges  
> > 
> > Could you try to edit the boot options also to
> > 
> > - remove the `quiet`
> > 
> > - possibly you may need to add `nomodeset`.
> > 
> > What GPU is in this machine?  On your Manjaro system, lspci or GNOME
> > Settings for example would show.
> > 
> > There are problems at least with some AMD GPUs, but this may not be
> > the issue.
> > 
> > (If it AMD turns out to be the issue, Denis 'GNUtoo' Carikli
> > suggested to partially fix them
> > , while I suggested to work
> > around them . Manjaro would not
> > have these issues because it uses a nonfree linux package.  But
> > your bug may be something completely different.)
> > 
> > Regards,
> > Florian  
> Florian, 
> 
> Removing quiet and adding nomodeset, I was able to boot for the first
> time! low resolution, but I was able to edit config.scm to add 
> 
> (kernel-arguments
>  '(; https://issues.guix.gnu.org/53712#12
>"modprobe.blacklist=pcspkr,snd_pcsp,iwlwifi"))
> 
> as referenced in https://issues.guix.gnu.org/53712#13
> 
> then did guix pull and sudo guix system reconfigure /etc/config.scm
> 
> Noticed that the kernel was updated to linux-libre 5.16.20. Tried to
> reboot without editing arguments in the kernel. I got to another
> freeze, and clearly it seems to be the amd gpu, as in the new
> attached image. Is it possible, considering that this gpu has free
> software drivers?  
> 
> The GPU is a Radeon RX 6800 XT, which manjaro lists as using open
> source drivers.
> 
> 

The funny thing is that AMDGPU is not really entirely free software,
only the kernel component is, but the firmwares are not. Guix doesn't
actually package AMDGPU as far as I know, you have to use The Forbidden
Channel if you have an AMD card and want to actually use it. But also
yes, it's super buggy for me as well, sometimes it freezes, sometimes
it just glitches out.

Also IMHO this further proves my point that we need a "safe graphics
mode" boot option, see issue 54945.

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Maxime Devos]

Attila Lendvai schreef op di 19-04-2022 om 11:38 [+]:
> so, is such an idempotent locale available/embedded in glibc without
> any external dependencies? searching the web suggests that there isn't.

Try:

$ LC_CTYPE=anything.ISO-8859-2  guix repl é
hint: Consider installing the `glibc-locales' package and defining 
`GUIX_LOCPATH', along these lines:

 guix install glibc-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

;;; Stat of /home/[...]/ĂŠ failed:
;;; In procedure stat: Bestand of map bestaat niet: "/home/[...]/ĂŠ"
guix repl: fout: open-file: Bestand of map bestaat niet: 
"/home/regulator/source-code/rw/ĂŠ"

IIUC, this causes lib/localcharset.c in Guile to run 'eviron_locale_charset',
which just uses environment variables and ignores glibc's locale data.

I don't know if this requires 'setlocale' or requires the absence of 
'setlocale'.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Maxime Devos]

Attila Lendvai schreef op di 19-04-2022 om 11:38 [+]:
> > thank you, this works indeed as a band aid:
> > 
> > (setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale"))
> > (setlocale LC_ALL "en_US.utf8")
> 
> 
> i spoke too early. this works in a git checkout of guix, but it fails
> to compile when i try to guix pull it.
> 
> even if i declare the dependency like this:
> 
> #:autoload   (gnu packages base) (glibc-locales)
> 
> IIUC, this is due to a circular dependency: glibc-locales (and its
> variants) depend on git-fetch, therefore i cannot refer to them from
> the implementation of git-fetch.

The module of the glibc-locales package depends on git-fetch, but I
don't think the package glibc-locales does.  Anyway, circular imports
are messy and (guix build-system ...) and (guix git-download) use an
extra-lazy variant of #:autoload that doesn't load the module even when
compiling (*).

(*) Limitation: this method cannot be used to use macros.

Maybe the attached variant works?

Greetings,
Maxime.
diff --git a/guix/git-download.scm b/guix/git-download.scm
index 5e624b9ae9..a74ba5f592 100644
--- a/guix/git-download.scm
+++ b/guix/git-download.scm
@@ -104,6 +104,9 @@ (define guile-zlib
   (define gnutls
 (module-ref (resolve-interface '(gnu packages tls)) 'gnutls))
 
+  (define glibc-locales
+(module-ref (resolve-interface '(gnu packages base)) 'glibc-locales))
+
   (define modules
 (delete '(guix config)
 (source-module-closure '((guix build git)
@@ -122,6 +125,8 @@ (define build
  (guix swh)
  (ice-9 match))
 
+(pk #+glibc-locales)
+(error "see the pk")
 (define recursive?
   (call-with-input-string (getenv "git recursive?") read))
 


signature.asc
Description: This is a digitally signed message part

bug#55024: [cuirass] '+' character in branch name causes problems

[Maxim Cournoyer]

Hello,

It seems that when using a '+' character in the branch name, such as in
the wip-ipython+polyglossia branch I pushed to Savannah, Cuirass is not
able to use it as part of a job specification, at least one made via the
web interface as found here:
https://ci.guix.gnu.org/jobset/wip-ipython%2Bpolyglossia.

Thanks,

Maxim

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Attila Lendvai]

> thank you, this works indeed as a band aid:
>
> (setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale"))
> (setlocale LC_ALL "en_US.utf8")


i spoke too early. this works in a git checkout of guix, but it fails
to compile when i try to guix pull it.

even if i declare the dependency like this:

#:autoload   (gnu packages base) (glibc-locales)

IIUC, this is due to a circular dependency: glibc-locales (and its
variants) depend on git-fetch, therefore i cannot refer to them from
the implementation of git-fetch.

i tried to set the locale to "C" or "POSIX", but it results in ASCII encoding.

i tried to set the locale to "en_US.iso-8859-1", hoping that it's
available, but it isn't.

all that is needed here is an encoding that is idempotent wrt a cycle
through bytes->string, string->bytes. i think the iso-8859-n encodings
are like that.

to verify that hypothesis:

$ mkdir -p /tmp/delme/v½.2.0
$ LANG=C guix repl
scheme@(guix-user)> (use-modules (guix build utils))
scheme@(guix-user)> (delete-file-recursively "/tmp/delme")
warning: failed to delete /tmp/delme/v??.2.0: No such file or directory
warning: failed to delete /tmp/delme: Directory not empty
$1 = #t
$2 = #
scheme@(guix-user)>

$ LANG=en_US.iso-8859-1 guix repl
scheme@(guix-user)> (use-modules (guix build utils))
scheme@(guix-user)> (delete-file-recursively "/tmp/delme")
$1 = #
scheme@(guix-user)>


so, is such an idempotent locale available/embedded in glibc without any 
external dependencies? searching the web suggests that there isn't.

if not, then what would be a bird's eye view plan to make one
available for git-fetch?

should we create a new, ASCII-only git-fetch variant used in the bootstrap 
process?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The world is changed by your example, not by your opinion.”
— Paulo Coelho (1947–)

bug#55006: First time boot hangs after "watchdog hardware is disabled"

[pelzflorian (Florian Pelz)]

On Mon, Apr 18, 2022 at 10:32:53AM -0700, crodges wrote:
> Hello,
> 
> I'm installing guix in a recent desktop that I build (little more than a 
> year). After being suggested to use latest iso on cuirass, I was able to 
> install guix. The boot then hanged looking for iwlwifi firmware; someone in 
> the help list suggested me to edit boot options and blacklist iwlwifi, then 
> reconfigure guix once in.
> 
> I did that and now booting process hangs in a new place, "Watchdog hardware 
> is 
> disabled". I include an image of the point.
> 
> Thanks,
> 
> crodges

Could you try to edit the boot options also to

- remove the `quiet`

- possibly you may need to add `nomodeset`.

What GPU is in this machine?  On your Manjaro system, lspci or GNOME
Settings for example would show.

There are problems at least with some AMD GPUs, but this may not be
the issue.

(If it AMD turns out to be the issue, Denis 'GNUtoo' Carikli suggested
to partially fix them , while I
suggested to work around them .
Manjaro would not have these issues because it uses a nonfree linux
package.  But your bug may be something completely different.)

Regards,
Florian

bug#55003: emacs-dash test failing,

[Liliana Marie Prikler]

Am Montag, dem 18.04.2022 um 06:23 -0500 schrieb Bryan Paronto:
> Hello Guixers
Hi Bryan

> I’ll prefacing by saying I’m still rather green to Guix System and
> Home, but am loving every minute of hacking, even when things dont
> immediate go according to plan.
> 
> This morning I’m attempting to use Guix for all of my Emacs package
> management needs, however one package, emacs-dash-2.19.1 seems to be
> failing to build. According to the logs, this is due to a long-than-
> 80-character doctring. According to their repository, this issue has
> been address, but a new release has not yet been cut containing the
> fix.
That's rather peculiar given that emacs-dash builds fine in CI as far
as I am aware.  I also have a build locally cached.

/gnu/store/63r1i2mpgivb2f99h2dscmrymcv9n257-emacs-dash-2.19.1

On which Guix commit are you currently?  Do you perhaps use a channel,
that provides its own definition of emacs-dash?

> What is the prescribed way of addressing such an issue, where emacs-
> dash is an input on one or more of the packages I’m attempting to
> install as part of my reconfigure.
The short fix would be to cut out emacs-dash from your config for now.
Use `guix graph' to find out what pulls it in.  The long fix would be
to find out what makes emacs-dash fail and repair that.

> I’ve run `guix pull' and `guix package -u' . I’m uncertain of
> creating a new package definition with tests disabled would be the
> solution, but I’ve yet to try.
You can use a transformation for that, it's called --without-tests. 
Using it does not guarantee a successful build, though.

Cheers