Re: GNU Guix maintainer collective update

[John Soo]

Hello Guix and Ricardo,

> There's a new blog post about a recent update to the GNU Guix maintainer
> collective [0].  I won't repeat the blog post here, but in a few words,
> Ricardo Wurmus is stepping down from his role and Mathieu Othacehe
> is joining in.

I would like to echo the sentiment that Guix is nice software but has
even nicer leadership and community. Thank you so much for your service,
Ricardo.

I hope to see you around.

> Let's also welcome Mathieu Othacehe in his new role!  Congratulations,
> Mathieu!  :-)

Congratulations Mathieu!

Kindly,

John Soo

Re: What LVM support is missing?

[Michael Rohleder]

Hey Simon!

Simon Josefsson  writes:
> I'm thinking that having the root file system on LVM may be unsupported,
> so that manual could say that, but I'm not even sure that is true.  I
> haven't tried it though.  Perhaps 'lvm2' should be pre-installed on the
> default installation image to help move LVM support along.
>
> Another thought may be that constructing LVM partitions through the
> mapped-device mechanism is not supported:
>
> http://guix.gnu.org/manual/en/html_node/Mapped-Devices.html
>
> however as far as I can tell, LVM is working just as well as LUKS/RAID
> here: LVM just doesn't need any command to start the devices.  The
> mapped-device approach appear to require out-of-band device creation for
> LUKS and RAID, just like is required for LVM.  A no-op
> `lvm-device-mapping' could be added for completeness, and it might run
> 'pvscan --active ay' or something like that if we really wanted to but
> I'm not sure when that would be useful.

I use a root fs on lvm.
What helped me a lot was this posting, where I stole most things:

https://lists.gnu.org/archive/html/bug-guix/2020-02/msg00285.html

What (currrently) isnt working is the lvm device-mapper and (for me more
important) lvmcache...


-- 
Fly Windows NT:
All the passengers carry their seats out onto the tarmac, placing the chairs
in the outline of a plane. They all sit down, flap their arms and make jet
swooshing sounds as if they are flying.


signature.asc
Description: PGP signature

Re: GNU Guix maintainer collective update

[Efraim Flashner]

On Mon, May 04, 2020 at 09:31:46AM -0400, Maxim Cournoyer wrote:
> Hello Guix!
> 
> There's a new blog post about a recent update to the GNU Guix maintainer
> collective [0].  I won't repeat the blog post here, but in a few words,
> Ricardo Wurmus is stepping down from his role and Mathieu Othacehe
> is joining in.
> 
> Let's take a moment to thank Ricardo for his time as a Guix
> co-maintainer.  He's been immensely useful to the project and I hope
> we'll continue to see him around.
> 
> Let's also welcome Mathieu Othacehe in his new role!  Congratulations,
> Mathieu!  :-)
> 
> [0]  https://guix.gnu.org/blog/2020/gnu-guix-maintainer-collective-update/
> 
> Maxim

A big thank you to Ricardo for all his hard work over the years and a
warm welcome to Mathieu!

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: What LVM support is missing?

[Marius Bakke]

Simon Josefsson  writes:

> The manual is quite clear that LVM support is missing:
>
>   https://guix.gnu.org/manual/en/html_node/Limitations.html
>
> This held me back from using guix as the OS for my virtualization
> servers since I use LVM for virtual machines.  However, one evening I
> was curious how difficult it would be to fix the above limitation, so I
> started with a simple 'guix package -i lvm2' and that allowed me to get
> LVM to work and I can't really notice anything missing.
>
> Before producing a patch to correct the manual, could someone explain
> what LVM support was intended that was missing?  Does a reference to LVM
> as a limitation of Guix still make sense?

What's missing is support in the configuration system: the ability to
declare a LVM mapped device in the OS configuration and expect 'guix
system init', 'guix system reconfigure' etc to work.

LVM 2.03 simplifies things a bit, but I don't know of any recent
attempts to add LVM support to the configuration system.


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

Timothy Sample  writes:

> Hi Marius,
>
> Marius Bakke  writes:
>
>> The "core-updates" branch is ready for testing!  [...]
>>
>> Please try upgrading your profiles and systems and file bugs for
>> anything that does not work for you.  GNOME users in particular are
>> encouraged to try the new GNOME 3.34 and report any regressions.
>
> Just so you know, GNOME 3.34 is working swimmingly for me.  So far I am
> a very happy core-updates user.  Thank you very much for all your hard
> work!

Great to know, thanks!  Credits to Kei for the GNOME 3.34 upgrade.  :-)

I think the only remaining blocker is fixing the WebKitGTK+ sandbox
issue in Epiphany: .

Chris also reported an issue with FlighGear.  Presumably updating to the
latest version would make it work with the newer Boost.  Any takers?

@everyone, please speak up if you find any of your packages failing on
the core-updates branch!  The substitute coverage is currently ~90%,
which is better than on 'master'.


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Timothy Sample]

Hi Marius,

Marius Bakke  writes:

> The "core-updates" branch is ready for testing!  [...]
>
> Please try upgrading your profiles and systems and file bugs for
> anything that does not work for you.  GNOME users in particular are
> encouraged to try the new GNOME 3.34 and report any regressions.

Just so you know, GNOME 3.34 is working swimmingly for me.  So far I am
a very happy core-updates user.  Thank you very much for all your hard
work!


-- Tim

What LVM support is missing?

[Simon Josefsson]

The manual is quite clear that LVM support is missing:

  https://guix.gnu.org/manual/en/html_node/Limitations.html

This held me back from using guix as the OS for my virtualization
servers since I use LVM for virtual machines.  However, one evening I
was curious how difficult it would be to fix the above limitation, so I
started with a simple 'guix package -i lvm2' and that allowed me to get
LVM to work and I can't really notice anything missing.

Before producing a patch to correct the manual, could someone explain
what LVM support was intended that was missing?  Does a reference to LVM
as a limitation of Guix still make sense?

I'm thinking that having the root file system on LVM may be unsupported,
so that manual could say that, but I'm not even sure that is true.  I
haven't tried it though.  Perhaps 'lvm2' should be pre-installed on the
default installation image to help move LVM support along.

Another thought may be that constructing LVM partitions through the
mapped-device mechanism is not supported:

http://guix.gnu.org/manual/en/html_node/Mapped-Devices.html

however as far as I can tell, LVM is working just as well as LUKS/RAID
here: LVM just doesn't need any command to start the devices.  The
mapped-device approach appear to require out-of-band device creation for
LUKS and RAID, just like is required for LVM.  A no-op
`lvm-device-mapping' could be added for completeness, and it might run
'pvscan --active ay' or something like that if we really wanted to but
I'm not sure when that would be useful.

