bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  wrote:
> I noticed that connections to the machines were unstable (using
> OpenSSH’s client).  That is, the connection would eventually “hang”,
> apparently several times a day.
>
> Currently we have an SSH tunnel set up on berlin to connect to each of
> these machines via overdrive1.guixsd.org.  This setup proved to be
> robust in the past (we used it to connect to another build machine), so
> I suspect something’s wrong on “your” end of the network.  It’s hard to
> tell exactly what, though.
>
> Ideas?

Okay, I'll look into it.  I'm very busy with something else for the next
couple of days, but I'll try to get to it in the next week.

> If it’s causing build failures, I’m afraid we’ll have to comment out
> those machines from berlin’s machines.scm until we’ve figured it out.

Agreed.

 Thanks,
   Mark

bug#36782: Website manual language links

[Julien Lepiller]

Hi guix,

The online manual says it is available in other languages on its index page, 
with links to… the current page. Can we fix that so one can switch to that 
other language?

I think it would be even better if we could link each page from one language to 
the others, but that looks very difficult.

bug#36782: Website manual language links

[pelzflorian (Florian Pelz)]

On Wed, Jul 24, 2019 at 01:13:44PM +0200, Julien Lepiller wrote:
> Hi guix,
> 
> The online manual says it is available in other languages on its index page, 
> with links to… the current page. Can we fix that so one can switch to that 
> other language?
> 
> I think it would be even better if we could link each page from one language 
> to the others, but that looks very difficult.
> 
> 
> 

This is related, but I am not sure if it is about how Guix online
manuals are generated:

https://lists.gnu.org/archive/html/bug-texinfo/2019-05/msg0.html

Regards,
Florian

bug#36783: Guix graphical installation failure on all drives with size > 1 TiB

[Danny Milosavljevic]

Hi,

using the Guix graphical installation method, one cannot install Guix on a drive
with more than 1 TiB.  (symptom: "null pointer dereference" in mkpart)

The reason is a bug in guile-parted.

An example is to use the "separate /home" option with a 2 TiB disk.

The fix that lets me install is:

