Re: Multiple profiles with Guix Home

[Maxime Devos]

Liliana Marie Prikler schreef op wo 04-05-2022 om 06:23 [+0200]:
> > Also, this sounds like adding a new feature (multiple profiles for
> > Guix Home) at cost of an extra (known) bug (these multiple profiles
> > don't share search paths).
> Hyrum's Law might also come in play here.

... how can an user come to depend on internals that do not yet exist?
Also, Hyrum's Law only says that assumptions about the implementation
will eventually be made, not that these assumptions can't be broken
later.

Greetings,
Maxime.


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

Re: Multiple profiles with Guix Home

[Maxime Devos]

Liliana Marie Prikler schreef op wo 04-05-2022 om 06:16 [+0200]:
> > Until the previous mail, I have not seen anything about thematic
> > profiles, so I did not have thematic profiles in mind in my
> > response.
> > Even then, I'm not sure what these thematic profiles are supposed
> > to
> > solve that is not working around some underlying problem (e.g. slow
> > profile building times).
> Pierre's "Guix Profiles in Practice" is a 2.5 years old blog post. 
> If
> you can't think of any uses for multiple profiles, you're not the
> target audience at this point.
> 

I have seen that blog post.  I do use profiles, albeit with "guix
environment" and now "guix shell".  But I have not yet seen any reasons
for profile _splitting_.  And if I'm not the target audience, what does
that matter?

Greetings,
Maxime.


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

Re: Multiple profiles with Guix Home

[Maxime Devos]

Maxime Devos schreef op wo 04-05-2022 om 09:01 [+0200]:
> But I have not yet seen any reasons
> for profile _splitting_.

TBC, I mean splitting into seperate profiles in $GUIX_EXTRA_PROFILES
here, not "guix shell"/manifest.scm-style separate profiles.

Greetings,
Maxime.


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

Re: Updating mumi on berlin

[zimoun]

Hi,

On Tue, 03 May 2022 at 17:42, Thiago Jung Bauermann  
wrote:
> zimoun  writes:
>
>> Instead of subscription, public-inbox provides the archives as a Git
>> repo.  Therefore, being up to date just becomes “guix pull” and the Git
>> repo can be transformed to Maildir using e.g.,
>>
>> $git rev-list  | while read sha; do
>>  $git show $sha:m > /new/$sha
>> done
>>
>> (modulo some errors for deleted messaged, another story).
>
> Just an aside about public-inbox: Starting with version 0.7 it ships
> with a ‘lei’ tool that can be used to query a local or remote
> public-inbox repo, and export the matching messages to a maildir.

Thanks.  Maybe I am missing something, “guix show public-inbox” tells
version 1.6.1 but I do not find ’lei’.  Anyway.

That’s why I used this ugly loop. ;-)


> So the above would become something like:
>
> $ lei q -o  -I  -t 
>
> The maildir can even be updated later with newer messages matching the
> query with:
>
> $ lei up 

Yes, I agree ’lei’ is cool.  For instance, it allows to filter (and thus
follow), e.g., let query for the patches submitted the last 3 months to
’gnu/packages/bioinformatics.scm’ touching R packages,

dfn:gnu/packages/bioinformatics AND b:r-build-system AND rt:3.months.ago..

where

   dfn: match filename from diff
   b:   match within message body, including text attachments
   rt:  match date-time range, git "approxidate" formats supported
Open-ended ranges such as `d:last.week..' and `d:..2.days.ago'
are supported



Then, ’lei up’ will request the public-inbox server for this query and
will download the messages if any.


Cheers,
simon

Re: Mumi, public-inbox and tools

[zimoun]

Hi Arun,

On Tue, 03 May 2022 at 23:20, Arun Isaac  wrote:

>> of public-inbox via yhetil.org/guix and the piem glue?
>
> I haven't thought carefully about public-inbox integration. But, if we
> can do everything in mumi, do we need public-inbox at all?

Well, some advantages I see after using a bit the public-inbox instance
 mirroring some lists.

1. The web interface,

  a) works well with “poor“ web browser as EWW
 (whereas I prefer Mumi with full featured browser ;-))
  b) show the complete thread
  c) powerful and quick search

2. The local mirror,

  a) ‘git pull’, so do not pollute my email inbox   
  b) I pull and so read whenever I want, not when messages are
delivered
  c) I index and read using whatever fits my workflow
  d) the public-inbox server provides NNTP for Gnus folks