Thanks,
/Simon


signature.asc
Description: PGP signature

GNU Guix maintainer collective update

[Maxim Cournoyer]

Hello Guix!

There's a new blog post about a recent update to the GNU Guix maintainer
collective [0].  I won't repeat the blog post here, but in a few words,
Ricardo Wurmus is stepping down from his role and Mathieu Othacehe
is joining in.

Let's take a moment to thank Ricardo for his time as a Guix
co-maintainer.  He's been immensely useful to the project and I hope
we'll continue to see him around.

Let's also welcome Mathieu Othacehe in his new role!  Congratulations,
Mathieu!  :-)

[0]  https://guix.gnu.org/blog/2020/gnu-guix-maintainer-collective-update/

Maxim

Re: Wi-Fi connection during gui-based installation

[sb . nipper001]

I think I didn't reply correctly, here is follow-up again:


Thanks for responding.  I do not know how to avail me of this fix you
referenced.

 On Thu, 23 Apr 2020 22:35:37 +0200
Ludovic Courtès  wrote:

> Hi Stephen,
> 
> Stephen Minton  skribis:
> 
> > I successfully put guix-system-install-1.0.1.x86_64-linux.iso on a
> > mem stick and booted.
> >
> > GUI installer hung up on connecting to wifi network (successfully
> > found interface and scanned, showing target wifi name) on message
> > "connection in progress  Connecting to ... please wait.  
> 
> Yeah, unfortunately we discovered this bug in the 1.1.0 image (it’s
> now fixed: ).
> 
> If it’s an option for you, I’d suggest installing over Ethernet.
> 
Unfortunately, it is not.

> > I went to manual install, network wifi and successfully entered a
> > wpa_supplicant.conf and connected (ping -c 3 gnu.org)
> >
> > I think the script's wpa_supplicant.conf is missing some
> > parameter.  How do I specify that, or break out of the script to
> > connect to the network manually and then return?
> 
> What does ‘wpa_supplicant.conf’ contains?

This is what I copied from my working system (mimicing the instruction
parameters)  was:

network={
ssid="XXX"
psk=""
proto=WPA
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP
}


The 'manual instructions' say to make a wpa_supplicant.conf :

excerpt--

nano wpa_supplicant.conf

As an example, the following stanza can go to this file and will work
for many wireless networks, provided you give the actual SSID and
passphrase for the network you are connecting to:

network={
  ssid="my-ssid"
  key_mgmt=WPA-PSK
  psk="the network's secret passphrase"
}

end excerpt---

note two keys not instructed, which I can only presume means they are
not in the gui script's wpa_supplicant.conf file and are needed by the
hot spot I am connecting to.  If I could edit this before the gui
script begins (installing the iso off my memory stick) this might do
the trick.

Does this help?

Thanks