Re: Blog post: Guix/Hurd on Real Iron

[Tanguy LE CARROUR]

Hi Joshua,

Quoting jbra...@dismail.de (2024-11-27 20:41:44)
> It should work on Debian GNU/Hurd.  That's an option as well.

I downloaded the lastest Debian GNU/Hurd ISO and try to boot on
my Thinkpad… but it get stuck at "loading…" on a Debian 12 logo screen.

Was it supposed to work on real hardware or was I being overly optimistic?

--
Tanguy

Re: Blog post: Guix/Hurd on Real Iron

[Janneke Nieuwenhuizen]

> November 29, 2024 at 1:35 PM, "Janneke Nieuwenhuizen"  mailto:jann...@gnu.org?to=%22Janneke%20Nieuwenhuizen%22%20%3Cjanneke%40gnu.org%3E
>  > wrote:
>
>> 
>> > 
>> > November 27, 2024 at 8:41 AM, "Tanguy LE CARROUR" > > mailto:tan...@bioneland.org?to=%22Tanguy%20LE%20CARROUR%22%20%3Ctanguy%40bioneland.org%3E
>> >  > wrote:
>> > 
[..]
>> Debian GNU/Hurd is a pretty awesome*) system. It Just Works (TM).
>> That's were we got most of my inpiration from, did much of our debugging
>> on, got many of our patches from, and its developers have helped us
>> endlessly to make Guix/Hurd a thing.
>> 
>> I conisdered this a well known fact; do you think we should mention this
>> (more explicitly) in the blog post? If so, do you have a suggestion?
>
> I'm not sure.  I had also assumed that it was a well known fact that Debian
> GNU/Hurd is the most up to date and maintained Hurd distribion, with which 
> you 
> can run a desktop environment (XFCE) on bare metal.
>
> If you so chose to add a snippet or link to Debian GNU/Hurd, then perhaps you 
> could add this in a footnote (the choice is yours to make):
>
> While Guix GNU/Hurd has an exciting future, please be aware that it 
> lacks many packages and services, including Xorg.  If you simply must install
> the Hurd on bare metal running your favorite window manager (eg: i3, icewm, 
> etc.)
> or lightweight desktop environment (Xfce) this week, then Debian GNU/Hurd is 
> a good
> choice.  Though we hope to catch up to them soon!

Added as an addendum to the blog post, with slight modification and some
links.  Thanks!  Should be up in an hour or so.

> P.S.  Really nice work on the blog post!  It's always fun to see you leading
> the guix Hurd development effort! 

Thanks!
Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: Blog post: Guix/Hurd on Real Iron

[Janneke Nieuwenhuizen]

Suhail Singh writes:

> Janneke Nieuwenhuizen  writes:
>
>> I conisdered this a well known fact; do you think we should mention this
>> (more explicitly) in the blog post?  If so, do you have a suggestion?
>
> For what anecdotal evidence is worth, I didn't know about Debian
> GNU/Hurd till this email thread.

Thank you for your feedback.  I added an addendum to the blog post about
this.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: Some contributor stats

[Simon Tournier]

Hi Steve,

On Fri, 29 Nov 2024 at 16:22, Steve George  wrote:

> I just finished inviting contributors to take the Guix Survey

Nice!  And thanks for the numbers, cool!

Do you plan to release some figures or plots based on the survey?

Cheers,
simon

Are you interested in a new "patchsets" field for ?

[Nicolas Graves]

Hi Guix,

I've been trying to properly use the notion of patches above a channel,
and there are actually ways to make that work thanks to b4's
reproducible preprocessing of patch series / patchsets.  I know about
the wget help we know have on guix, but my point is broader here, I
wanted to have a tool for multiple channels, unregarding of the forge
they are using (sourcehut in particular works).

I seems quite doable to integrate this in main guix, but I'm not sure
guix developpers would be intersted in that, in which case I'll probably
put that in a new channel, with a  record or something
like that.

I think this could be of great value to any user that has trouble getting
some essential things merged into a project, but that still values the
reproducibility of what he does, without having its own guix fork online
(environmental reasons). My current use-case can be found at 
https://git.sr.ht/~ngraves/dotfiles/tree/main/item/channels.scm