3. Bridge the present with the past

  assume I start to follow guix-devel on Wed, 30 Mar 2022

  and I locally read with my favorite Email reader this message:
  

  I am interested and I would like to know more:
  a) I can read using my web browser
  b) I can download the complete thread and read offline
 (it requires some glue code, as ’lei’ or ’piem’; IIUC)

Using the “official” interface, it is really boring.  For instance, I
read this message
,
then one needs some motivation to find the message of this reply; since
it had not been sent the same month.


Mumi is about bugs and another interface for Debbugs.  Therefore, we
cannot do everything with Mumi. ;-)

Maybe, what could help, IMHO, would to have the various Guix mailing
lists as public-inboxes under, say https://lists.guix.gnu.org and Mumi
could use this instance, eventually, or bridge.  The aim would be a
flexible interface but still uniform.

And I do not speak about other tools from the ecosystem as B4,




Cheers,
simon

Re: Multiple profiles with Guix Home

[Maxime Devos]

Maxime Devos schreef op di 03-05-2022 om 22:44 [+0200]:
> Liliana Marie Prikler schreef op di 03-05-2022 om 22:04 [+0200]:
> > > Also, why would the user need to split things, couldn't Guix do
> > > that
> > > automatically?
> > Oh, sure, I'll just train a machine learning model to partition
> > packages into profiles.  This will obviously be better than a human
> > figuring things out, because machines can't fail ever.
> > 
> > In case the above wasn't clear enough, I'd rather leave this
> decision
> > to the user along with the decision of whether or not to waste
> > electricity in training an artificial intelligence.  Offering a
> > declarative interface to profile splitting benefits everyone here.
> 
> I did not suggest any machine learning or AI?  Also, how can a
> machine
> fail here?  The computed partitioning might not be optimal, but as
> long
> as we're careful with search paths and its not overly suboptimal, any
> partititioning would do (in the sense that it doesn't ‘lose’ packages
> or invent packages oout of thin air or something).

Nevermind, see ‘thematic profiles’.

Greetings,
Maxime.


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

Re: Multiple profiles with Guix Home

[Maxime Devos]

Liliana Marie Prikler schreef op wo 04-05-2022 om 06:23 [+0200]:
> Am Dienstag, dem 03.05.2022 um 23:11 +0200 schrieb Maxime Devos:
> > Liliana Marie Prikler schreef op di 03-05-2022 om 22:04 [+0200]:
> > > That's why I say the long-term goal is evaluating search paths over
> > > multiple profiles.  However, given that Guix Home is currently a
> > > technological preview and given on top that multiple profile
> > > support is "write your own shell script, will ya?", I think we can
> > > leave that as a nice to have for later.
> > 
> > In practice, ‘nice to have later’ becomes virtually never, see e.g.
> > not building dependencies again and again and not having to build
> > dozens of variants of a package (go-build-system (*) and cargo-build-
> > system (**). As such, I'd rather have ‘now’.
> In practice, this is still not a blocker, because extra inputs for
> search paths affect neither the purity nor the union-build much.

... I did not say anything about purity or union-build here?
Search paths are independent of union-build.

Greetings,
Maxime.


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

Re: abjad 3.6 and python 3.10

[zimoun]

Hi,

On Fri, 25 Mar 2022 at 20:18, jgart  wrote:

> When will guix master branch see python 3.10 more or less?

Who knows? ;-)

Well, if you have python@3.10 packaged then you could use a
package transformation.

In ’(guix build-system python)’, you have ’package-with-explicit-python’
where you can replace the Python VM.  Somehow, you could write something
along these lines,

--8<---cut here---start->8---
(define-public python-3.10
  (package
(inherit python-3.9)
...
))