(for https://gitlab.com/mothacehe/guile-parted.git master)

diff --git a/parted/unit.scm b/parted/unit.scm
index 6818b7e..68862a8 100644
--- a/parted/unit.scm
+++ b/parted/unit.scm
@@ -147,7 +147,7 @@
  out-range)))
   (if (return-int->bool result)
   (values (car
-   (parse-c-struct c-sector (list int)))
+   (parse-c-struct c-sector (list sector-type)))
   (pointer->geometry
(dereference-pointer out-range)))
   (values #f #f)

However, even after that, disk-print, if used, prints nonsensical (negative)
values for "free" (but installation succeeds).

That bug prevents graphical installation on any drive bigger than 1 TiB.
Let's make a bugfix Guix release shortly.

bug#36784: Cannot generate key pair with GnuPG

[Raghav Gururajan]

Hello Guix!

The current gnupg package in guix has "pinentry" as a missing
dependency.

Because of this, GnuPG throws the following error upon attempting to
generate key pairs:

gpg: agent_genkey failed: No pinentry
gpg: key generation failed: No pinentry

So it appears, unless the above mentioned dependency issue is fixed,
one cannot create gpg key pairs. :(

Regards,
RG.

bug#36785: Impossible to pull on foreign distro

[Julien Lepiller]

Hi guix,

I gave a small tutorial to someone today, where we installed guix on top of a 
foreign distro. We used the script and everything went smoothly, and after 
finding out that we were going to build php (we were trying to define a VM that 
would serve one of their services), we tried to run guix pull:

sudo guix pull —commit=…

However the command failed immediately with:

Migrating profile generations to '/var/guix/profiles/per-user/root'...
Guix pull: error: symlink: File exists: 
"/var/guix/profiles/per-user/root/current-guix"

Indeed, the file exists and everything looks good. Why does guix try to migrate 
a profile that's already good?

I was able to work around that situation, but it's not great for our users.

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

Back in
,
I wrote:

On Fri, Apr 26, 2019 at 10:35:43AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sat, Apr 20, 2019 at 11:47:56AM +0200, Ludovic Courtès wrote:
> > "pelzflorian (Florian Pelz)"  skribis:
> > > I believe issues with (some?) AMD GPUs should be mentioned in the
> > > manual.  Also, on the downloads page perhaps it should be mentioned
> > > that there may be issues with some hardware, referring users to the
> > > Hardware Considerations in the Guix manual.
> > 
> > We could do that, but these kind of kernel-side issues tend to appear
> > and vanish quickly, no?  But I don’t know much about these AMD GPU
> > issues, so I’m happy to do what people consider appropriate.
> > 
> 
> My AMD GPU machine started working with VESA Xorg drivers at full resolution.
> I reconfigured a while ago but did not test back then.

Aside from the fact that 3d acceleration is out of reach for modern
AMD GPUs on a linux-libre kernel, Guix had at least two further
reports of trouble with old and very new AMD GPUs like:

https://lists.gnu.org/archive/html/help-guix/2019-06/msg00227.html

and

https://lists.gnu.org/archive/html/help-guix/2019-07/msg00179.html


Part of the reason a warning about AMD GPUs should be considered is
that AMD Radeon is often claimed to be usable with drivers that are
“entirely free and open-source software”
(),
making people believe they do not require nonfree firmware.

I suppose but do not know that recent Nvidia hardware works without 3d
acceleration, even when the Nouveau Xorg driver does not support it
yet.  I suppose but am unsure if recent Intel GPUs work out of the box
without blobs.  If correct, this would make AMD in particular notable.

On the other hand, Pierre Neidhard commented at

that many AMD GPUs work well.

Possibly I am overly negative because my computer is affected as well.
Still, I think the hardware considerations section in the manual
should list at least that Xorg graphics on some AMD GPUs do not work
and that using the console might require tweaks like
modprobe.blacklist=radeon.  The website too should tell users on the
downloads page that, even though most machines work well, wi-fi
vendors like Broadcom and graphics card vendor AMD refuse to make *some*
of their devices work with the linux-libre kernel used by Guix System.

Regards,
Florian

bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds

[Ludovic Courtès]

Hello,

Mark H Weaver  skribis:

> Ludovic Courtès  wrote:
>> I noticed that connections to the machines were unstable (using
>> OpenSSH’s client).  That is, the connection would eventually “hang”,
>> apparently several times a day.
>>
>> Currently we have an SSH tunnel set up on berlin to connect to each of
>> these machines via overdrive1.guixsd.org.  This setup proved to be
>> robust in the past (we used it to connect to another build machine), so
>> I suspect something’s wrong on “your” end of the network.  It’s hard to
>> tell exactly what, though.
>>
>> Ideas?
>
> Okay, I'll look into it.  I'm very busy with something else for the next
> couple of days, but I'll try to get to it in the next week.

OK!

>> If it’s causing build failures, I’m afraid we’ll have to comment out
>> those machines from berlin’s machines.scm until we’ve figured it out.
>
> Agreed.

I’ve commented them out now.

Thanks,
Ludo’.

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

On Wed, Jul 24, 2019 at 04:56:03PM +0200, pelzflorian (Florian Pelz) wrote:
> very new AMD GPUs like:
> […]
> https://lists.gnu.org/archive/html/help-guix/2019-07/msg00179.html
>

Sorry.  The reporter said this GPU is a Radeon R9 280X 3G.  I was
wrong to believe it was a new GPU just because the CPU was reported to
be recent.  It is from the same

https://en.wikipedia.org/wiki/AMD_Radeon_Rx_200_series

as my AMD GPU.

We could make a list of known bad GPUs.

bug#36783: Guix graphical installation failure on all drives with size > 1 TiB

[Mathieu Othacehe]

Hello Danny,

> However, even after that, disk-print, if used, prints nonsensical (negative)
> values for "free" (but installation succeeds).
>
> That bug prevents graphical installation on any drive bigger than 1 TiB.
> Let's make a bugfix Guix release shortly.

Your fix seems ok for me, thank you! I don't get why you negative values
though. I'll try to find a big hard drive to understand this before
pushing this patch.

Thanks,

Mathieu

bug#36659: There should be an unattended upgrades service

[Ludovic Courtès]

Hi,

Arne Babenhauserheide  skribis:

> Also it would be interesting to have an auto-update service that only
> updates /run/current-system

Yes, that’s what we’re talking about here, or at least what I had in
mind.  :-)

Ludo’.

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

On Wed, Jul 24, 2019 at 05:42:49PM +0200, pelzflorian (Florian Pelz) wrote:
> We could make a list of known bad GPUs.
> 

When thinking about it, a list of known bad GPUs might be legally
safer than saying AMD GPUs are often bad.

Regards,
Florian

bug#36786: Warn of AMD GPUs unusable with Guix System

[Ricardo Wurmus]

pelzflorian (Florian Pelz)  writes:

> On Wed, Jul 24, 2019 at 05:42:49PM +0200, pelzflorian (Florian Pelz) wrote:
>> We could make a list of known bad GPUs.
>>
>
> When thinking about it, a list of known bad GPUs might be legally
> safer than saying AMD GPUs are often bad.

I sympathize with the frustration that comes along with the realization
that hardware you own cannot be used with free software.  I would like
to alert people to the fact that certain GPUs won’t be usable with
linux-libre.

I just think that there might be a better distro-independent place for
this kind of information.  Some free distros suggest checking for free
software compatibility on h-node.org, a shared resource.  That’s also
where we could record known bad GPUs.

(h-node.org isn’t the prettiest resource out there, but perhaps this can
be changed.)

Do you think it would be enough if we pointed to h-node.org and
mentioned kernel flags that might be useful in certain generic cases?

--
Ricardo

bug#36685: ant-bootstrap fails on core-updates (409 dependents)

[Ricardo Wurmus]

Hi Gábor,

>> So, with the following change I was able to build all the way up to the
>> latest openjdk.  Should we use it despite the introduction of a memory
>> leak in a bootstrap JVM?  Can we make the patch smaller (fewer uses of
>> glibc 2.28 or gcc-5)?
>>
>> What do you think?
>>
>
> I will have a look at reducing the patch later today. I will report back
> tomorrow morning with the results.

Did you have any luck with this?

-- 
Ricardo

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

On Wed, Jul 24, 2019 at 09:05:06PM +0200, Ricardo Wurmus wrote:
> Do you think it would be enough if we pointed to h-node.org and
> mentioned kernel flags that might be useful in certain generic cases?
> 

Yes, that is a very good suggestion and easiest to do.  I did not
think about h-node…  The manual already points there, but the website
should too.  Then this bug can be closed, I think.

Find attached a patch that mentions the kernel flag in the manual’s
Hardware Considerations section.  I do not know if a separate section
would be better.  (The alternative kernel flag “nomodeset” was
reported to not work as well, so I did not mention it, see here:
)

h-node currently appears to have no information on those video cards.
I will take a look at how to add information there later.

Regards,
Florian>From e88ee68c09266e1d09d24ff0d1b6ec6a4708841b Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Wed, 24 Jul 2019 23:02:21 +0200
Subject: [PATCH] doc: Mention AMD Radeon workaround when TTYs are not redrawn.

* doc/guix.texi (Hardware Considerations): Describe workaround.
---
 doc/guix.texi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index f6d9718f59..b9e18e55c4 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1879,6 +1879,24 @@ Another useful resource is the 
@uref{https://www.h-node.org/, H-Node}
 web site.  It contains a catalog of hardware devices with information
 about their support in GNU/Linux.
 
+Some hardware requires specific tweaks to work better with Guix System.  The
+following is an incomplete list of known workarounds:
+
+@itemize
+@item
+Some @emph{AMD Radeon} graphics cards stop redrawing the virtual console TTYs
+when booting because of an error with Kernel Mode Setting.  The problem
+disappears when blacklisting the kernel module for the driver.  To do so, you
+can add @code{modprobe.blacklist=radeon} to the Linux-libre kernel flags,
+either for only one boot by pressing the @kbd{e} key in the GRUB bootloader
+and adding this kernel flag to the end of the @code{linux} command-line, or
+permanently by changing the @code{kernel-arguments} field in your
+@code{operating-system} declaration, e.g.:
+
+@example
+(kernel-arguments '("quiet" "modprobe.blacklist=radeon"))
+@end example
+@end itemize
 
 @node USB Stick and DVD Installation
 @section USB Stick and DVD Installation
-- 
2.22.0

bug#36784: Cannot generate key pair with GnuPG

[Raghav Gururajan]

Hello Guix!

After brief discussion on IRC channel, I found out that adding
"pinentry-program /home/user/.guix-profile/bin/pinentry-program" to
"gpg-agent.conf" in "/home/user/.gnupg", was able to temproarily
resolve the situation. Thanks to Ricardo (rekado).

I still suggest that there should be a default/fallback option for
this. After reviewing guix repository, I found pinentry, emacs-
pinentry, pinentry-tty, pinentry-qt, pinentry-gtk2, pinentry-gnome3,
pinentry-emacs and pinentry-efl, as available pinentry programs.

Out of all, I suggest pinentry to be set as default/fallback option for
gnupg in guix, as it is platform-independent and provides both CUI
(console) and GUI.

Thank you!

Regards,
RG.