-- 
Best regards,
Nicolas Graves

Re: Persistent heap usage when computing derivations

[Ludovic Courtès]

Hi Christopher,

Apologies for not answering earlier.

Christopher Baines  skribis:

> One of the memory problems I'm having relates to the Guix inferior
> processes that the data service uses when computing derivations. The
> data serivce goes through the list of systems (x86_64-linux,
> aarch64-linux, ...) and because the data cached for x86_64-linux
> probably doesn't relate to aarch64-linux, there's some code that
> attempts to clear the caches [1].
>
> 1: 
> https://git.savannah.gnu.org/cgit/guix/data-service.git/tree/guix-data-service/jobs/load-new-guix-revision.scm#n1970
>
> Unfortunately this code has to reach in to Guix internals to try and do
> this, and it does reduce the heap usage significantly, but this doesn't
> result in stable memory usage. Each system processed seems to add about
> 250MiB of data to the Guile heap that isn't cleared out. To me that
> sounds like a lot of memory, but there's also a lot of systems/targets,
> so overall this leads to the inferior process using with around 6GiB of
> data in the heap after processing all the systems/targets. This peak
> memory usage really limits how much the machine can do.

Did you consider running one inferior per system type, as a way to
sidestep the problem?

This is what ‘cuirass evaluate’ does and it manages to run typically 4
of them in parallel (x86_64-linux, i686-linux, aarch64-linux, and
powerpc64le-linux).  Memory usage may be high but at least it’s not a
blocker.

  
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/scripts/evaluate.scm#n137

Ludo’.

Re: Creating a C/C++ team?

[Ludovic Courtès]

Hi!

Liliana Marie Prikler  skribis:

> Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan:

[...]