(define package-with-python-3.10
  (package-with-explicit-python python-3.10
"python-" "python3.10-"
#:variant-property 'python-variant))

(define-public python-abjad
  (package-with-python-3.10
   (package
 (name "python-adjad")
 ...
 )))
--8<---cut here---end--->8---

*Warning*: it will “recompile” all the Python dependents using the
 Python VM v3.10 so it could be some CPU.


BTW, maybe we could provide ’python-next’ pointing to whatever new
Python release.  It would ease the upgrade, IMHO.


Cheers,
simon

Re: emacs-company-jedi BUG

[zimoun]

Hi,

On Thu, 24 Mar 2022 at 22:56, jgart  wrote:

> Just leaving this here as a reminder to work on this soon and to get
> thoughts from the community.

Maybe you could open a bug report to act as such.  If you have not done
already.

Cheers,
simon

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2022-05-03 20:34, Liliana Marie Prikler wrote:

> Am Dienstag, dem 03.05.2022 um 17:13 +0300 schrieb Andrew Tropin:
>> On 2021-10-03 12:50, Liliana Marie Prikler wrote:
>> 
>> > Hi Guix,
>> > 
>> > it's been a while since the discussion of whether or not to collect
>> > multiple profiles into a single directory [1].  This suggestion
>> > takes inspiration from that, but goes a vastly different route. 
>> > Instead of using environment variables to control Guix, it takes
>> > advantage of the recently added Guix Home, even if it is still a
>> > technical preview.
>> > 
>> > So, what's the proposition?  I suggest we modify home-profile-
>> > service-type (or add a new service) such that it takes a list of
>> >  records instead of a list of packages.  This record
>> > would be defined as
>> > 
>> >   (define-record-type*  home-profile
>> >     make-home-profile home-profile? this-home-profile
>> >     (location home-profile-location) ; string, e.g. $HOME/.guix-
>> > profile
>> >     (short-name home-profile-short-name) ; string or #f, if given
>> >  ; construct a symlink in
>> >  ; /var/guix/.../per-user/
>> >     (manifest %home-profile-manifest) ;  or #f
>> >     (packages home-profile-packages) ; list of  or #f
>> >  ; fallback for manifest
>> >     (enabled? home-profile-enabled?) ; boolean, default #t
>> >     [...])
>> > 
>> >   (define (home-profile-manifest home-profile)
>> >     (or (%home-profile-manifest home-profile)
>> >     (and=> (home-profile-packages home-profile) 
>> >    packages->manifest
>> > 
>> > On init/reconfigure, `guix home' creates/updates all home-profiles
>> > which have a home-profile-manifest that is not #f and links them to
>> > the appropriate locations.  It also creates a shell startup script
>> > that loads those profiles that are enabled?, even if they have no
>> > manifest (this can be used to e.g. declare a pull profile, which
>> > `guix home' can't manage).  
>> > 
>> > Some existing home services would need to be adapted towards this
>> > multiple profile usage.  For instance, home-fontconfig-service-type
>> > would need to accept a list of directories, rather than hardcode
>> > its value.
>> > 
>> > What do y'all think?
>> > 
>> > <
>> > https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html
>> > >
>> > 
>> > 
>> 
>> It seems doable, but not sure about costs and benifits.
> Glad I have your attention now :)
>
> Depending on your use the time spent building `guix home' could go up
> or down.  If you simply add more profiles to it, that'll be an increase
> in cost, same if you don't make use of the feature at all due to the
> time spent field sanitizing.  If you do split your home in multiple
> profiles however, you will benefit from faster union builds, which
> themselves have quadratic complexity as a lower bound.
>

Yep, I already face some relatively long builds of profiles, I don't
remember when I started to face it, but splitting into a few independent
profile can make the situation better, need to experiment with it.

>> Also, cross-profile package installation can be error-prone, for
>> example if user install an emacs in main profile and emacs packages
>> in emacsy profile we will end up in a situation, where those emacs
>> package aren't available in Emacs.  Probably some other issues will
>> become clearer during implementation.
> The solution to that would be evaluating the search paths over all
> enabled packages.

It won't work if we have "managed outside" profiles and overall seems
quite fragile.

> However, I do think it's fine to do as we did before
> for now; people are already used to this aspect of Guix, but the fact
> that they need to code up their own shell wrappers to manage multiple
> profiles is not good optics imo.

Sounds reasonable.

>> Another idea I have in mind is to make such profiles (including guix
>> home's main profile) detached from ~/.config/guix/current.  For
>> example by providing channels specification as a part of > profile>.  It will make it possible to freeze a costly-to-rebuild
>> profile at a given channels revisions and not to rebuild it, when the
>> main profile and channels for it get updated.
> I don't think that's meaningful.  For one, time-machine exists, for the
> other you can directly use inferiors in code.  With profiles managed by
> Guix Home, you could even make it so that said inferiors are "globally"
> managed.  I don't think a manifest consisting of inferior packages only
> would require rebuilding.  

I had some issues with inferiors previously, but will see, maybe it will
work for me.

> Another dirty hack would be to have the manifest evaluate to #f when
> you don't want to update it – as per my specification it will in that
> case be assumed that you're manually managing it.  Then all you need to
> control when to build it is a smart binding of environmen

Re: Multiple profiles with Guix Home

[Reza Housseini]

On 5/4/22 09:01, Maxime Devos wrote:

Liliana Marie Prikler schreef op wo 04-05-2022 om 06:16 [+0200]:

Until the previous mail, I have not seen anything about thematic
profiles, so I did not have thematic profiles in mind in my
response.
Even then, I'm not sure what these thematic profiles are supposed
to
solve that is not working around some underlying problem (e.g. slow
profile building times).

Pierre's "Guix Profiles in Practice" is a 2.5 years old blog post.
If
you can't think of any uses for multiple profiles, you're not the
target audience at this point.


I have seen that blog post.  I do use profiles, albeit with "guix
environment" and now "guix shell".  But I have not yet seen any reasons
for profile _splitting_.  And if I'm not the target audience, what does
that matter?

Greetings,
Maxime.


A specific use case for profile splitting I see very useful, is e.g. 
having a profile with all your editor and plugin dependencies and your 
project specific dependencies. So if you work on a specific project you 
can merge the two profiles and your linters will not complain about 
missing dependencies.


I can also imagine more fine grained splitting, for example test and 
documentation dependencies in separate profiles or even unit test and 
integration test dependencies split into separate profiles.


At the moment I see no possibilities for even the "easy" use case I 
mentioned first.


Cheers,

Reza



OpenPGP_0xC375C6AF05125C52.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Multiple profiles with Guix Home

[Maxime Devos]

Reza Housseini schreef op wo 04-05-2022 om 15:15 [+0200]:
> A specific use case for profile splitting I see very useful, is e.g. 
> having a profile with all your editor and plugin dependencies and
> your 
> project specific dependencies. So if you work on a specific project
> you 
> can merge the two profiles and your linters will not complain about 
> missing dependencies.

That's a use case, but this appears to be already implemented by "guix
shell [-m manifest.scm]"?  Though I suppose there's a use case for
putting the manifests outside the project source code ...

Greetings,
Maxime.


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

Re: Guix System on RockPro64

[Tom Fitzhenry]

On 4/5/22 04:53, Tobias Platen wrote:

I had a look at the guix page, there is a latest version image for the
PineBook Pro, which uses the same SoC.
The SoC is the same, but the PineBook Pro and RockPro64 have different 
u-boot bootloaders: u-boot-rockpro64-rk3399-bootloader and 
u-boot-pinebook-pro-rk3399-bootloader, both in gnu/bootloader/u-boot.scm .


I have attached the image config that I used to build a RockPro64 image 
last week. See below for my plans to upstream.



Unfortunately I was unable to
find the reciepe to build that image. The guix page is currently down,
I will try again tomorrow.


FWIW, the PineBook Pro image is at gnu/system/images/pinebook-pro.scm


Today I was able to install guix on top of
Debian which I have installed on my RockPro64.


That should be useful, to be able to build aarch64 images without having 
to do cross-compilation.



However, it's inconvenient that each aarch64 platform needs its own 
aarch64 image. To improve on this, I'm working on Tow-Boot[0] support 
for Guix. The result is that a single generic aarch64 image will work 
across all Tow-Boot supported devices[1], including the RockPro64.


0. https://tow-boot.org/
1. https://tow-boot.org/devices/index.htmlcommit 397ee4242238905c8c1071aff6d345c600a709d6
Author: Tom Fitzhenry 
Date:   Mon Apr 25 16:51:52 2022 +1000

add rockpro64 image

diff --git a/gnu/system/images/rockpro64.scm b/gnu/system/images/rockpro64.scm
new file mode 100644
index 00..d03b4b90de
--- /dev/null
+++ b/gnu/system/images/rockpro64.scm
@@ -0,0 +1,69 @@
+
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2021 Marius Bakke 
+;;;
+;;; 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 .
+
+(define-module (gnu system images rockpro64)
+  #:use-module (gnu bootloader)
+  #:use-module (gnu bootloader u-boot)
+  #:use-module (gnu image)
+  #:use-module (gnu packages linux)
+  #:use-module (gnu platforms arm)
+  #:use-module (gnu services)
+  #:use-module (gnu services base)
+  #:use-module (gnu services networking)
+  #:use-module (gnu system)
+  #:use-module (gnu system file-systems)
+  #:use-module (gnu system image)
+  #:use-module (srfi srfi-26)
+  #:export (rockpro64-barebones-os
+rockpro64-image-type
+rockpro64-barebones-raw-image))
+
+(define rockpro64-barebones-os
+  (operating-system
+(host-name "jiehkkevarri")
+(timezone "Europe/Oslo")
+(locale "en_US.utf8")
+(bootloader (bootloader-configuration
+ (bootloader u-boot-rockpro64-rk3399-bootloader)
+ (targets '("/dev/sda"
+(initrd-modules '())
+(kernel linux-libre-arm64-generic)
+(file-systems (cons (file-system
+  (device (file-system-label "my-root"))
+  (mount-point "/")
+  (type "ext4"))
+%base-file-systems))
+(services (append (list (service dhcp-client-service-type))
+  %base-services
+
+(define rockpro64-image-type
+  (image-type
+   (name 'rockpro64-raw)
+   (constructor (cut image-with-os
+ (raw-with-offset-disk-image (expt 2 24))
+ <>
+
+(define rockpro64-barebones-raw-image
+  (image
+   (inherit
+(os+platform->image rockpro64-barebones-os aarch64-linux
+#:type rockpro64-image-type))
+   (name 'rockpro64-barebones-raw-image)))
+
+rockpro64-barebones-raw-image

Re: Guix System on RockPro64

[Vagrant Cascadian]

On 2022-05-04, Tom Fitzhenry wrote:
> On 4/5/22 04:53, Tobias Platen wrote:
>> I had a look at the guix page, there is a latest version image for the
>> PineBook Pro, which uses the same SoC.
> The SoC is the same, but the PineBook Pro and RockPro64 have different 
> u-boot bootloaders: u-boot-rockpro64-rk3399-bootloader and 
> u-boot-pinebook-pro-rk3399-bootloader, both in gnu/bootloader/u-boot.scm .
...
> However, it's inconvenient that each aarch64 platform needs its own 
> aarch64 image.

You could create a "generic" image that supports UEFI or standard u-boot
methods, and the user can bring-their-own UEFI implementation
(e.g. tianocore, recent versions of u-boot with EFI) or install u-boot
or barebox or whatever manually.

Another approach used by debian-installer images is to ship the image
that is used by all the platforms, and then a small firmware portion
that is device-specific:

  
https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/README.concatenateable_images

It's a little more cumbersome to download two images and dump them onto
the media, although I imagine guix could implement this part and make it
relatively simple, while still having a shared substitute for the bulk
of the image.


> To improve on this, I'm working on Tow-Boot[0] support 
> for Guix. The result is that a single generic aarch64 image will work 
> across all Tow-Boot supported devices[1], including the RockPro64.
>
> 0. https://tow-boot.org/
> 1. https://tow-boot.org/devices/index.html

My understanding was tow-boot was mostly, at this point, something to
avoid installing as part of the distro image. You can basically do the
same thing with mainline u-boot, if you install u-boot to media other
than the distro media. Or does tow-boot have fancier features working
yet (e.g. menu interfaces from the firmware) ?


> +(initrd-modules '())
> +(kernel linux-libre-arm64-generic)

I've managed to get the default linux-libre working, installed with
rootfs on SATA. It does require a fairly extensive list of modules to
load in the initrd:

  (kernel linux-libre-5.17) ;; from before it was default
  (initrd-modules
   (append  
(list
 ;; scsi modules
 "ahci"
 "libata"
 "sd_mod"
 "scsi_common"
 "t10_pi"
 ;; regulators and clocks
 "rk808-regulator"
 "clk-rk808"
 "fixed"
 "fan53555"
 "rk808"
 "i2c-rk3x"
 "pl330"
 "dwc3"
 "rtc-rk808"
 "sdhci"
 "sdhci-pltfm"
 "dw_mmc"
 "dw_mmc-pltfm"
 ;; "dw_mmc-rockchip"
 "phy_rockchip_pcie"
 "pcie_rockchip_host"
 "nvme")))

I've recently noticed it taking a long time on shutdown or reboot with
"dw_mmc_rockchip" still loaded, but I don't use the mmc bus for anything
other than the bootloader itself installed on microSD. If you're using
microSD or eMMC I'd be curious if that still happened.


Although using the generic kernel, with guix's primitive module handling
from the initrd (essentially looping through the list and manually
loading each one), it might be easier to support a single image with
linux-libre-arm64-generic kernel, where most features are built-in
rather than modular.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Multiple profiles with Guix Home

[zimoun]

Hi,

On Wed, 04 May 2022 at 15:46, Maxime Devos  wrote:

> That's a use case, but this appears to be already implemented by "guix
> shell [-m manifest.scm]"?  Though I suppose there's a use case for
> putting the manifests outside the project source code ...

Well, I miss two things: for one, ’guix shell’ creates a temporary
profile and thus not protected from GC so it can be boring to create
again and again the same profile depending on the frequency you are
working on the project vs the frequency “guix gc” is run.  For two,
’guix shell’ does not guarantee the exact same profile depending if
’guix pull’ had been run in between.

Therefore, many use cases seem around, no?

Otherwise, even ~/.guix-profile is not useful at all since all could be
done with:

guix time-machine -C channels.scm -- shell -m manifest.scm

(what I do more than often ;-) but not protected from GC either).

For practical reasons, it seems easier to create some profiles and
“load” them (compose?) when required.


Cheers,
simon

Re: Multiple profiles with Guix Home

[Maxime Devos]

zimoun schreef op wo 04-05-2022 om 20:14 [+0200]:
> Well, I miss two things: for one, ’guix shell’ creates a temporary
> profile and thus not protected from GC so it can be boring to create
> again and again the same profile depending on the frequency you are
> working on the project vs the frequency “guix gc” is run.  For two,
> ’guix shell’ does not guarantee the exact same profile depending if
> ’guix pull’ had been run in between.
> 
> Therefore, many use cases seem around, no?

The second point is also the case when Guix Home is used.
And at least in some situations, "guix shell" makes GC roots --
guix/scripts/shell.scm has a comment

;; Attempt to compute a file name for use as the cached profile GC root.

.  Maybe not in a sufficient amount of situations though.

Greetings,
Maxime.


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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Mittwoch, dem 04.05.2022 um 09:01 +0200 schrieb Maxime Devos:
> I have seen that blog post.  I do use profiles, albeit with "guix
> environment" and now "guix shell".  But I have not yet seen any
> reasons for profile _splitting_.  
That's nice for you, but don't take that to mean that no one has any
reason to do so ever.  I personally have my Guix profile already split
across several manifests, that could easily fit into separate profiles
if Guix didn't make working with those an absolute pain.

> And if I'm not the target audience, what does that matter?
It matters because it makes part of your complaint basically "fuck your
use case, mine's already satisfied" (pardon my French).  As for the
other point, which is tangential issues remaining, those deserve fixing
too, but they're not the point of this debate.  Particularly w.r.t.
evaluating search paths across multiple profiles, we already have an
instance of that even without allowing users to specify multiple
profiles easily.  Thus we not only can think about them as different
matters, we should even derive solutions that work outside the context
of guix home!

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

Liliana Marie Prikler schreef op wo 04-05-2022 om 20:38 [+0200]:
> Am Mittwoch, dem 04.05.2022 um 09:01 +0200 schrieb Maxime Devos:
> > I have seen that blog post.  I do use profiles, albeit with "guix
> > environment" and now "guix shell".  But I have not yet seen any
> > reasons for profile _splitting_.  
> That's nice for you, but don't take that to mean that no one has any
> reason to do so ever. 

I don't.

> I personally have my Guix profile already split
> across several manifests, that could easily fit into separate profiles
> if Guix didn't make working with those an absolute pain.

... but separate profiles = separate manifests (except when using "guix
install")?

> > And if I'm not the target audience, what does that matter?
> It matters because it makes part of your complaint basically "fuck your
> use case, mine's already satisfied" (pardon my French).

This was not my complaint.  There are a lot of cool use cases there,
though for whatever reason they were not mentioned in the original e-
mal, so I had to ask what the use cases were.  And FWIW, mine is not
satisfied, profile building is still occassionally a bit on the slow
side.

What is my concern, is that most use cases I have seen mentioned seem
like they can be addressed without extra configuration or records or
manual steps and independently of Guix Home: slow union-build -> make
it faster (linear or at least O(n lg n)), per-project packages -> use
"guix shell -m manifest.scm", things change after "guix pull" -> Guix
Home doesn't solve this(?).  

So except for ‘guix shell maybe doesn't create GC roots sufficiently
often’ and ‘keep things tidy and separate’ (though the latter appears
to be already done by "guix shell"?), I don't see why we need some Guix
Home-specific manual configuration and complexity when we can have some
automatic general optimisations instead.

> As for the
> other point, which is tangential issues remaining, those deserve fixing
> too, but they're not the point of this debate.  Particularly w.r.t.
> evaluating search paths across multiple profiles, we already have an
> instance of that even without allowing users to specify multiple
> profiles easily.  Thus we not only can think about them as different
> matters, we should even derive solutions that work outside the context
> of guix home!

I don't understand this paragraph, weren't these issues the whole
reason for introducing this manual configuration thing?  (And the
thematic profile, which is not tangential IIUC.)

Greetings,
Maxime


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

Re: Updating mumi on berlin

[Kyle Meyer]

zimoun writes:

> On Tue, 03 May 2022 at 17:42, Thiago Jung Bauermann  
> wrote:
[...]
>> Just an aside about public-inbox: Starting with version 0.7 it ships
>> with a ‘lei’ tool that can be used to query a local or remote
>> public-inbox repo, and export the matching messages to a maildir.
>
> Thanks.  Maybe I am missing something, “guix show public-inbox” tells
> version 1.6.1 but I do not find ’lei’.  Anyway.

Yes, Thiago must have meant to write 1.7, not 0.7.

I've tried sit down and update Guix's public-inbox definition a few
times, but there are various test failures that I didn't figure out how
to handle in the time I had.  (IIRC, I think they're related to the lei
tests expecting to be able to kill the lei-daemon process, which isn't
the case in Guix's build environment.)

Re: Guix System on RockPro64

[Tom Fitzhenry]

On Thu, 5 May 2022, at 2:14 AM, Vagrant Cascadian wrote:
> You could create a "generic" image that supports UEFI or standard u-boot
> methods, and the user can bring-their-own UEFI implementation
> (e.g. tianocore, recent versions of u-boot with EFI) or install u-boot
> or barebox or whatever manually.

Yes, this is the idea behind Tow-Boot. Tow-Boot is an opinionated build of 
u-boot that implements enough of EFI to be able to boot a generic UEFI image.

The same image would work for any aarch64 device supporting EFI: via Tianocore, 
via Tow-Boot, via ARM BBR, ...

I intend to write this up in more detail with my patches.

> My understanding was tow-boot was mostly, at this point, something to
> avoid installing as part of the distro image. You can basically do the
> same thing with mainline u-boot, if you install u-boot to media other
> than the distro media. Or does tow-boot have fancier features working
> yet (e.g. menu interfaces from the firmware) ?

Yes, the distro is not responsible for installing Tow-Boot on the SPI. If a 
user's device doesn't support EFI, and they want to install Tow-Boot on SPI, 
they would need to do that themselves (by following Tow-Boot's installation 
instructions). PostmarketOS are working on delivering Tow-Boot updates via 
LVFS: https://github.com/fwupd/fwupd/issues/4294

The only thing Guix needs to do is provide a generic aarch64 image that 
supports UEFI. I have something WIP for that.

Re: Updating mumi on berlin

[Thiago Jung Bauermann]

Kyle Meyer  writes:

> zimoun writes:
>
>> On Tue, 03 May 2022 at 17:42, Thiago Jung Bauermann  
>> wrote:
> [...]
>>> Just an aside about public-inbox: Starting with version 0.7 it ships
>>> with a ‘lei’ tool that can be used to query a local or remote
>>> public-inbox repo, and export the matching messages to a maildir.
>>
>> Thanks.  Maybe I am missing something, “guix show public-inbox” tells
>> version 1.6.1 but I do not find ’lei’.  Anyway.
>
> Yes, Thiago must have meant to write 1.7, not 0.7.

Indeed, that's what I meant. Sorry about the confusion.

> I've tried sit down and update Guix's public-inbox definition a few
> times, but there are various test failures that I didn't figure out how
> to handle in the time I had.

Me too. What I did while I can't move this forward was install in a
separate Guix profile a local package definition of public-inbox with
tests disabled. Then I run lei with:

$ guix shell -p path/to/profile -- lei up --all

> (IIRC, I think they're related to the lei tests expecting to be able
> to kill the lei-daemon process, which isn't the case in Guix's build
> environment.)

Yes, that's what I'm seeing as well. The lei-daemon process is actually
killed, but because of bug 30948 it is left in a zombie state and so the
testsuite thinks that it didn't go away.

The testsuite checks whether lei-daemon is gone by doing a
“kill(, 0)”, which unfortunately succeeds for zombie processes.

I've been meaning to add child reaping to the Guix builder process, but
I'm moving very slowly due to time constraints and my unfamiliarity with
that part of Guix...

-- 
Thanks
Thiago

¹ https://issues.guix.gnu.org/30948

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Mittwoch, dem 04.05.2022 um 22:41 +0200 schrieb Maxime Devos:
> 
> > I personally have my Guix profile already split
> > across several manifests, that could easily fit into separate
> > profiles if Guix didn't make working with those an absolute pain.
> 
> ... but separate profiles = separate manifests (except when using
> "guix install")?
This implication really only goes one way, i.e. separate profiles
require separate manifests.  Not that you can't specify multiple
manifests in one file, for instance, ...

> > 
> > > And if I'm not the target audience, what does that matter?
> > It matters because it makes part of your complaint basically "fuck
> > your use case, mine's already satisfied" (pardon my French).
> 
> This was not my complaint.  There are a lot of cool use cases there,
> though for whatever reason they were not mentioned in the original e-
> mail, so I had to ask what the use cases were.  And FWIW, mine is not
> satisfied, profile building is still occassionally a bit on the slow
> side.
> 
> What is my concern, is that most use cases I have seen mentioned seem
> like they can be addressed without extra configuration or records or
> manual steps and independently of Guix Home: slow union-build -> make
> it faster (linear or at least O(n lg n)), per-project packages -> use
> "guix shell -m manifest.scm", things change after "guix pull" -> Guix
> Home doesn't solve this(?).  
You are still debating the legitimacy of splitting ~/.guix-profile and
I don't want to entertain that discussion longer than it's worth.  Just
trust me that there are people, like myself, who *want* to split them.

> So except for ‘guix shell maybe doesn't create GC roots sufficiently
> often’ and ‘keep things tidy and separate’ (though the latter appears
> to be already done by "guix shell"?), I don't see why we need some
> Guix Home-specific manual configuration and complexity when we can
> have some automatic general optimisations instead.
> 
> > As for the other point, which is tangential issues remaining, those
> > deserve fixing too, but they're not the point of this debate. 
> > Particularly w.r.t. evaluating search paths across multiple
> > profiles, we already have an instance of that even without allowing
> > users to specify multiple profiles easily.  Thus we not only can
> > think about them as different matters, we should even derive
> > solutions that work outside the context of guix home!
> 
> I don't understand this paragraph, weren't these issues the whole
> reason for introducing this manual configuration thing?  (And the
> thematic profile, which is not tangential IIUC.)
No, the issues I'm describing is that certain things break when you use
a different profile at all.  For instance, you can't build a font
profile, because both Guix Homeless and Guix Home assume that you're
using their blessed profile to store fonts in.  Such issues can be
solved through configuration, i.e. allowing the user to specify "this
is my font profile and it has fonts".

Cheers

Re: RFC: Configurable placing of the ~/.guix-home symlink

[Andrew Tropin]

On 2022-04-29 11:44, EuAndreh wrote:

> Hi Guix!
>
> When trying to get a clean $HOME, I see that the ~/.guix-home path is fixed in
> the code under gnu/home/*,
> usually via (string-append (getenv "HOME") "/.guix-home").
>
> I want to propose a configurable path to ~/.guix-home, and allow this to be
> chosen in the (home-environment ...) declaration.  It would expose a
> GUIX_HOME_PATH_ENVIRONMENT variable[0] so that one could dynamically retrieve
> the path to it, if needed in scripts or similar.  The implementation would 
> also
> need to be able to handle changes in the (home-environment ...) declaration,
> and know when to remove the old symlink from ~/.guix-home to the new path,
> similar to what the gnu/home/services/symlink-manager.scm does nowadays.
>
> How do you feel about this?  What do you think?  Is there a shortcoming,
> pitfalls, limitations that this approach entails?
>
> I'm willing do work on the implementation and on tests where applicable, and
> send the patches (eventually when I get this done =p).  I wanted to raise a
> discussion before jumping into the code, even to get input and see how the
> community feels about this.
>
> WDYT?

Hi EuAndreh,

This feature was removed from Guix Home 10 months ago:
https://git.sr.ht/~abcdw/rde/commit/a4b3a93b88f29eb4b37695e04e0ca200184fec28

I don't remember all the reasons, but it was slightly problematic.  I'll
name a few things, which come to my mind:

- Due to implementation of guix services extension mechanism, it's
  necessary to pass the path to guix home directory to some services
  explicitly and instantiate them even if they not used.

https://git.sr.ht/~abcdw/rde/commit/a4b3a93b88f29eb4b37695e04e0ca200184fec28#gnu/home.scm-1-4

- It's hard to cleanup environment variables like PATH and similiar when
  GUIX_HOME_DIRECTORY changed.
  
- It was hard to know if and where the previous generation was
  installed, right now it can be easier, but some edge cases can pop up.
  For example if activation script called outside of `guix home
  reconfigure` or some other circumstances.

If I remember something else, I'll let you know.

I don't dissuade you, but not sure if abilitiy to move ~/.guix-home
around worth the hassle.  Aesthetically pleasant paths in the cost of
development and maintaining a feature, which affects and complicates
many places.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: RFC: Configurable placing of the ~/.guix-home symlink

[Attila Lendvai]

> When trying to get a clean $HOME, I see that the ~/.guix-home path is fixed in
> the code under gnu/home/*,
> usually via (string-append (GETENV "HOME") "/.guix-home").

FWIW, i was also surprised that the default is not something under 
~/.config/guix/

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