>> This team would of course be distinct from the core-packages team,
>> which manages the most fundamental packages and challenging updates.
> I think there is a risk that this still overlaps with core-packages on
> the account of GCC being our main C/C++ toolchain.
>
> Note: while I'm already swamped with work on gnome and emacs, I would
> be interested in joining a hypothetical c++ team.
>
>> diff --git a/etc/teams.scm b/etc/teams.scm
>> index fe3291f914..e257650a04 100755
>> --- a/etc/teams.scm
>> +++ b/etc/teams.scm
>> @@ -611,0 +612,14 @@ (define-team zig
>> +(define-team c++
>> +  (team 'c++
>> +    #:name "C/C++ team"
>> +    #:description
>> +    "C and C++ compilers, libraries, tools, and programs"
> I would limit the scope to "libraries and tools".  That programs happen
> to be written in C/C++ is almost always incidental :)

Yes, the description could clarify that Greg wrote above, which is that
its scope is disjoint from that of the ‘core-packages’ team.

Ludo’.

guix package -i kicad will fait with #error "Unsupported CPU architecture" on my Talos II

[Tobias Alexandra Platen]

When I try to install Kicad, I'll get the following output:

The following derivations will be built:
  /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
0.5b6f8b5.drv
  /gnu/store/x26zsx3fw74vhfc35i79fansmlmhl0cc-libfabric-1.22.0.drv
  /gnu/store/nfj2qvhyxvfc7x5fkdlyg2z1wnpqw9cz-openmpi-4.1.6.drv
  /gnu/store/l1rbmwj9m4kgkm1qada665mm0m6g10w1-libngspice-43.drv
  /gnu/store/y88c48hzcm78ch39wjfa3dpdgw9n6m7r-webkitgtk-with-libsoup2-
2.44.1.drv
  /gnu/store/qv0zpz8h2dvhbmxz6smsbmc763rdkdxm-wxwidgets-3.2.5.drv
  /gnu/store/llydl3baxardzgf9xmdbgjikny68vaar-python-wxpython-4.2.0.drv
  /gnu/store/b0s2jgimknw6035kcqvpb6sdxkhakz7b-kicad-7.0.11.drv
  
After a few minutes the build fails with:

building /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
0.5b6f8b5.drv...
\ 'build' phasebuilder for
`/gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
0.5b6f8b5.drv' failed with exit code 1
build of /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
0.5b6f8b5.drv failed
View build log at
'/var/log/guix/drvs/5r/inv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
0.5b6f8b5.drv.gz'.

CC   utils/read_lat.o

#error "Unsupported CPU architecture"

I also found a blogpost which mentions libcxi, what does libcxi do?
https://hpc.guix.info/blog/2024/11/targeting-the-crayhpe-slingshot-interconnect/

I guess that libcxi is optional for Kicad, so I could hack guix to
build Kicad without libcxi.

Re: guix package -i kicad will fait with #error "Unsupported CPU architecture" on my Talos II

[Ian Eure]

Hi Tobias,

On Sat, Nov 30, 2024, at 8:18 PM, Tobias Alexandra Platen wrote:
> When I try to install Kicad, I'll get the following output:
>
> The following derivations will be built:
>   /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
> 0.5b6f8b5.drv
>   /gnu/store/x26zsx3fw74vhfc35i79fansmlmhl0cc-libfabric-1.22.0.drv
>   /gnu/store/nfj2qvhyxvfc7x5fkdlyg2z1wnpqw9cz-openmpi-4.1.6.drv
>   /gnu/store/l1rbmwj9m4kgkm1qada665mm0m6g10w1-libngspice-43.drv
>   /gnu/store/y88c48hzcm78ch39wjfa3dpdgw9n6m7r-webkitgtk-with-libsoup2-
> 2.44.1.drv
>   /gnu/store/qv0zpz8h2dvhbmxz6smsbmc763rdkdxm-wxwidgets-3.2.5.drv
>   /gnu/store/llydl3baxardzgf9xmdbgjikny68vaar-python-wxpython-4.2.0.drv
>   /gnu/store/b0s2jgimknw6035kcqvpb6sdxkhakz7b-kicad-7.0.11.drv
>  
> After a few minutes the build fails with:
>
> building /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
> 0.5b6f8b5.drv...
> \ 'build' phasebuilder for
> `/gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
> 0.5b6f8b5.drv' failed with exit code 1
> build of /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
> 0.5b6f8b5.drv failed
> View build log at
> '/var/log/guix/drvs/5r/inv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1-
> 0.5b6f8b5.drv.gz'.
> 
> CC   utils/read_lat.o
> 
> #error "Unsupported CPU architecture"
>
> I also found a blogpost which mentions libcxi, what does libcxi do?
> https://hpc.guix.info/blog/2024/11/targeting-the-crayhpe-slingshot-interconnect/
>

The package description provides a pretty good summary:

Interface to the Cassini/Slingshot high-speed interconnect

Libcxi provides applications with a low-level interface to the
Cray/HPE Cassini high-speed NIC (network interface controller), also
known as Slingshot.

> I guess that libcxi is optional for Kicad, so I could hack guix to
> build Kicad without libcxi.
>

I think this is worth a bug report, and maybe you're also up to sending some 
patches?  I think it's slightly more complicated than just the kicad package, 
though, since libcxi isn't a direct dependency:

$ guix graph --path kicad libcxi
kicad@7.0.11
libngspice@43
openmpi@4.1.6
libfabric@1.22.0
libcxi@1.0.1-0.5b6f8b5

So, I think what needs to happen is that libcxi needs to have POWER9 removed 
from its supported-systems field; and libfabric needs to conditionally include 
libcxi in its inputs based on architecture.  I think the best way to do that is 
by checking for the build system in (package-supported-systems libcxi), which 
will avoid hardcoding duplicate arch tests in two packages.

  -- Ian

Shepherd 1.0.0rc2 available for testing!

[Ludovic Courtès]

Hello Guix!

1.0.0rc2 is available for testing!  Compared to 1.0.0rc1, it fixes bugs
reported by Attila, Florian, Jelle, and Thomas, and adds ‘herd spawn
transient’, inspired by Efraim’s ‘shepherd-run’.  Will it be the final
release candidate?  Maybe, we’ll see!

The tarball and signature are available at:

  https://alpha.gnu.org/gnu/shepherd/shepherd-1.0.0rc2.tar.gz
  SHA256: 316c9ba8ce63bd9b59b1ff59c0cb40076c72140246b73516b31e5d5424db

  https://alpha.gnu.org/gnu/shepherd/shepherd-1.0.0rc2.tar.gz.sig

The tarball was built from v1.0.0rc2 (commit
6e740fbc4a48f6f41800e7ecfc312d6c99d3587b) and should be bit-for-bit
reproducible, hopefully for real this time (run “make dist” from
‘guix shell -CP’).


What’s new
==

Check out the ‘NEWS’ file to see what you might enjoy:

  https://git.savannah.gnu.org/cgit/shepherd.git/tree/NEWS


How to test
===

You could still a reference to the tarball above in your Guix checkout,
but the preferred way is probably to use Shepherd as a channel, as noted
in ‘README’:

The Shepherd repository can be used as a Guix “channel”.  To do that, change
~/.config/guix/channels.scm along these lines:

  (append (list (channel
 (name 'shepherd)
 (url "https://git.savannah.gnu.org/git/shepherd.git";;)
 (branch "main")
 (introduction
  (make-channel-introduction
   "788a6d6f1d5c170db68aa4bbfb77024fdc468ed3"
   (openpgp-fingerprint
"3CE464558A84FDC69DB40CFB090B11993D9AEBB5")
  %default-channels)

Once that is done, run ‘guix pull’.  This will give you additional ‘shepherd’
packages with higher version numbers:

  guix package -A shepherd

You can then install it with ‘guix install shepherd’, or e.g. use it in an
operating-system configuration:

  (operating-system
...
(essential-services
 (modify-services (operating-system-default-essential-services
   this-operating-system)
   (shepherd-root-service-type
config =>
(shepherd-configuration
 (inherit config)
 (shepherd (@ (shepherd-package) shepherd)))

To test with Guix Home:

  (home-environment
(services
 (list (service home-shepherd-service-type
(home-shepherd-configuration
  (shepherd (@ (shepherd-package) shepherd
   …)))


Testing the new services


Among the highlights of 1.0.0 are the new ‘system-log’ and
‘log-rotation’ services.  Testing them requires more changes to your
config but feedback would be welcome!

First, you can define these two services in your Guix System config:

  (define system-log-service-type
(shepherd-service-type
 'shepherd-system-log
 (const (shepherd-service
 (documentation "Shepherd's built-in system log (syslogd).")
 (provision '(system-log syslogd))
 (modules '((shepherd service system-log)))
 (free-form #~(system-log-service
 #t
 (description
  "Shepherd's built-in system log (syslogd).")))

  (define log-rotation-service
(simple-service 'shepherd-log-rotation
shepherd-root-service-type
(list (shepherd-service
   (provision '(log-rotation))
   (modules '((shepherd service log-rotation)))
   (free-form #~(log-rotation-service))

Then you can actually use one or both:

  (operating-system
;; …
(services (cons* log-rotation-service
 (service system-log-service-type)

 ;; …

 ;; Remove the currently-used syslogd service,
 ;; now redundant.
 (modify-services %desktop-services
   (delete syslog-service-type)


Reporting bugs
==

Please email bug-g...@gnu.org with “[Shepherd]” in the subject to report
bugs.


Translation
===

Consider helping with translation of messages at
.


Thanks in advance.  :-)

Ludo’.


signature.asc
Description: PGP signature

Re: shepherd: failing test: should `herd stop` stop a respawning process?

[Ludovic Courtès]

Hi Attila,

Attila Lendvai  skribis:

> ok, i've attached a stipped down version of the test case. it hopefully 
> reproduces the same situation i'm observing on my servers.
>
> which seems to be the following:
>
>   1. i have a service that keeps respawning (typically due to a config
>  mistake)
>
>   2. said service is upgraded/replaced in a `guix system reconfigure`
>
>   3. v1 of the service keeps respawning forever, and there's nothing i
>  can do to stop it at this point. `herd disable` operates on v2 of
>  the service, while some fiber, or some signal handler of v1 is
>  still in a respawn loop.

Thanks for the detailed bug report and test case.  It’s a pretty nasty
bug that you found here.

Commit 5fe594d593e6dcb19e23029bf3ff5f4a77a92523 should fix it.  Let me
know if you notice anything wrong!

Ludo’.