Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi again!

On Thu, Dec 15, 2022 at 03:53 PM, Ludovic Courtès wrote:

> Hello!
>
> John Kehayias  skribis:
>
>> First, let's dive right into a big one: the popular VSCodium editor. This is 
>> a freely
>> licensed build of VS Code: 
>> 
>>
>> This comes in AppImage format. Downloading it and making it executable (with 
>> a 'chmod
>> +x') I can run it in a container as
>>
>> guix shell -CNF -D ungoogled-chromium gcc:lib \
>>  --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY \
>>  --preserve='^DBUS_' --expose=/var/run/dbus \
>>  --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
>>  -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage 
>> --appimage-extract-and-run
>
> The code in that AppImage is free software, right?
>

The usual disclaimer of IANAL, but I linked to the part of their readme which 
describes the project licensing. So it seems all free to me, similar maybe to 
ungoogled-chromium: all the source without the telemetry and non-free branding, 
etc. But please do check.

>> Another example is to get the latest nightly builds of Rust, via 
>> 
>
> That’s a nice one too!
>
>> Happy to try other examples and to hear feedback on these!
>
> I think these are two good examples, likely to correspond to the kind of
> thing people may want to try.
>

Great, thanks!

>>> Actually you can use or get inspiration from this animated GIF if you
>>> like:
>>>
>>>   
>>>
>>
>> Either I forgot to save this or wasn't able to access it before, and can't 
>> access it
>> now.
>
> Yeah, the TLS setup on that machine is broken, so you’d have to “Accept
> the risk and continue”; I sent you a copy off-list.
>

Thank you. I included it but realize now I forgot to add credit, so I can do 
that later.

> If we release on Monday, it would be great to have it published…
> tomorrow (Friday).  Otherwise next Friday maybe?
>

It has gotten crazy here this week, hence my slow response (and not using my 
new found commit powers yet!). I've just sent the draft post which is the 
previous version with changes you suggested and a slightly expanded version of 
the examples from my previous message.



I did some manual tweaking to the markdown export but I think it should look 
okay. Wasn't sure about the footnotes or if that should just be in-text. Oh, 
and now realized may want it with a fill column rather than long lines. (It 
always wraps nicely on my Emacs setup so I forget.)

I should be able to make quick edits tomorrow (it is very late here now), but 
we don't need to rush if there are other changes or checks anyone wants to 
make. I can also record some screen grabs if that is helpful.

> Thanks!
>
> Ludo’.

Thanks for the input, wish I had some more time this past week to have gotten 
this done earlier.

John

cirrus (was Re: Release progress, week 10)

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> There are currently two installer bugs that I think now have a valid fix:
>
>   https://issues.guix.gnu.org/60010
>   https://issues.guix.gnu.org/59784

Sadly those are still not completely fixed…

That hold-up aside, maybe could you also tentatively add the cirrus
initrd module to the 1.4.0 installation image?  I suppose it won’t break
anything, but it might help with bugs like
.

Regards,
Florian

remove chezmoi since ancient?

[jgart]

hi, 

Should chezmoi be removed since the version we have is ancient?

The latest version will be a doozy bear to package and will probably not be 
done anytime soon?

all best,

jgart

https://whereis.みんな/

Re: File search

[Antoine R. Dumont (@ardumont)]

Hello,

As mentioned last week (on irc), I've improved a bit the implementation
as per the last discussions in the thread. Please, find enclosed the
patch with those changes (hopefully a tad better attached than last
time...).

Here is the rough changelog:

- The local db cache is now versioned. Migration will transparently
  happen for users at each index command calls (if need be).

  Note: Care should be taken by devs to provide the migration script
  step for each db schema bump (examples inside). The rest will happen
  on its own.

- The cli parsing got rewritten to be more flexible (inspired from
  existing code from guix, notably `guix home`).

- We can now choose the indexation method using the
  `--with-method={store|manifests}` flag. The "manifests" method is the
  default, seel the help message for more details).

- Finally, the indexation methods are displayed using a progress bar.

Heads up, I did not yet address the "output" part. Thanks @zimoun for
the clarification btw ;)

> In the package case, the number of packages is known ahead.

@civodul For the index 'store' implementation, ^ I did not find that
information.

So, as a costly implementation detail, I'm folding over all packages
first to know the total number of packages (for the progress bar). And
then another round trip to actually do the insert.

I don't like it at all. Plus, that number seems off to me (21696)
packages in regards to the number of packages indexed (522). So, if you
could have a rapid look to fix or tell me what's wrong, that'd be great.
I'm pretty sure it will hit you immediately (while i still do not find
it ¯\_(ツ)_/¯ ;).



Here is a rapid sample of the current command usage:

--8<---cut here---end--->8---
$ guix index --version
Extension local cache database:
- path: /home/tony/.cache/guix/index/db.sqlite
- version: 2

guix index (GNU Guix) 5ccb5837ccfb39af4e3e6399a0124997a187beb1
Copyright (C) 2022 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ guix index --with-method=store --db-path=/tmp/db/db.sqlite
Registering 21696 packages  [ ]

$ guix index search git
...
git-minimal@2.38.1   
/gnu/store/xf734fz3jihgc5x4979ypyaxn8aday1k-git-minimal-2.38.1/bin/git
git@2.38.1   
/gnu/store/wx965ym3c5fwbcdp7i9lvzad3479vv7m-git-2.38.1/libexec/git-core/git
git@2.38.1   
/gnu/store/wx965ym3c5fwbcdp7i9lvzad3479vv7m-git-2.38.1/etc/bash_completion.d/git
git@2.38.1
/gnu/store/wx965ym3c5fwbcdp7i9lvzad3479vv7m-git-2.38.1/bin/git

$ guix index --help
Usage: guix index [OPTIONS...] [search FILE...]
Without argument, indexes (package, file) relationships from the machine.
This allows indexation with 2 methods:

- out of the local manifests. This is the fastest implementation but this
indexes less packages. That'd be typically the use case for user local
indexation.

- out of the local store. This is slower due to implementation details (it
discusses with the store daemon for one). That'd be typically the use case for
building the largest db in one of the build farm node.

With 'search FILE', search for packages installing FILE.

Note: Internal cache is located at ~/.cache/guix/index/db.sqlite by default.
See --db-path for customization.

The valid values for OPTIONS are:

  -h, --help  Display this help and exit
  -V, --version   Display version information and exit
  --db-path=DIR   Change default location of the cache db

  --with-method=METH  Change default indexation method. By default it uses the
  local "manifests" (faster). It can also uses the local
  "store" (slower, typically on the farm build ci).
The valid values for ARGS are:

  search FILE Search for packages installing the FILE (from cache db)

   Without any argument, it index packages. This fills in the
  db cache using whatever indexation method is defined.
Report bugs to: bug-g...@gnu.org.
GNU Guix home page: 
General help using Guix and GNU software: 

--8<---cut here---end--->8---

Hope you'll find it mostly to your taste!

Note: I gather we'll rework the commits at some point (when it's ready)
so I did not bother too much right now.

Cheers,
--
tony / Antoine R. Dumont (@ardumont)

-
gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8

From d3e658ca1e3ce2715e25450b794d139d3417c74c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Wed, 30 Nov 2022 15:25:21 +0100
Subject: [PATCH 01/25] extensions-index: Add initial implementation from
 civodul

Related to https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00354.html
---
 

Re: Experimenting with reduced gcc-lib

[Julien Lepiller]

Le 15 décembre 2022 15:34:02 GMT+01:00, "Ludovic Courtès"  a 
écrit :
>Hello!
>
>Julien Lepiller  skribis:
>
>> Before the patch we get:
>>
>> guix size perl
>> total: 147.7 MiB
>>
>> After the patch:
>>
>> ./pre-inst-env guix size perl
>> total: 114.5 MiB
>
>Nice!
>
>> I don't want to push that patch as is, because libstdc++.so is still in
>> the gcc-static-lib output and will bring all the useless stuff with it.
>> C++ programs will bring back the remaining 33.2 MiB.
>
>It wouldn’t be worse than the current situation though?
>
>> Another possible target is glibc, since the only useful bits in there
>> are libc.so and ld-linux.so (I think?). This could reduce the closure
>> of our packs by another ~40 MiB (I think our systems would still need
>> most of the content of this package).
>
>‘share/i18n’ is 16 MiB and ‘lib/iconv’ is 8 MiB.  Now, separating them
>without introducing loss of functionality may be tricky.
>
>> From bff8567b0770455397d44f1ed304a67681b472c9 Mon Sep 17 00:00:00 2001
>> From: Julien Lepiller 
>> Date: Thu, 8 Dec 2022 22:29:01 +0100
>> Subject: [PATCH] gnu: gcc: Separate lib output.
>>
>> * gnu/packages/gcc.scm (gcc-4.7): Replace `lib' output with `static-lib'
>>   and `shared-lib'.
>> * gnu/packages/commencement.scm (gcc-boot0): Update accordingly.
>> ---
>>  gnu/packages/commencement.scm |  6 +++---
>>  gnu/packages/gcc.scm  | 39 +--
>>  gnu/tests/mail.trs|  0
>>  3 files changed, 31 insertions(+), 14 deletions(-)
>>  create mode 100644 gnu/tests/mail.trs
>
>Oops?

Oopsie :)

>
>> (outputs '("out";commands, etc. (60+ MiB)
>> -  "lib";libgcc_s, libgomp, etc. (15+ 
>> MiB)
>> +  "shared-lib" ;libgcc_s, libgomp, etc. (5+ MiB)
>> +  "static-lib" ;object code libraries and 
>> internal data files of GCC. (10+ MiB)
>
>The convention is to use “lib” for shared libraries and “static” for
>static libraries.

But using lib introduces a --libdir argument which is used to install static 
libs…

>
>Is libgomp in “lib”?  Is it found when linking with ‘-fopenmp’?

Well, shared-lib should be renaimed into libgcc, because it's the only library 
there.

Libgomp amd all other libs are in static-lib (which is not well named either 
^^'). It will be found I think but not tested (it find libstdc++ in the same 
directory).

>
>Thanks for this work; we really need to do something about package
>sizes!
>
>Ludo’.

Release progress, week 10

[Ludovic Courtès]

Hello Guix!

Here’s what may be the last update for the 1.4.0 release.

The second release candidate was released earlier a few days ago:

  https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00145.html

Thanks to everyone who tested and reported back!

There are currently two installer bugs that I think now have a valid fix:

  https://issues.guix.gnu.org/60010
  https://issues.guix.gnu.org/59784

I’m waiting for confirmation from Florian; kudos to Florian for
tirelessly testing the installer over the past few weeks!

Apart from that, there have been only 3 cosmetic commits since RC2.

If everything goes well, I plan to publish the release on Monday, 19th.
Time to get to your instrument for a release song or whatever other
performance you feel like making!  :-)

Ludo’.

Week 9: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00119.html
Week 8: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00034.html
Week 7: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00274.html
Week 6: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00161.html
Week 5: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
Week 4: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
Week 3: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00293.html
Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html


signature.asc
Description: PGP signature

Re: shepherd: prefix output with service names?

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> here is some output from “guix system reconfigure”:
>
> …
> activating system...
> The following derivation will be built:
>   /gnu/store/7361cd8aasxwwb93ygdfwjp3ghn06ahb-switch-to-system.scm.drv
>
> building 
> /gnu/store/7361cd8aasxwwb93ygdfwjp3ghn06ahb-switch-to-system.scm.drv...
> making '/gnu/store/rp04hkqlzx5j2lhxainsz77vpqqigsjz-system' the current 
> system...
> setting up setuid programs in '/run/setuid-programs'...
> populating /etc from /gnu/store/gq2dvz09wf3sdmvynr2vdzy5wwj7k9fd-etc...
> The files belonging to this database system will be owned by user "postgres".
> This user must also own the server process.
>
> The database cluster will be initialized with locale "en_US.utf8".
> The default database encoding has accordingly been set to "UTF8".
> The default text search configuration will be set to "english".
>
> Data page checksums are disabled.
>
> initdb: error: directory "/var/lib/postgresql/data" exists but is not empty
> If you want to create a new database system, either remove or empty
> the directory "/var/lib/postgresql/data" or run initdb
> with an argument other than "/var/lib/postgresql/data".
> Starting installation ...
> Validate installation settings ...
> Create file system structures ...
> Create self-signed certificate database ...
> Error: Instance creation failed!  Failed to start DS

These lines are produced by activation snippets; they don’t go through
shepherd.

> You see that there is output of tools that run as part of service
> activation snippets.  It is not clear which service is responsible for
> any particular line of output.
>
> What service produced the line “Error: Instance creation failed!  Failed
> to start DS”, for example?  I know it’s the directory-server-localhost
> service, because that’s what I’m working on right now, but it’s not
> clear from the output.
>
> What do you think of prefixing every line with the name of the service
> that is responsible for it?  This way we could probably also
> prettify/post-process the output somewhat.

I agree it would be great; it’s not related to shepherd though (shepherd
already does that).

Now, maybe some activation snippets could be moved to the ‘start’ method
of the corresponding service.  That is, instead of:

  (make-forkexec-constructor …)

you’d have:

  (lambda ()
(invoke …) ;run some initialization command here
(fork+exec-command …))

In some cases that may be more appropriate; as a bonus, it would solve
the logging problem since shepherd would log it correctly.

WDYT?

Ludo’.

Re: Hi from a new committer!

[Ludovic Courtès]

Howdy John!

John Kehayias  skribis:

> I'm pleased to announce that I have been granted commit access by the
> esteemed Guix maintainer collective! I'm looking forward to continuing
> to be a part of this wonderful community and helping review and push all
> the great patches waiting for their time to shine. As one that had to
> learn some patience with my first patches it is a priority for me to
> make this easier and better for everyone.

Welcome on board!!  It’s great to have you here, and it’s great to see
you mention patch review as part of your work—I think that’s a key
aspect of the position.

Thanks for joining!

Ludo’.

Re: branch core-updates updated: gnu: coreutils-boot0: Fix building on arm architectures.

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> On December 12, 2022 1:47:29 PM UTC, "Ludovic Courtès"  wrote:

[...]

>>> +   ,@(if (target-arm?)
>>> +   ;; Some binaries fail to build.
>>> +   `(#:configure-flags '(,(string-append
>>> +"--enable-no-install-program="
>>> +;; the defaults
>>> +"arch,coreutils,hostname"
>>> +;; fails on aarch64
>>> +",timeout,sort")))
>>
>>Isn’t there a risk that things will break down the road if ‘sort’,
>>‘hostname’, etc. are missing?  How hard would it be to address the build
>>failure instead?
>>
>>Thanks,
>>Ludo’.
>
> I built all the way out to hello without any problems. Also %final-inputs has 
> coreutils-final, so it really shouldn't be noticable.

That’s odd though.  Isn’t there some upstream patch we could take?
Surely ‘sort’ has no reason to contain arch-specific code?

If there’s no such patch, we can go with the patch above, but then there
should be a comment linking to bug reports and reassuring the reader
that yes, some packages do build even without these commands.  :-)

(There’s no “coreutils” command BTW, unless enabling the
everything-in-one-binary trick, no?)

Thanks,
Ludo’.

Re: Drafting a Guix blog post on the FHS container

[Ludovic Courtès]

Hello!

John Kehayias  skribis:

> First, let's dive right into a big one: the popular VSCodium editor. This is 
> a freely licensed build of VS Code: 
> 
>
> This comes in AppImage format. Downloading it and making it executable (with 
> a 'chmod +x') I can run it in a container as
>
> guix shell -CNF -D ungoogled-chromium gcc:lib \
>  --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY \
>  --preserve='^DBUS_' --expose=/var/run/dbus \
>  --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
>  -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage 
> --appimage-extract-and-run

The code in that AppImage is free software, right?

> Another example is to get the latest nightly builds of Rust, via 
> 

That’s a nice one too!

> Happy to try other examples and to hear feedback on these!

I think these are two good examples, likely to correspond to the kind of
thing people may want to try.

>> Actually you can use or get inspiration from this animated GIF if you
>> like:
>>
>>   
>>
>
> Either I forgot to save this or wasn't able to access it before, and can't 
> access it now.

Yeah, the TLS setup on that machine is broken, so you’d have to “Accept
the risk and continue”; I sent you a copy off-list.

If we release on Monday, it would be great to have it published…
tomorrow (Friday).  Otherwise next Friday maybe?

Thanks!

Ludo’.

Re: Experimenting with reduced gcc-lib

[Ludovic Courtès]

Hello!

Julien Lepiller  skribis:

> Before the patch we get:
>
> guix size perl
> total: 147.7 MiB
>
> After the patch:
>
> ./pre-inst-env guix size perl
> total: 114.5 MiB

Nice!

> I don't want to push that patch as is, because libstdc++.so is still in
> the gcc-static-lib output and will bring all the useless stuff with it.
> C++ programs will bring back the remaining 33.2 MiB.

It wouldn’t be worse than the current situation though?

> Another possible target is glibc, since the only useful bits in there
> are libc.so and ld-linux.so (I think?). This could reduce the closure
> of our packs by another ~40 MiB (I think our systems would still need
> most of the content of this package).

‘share/i18n’ is 16 MiB and ‘lib/iconv’ is 8 MiB.  Now, separating them
without introducing loss of functionality may be tricky.

> From bff8567b0770455397d44f1ed304a67681b472c9 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller 
> Date: Thu, 8 Dec 2022 22:29:01 +0100
> Subject: [PATCH] gnu: gcc: Separate lib output.
>
> * gnu/packages/gcc.scm (gcc-4.7): Replace `lib' output with `static-lib'
>   and `shared-lib'.
> * gnu/packages/commencement.scm (gcc-boot0): Update accordingly.
> ---
>  gnu/packages/commencement.scm |  6 +++---
>  gnu/packages/gcc.scm  | 39 +--
>  gnu/tests/mail.trs|  0
>  3 files changed, 31 insertions(+), 14 deletions(-)
>  create mode 100644 gnu/tests/mail.trs

Oops?

> (outputs '("out";commands, etc. (60+ MiB)
> -  "lib";libgcc_s, libgomp, etc. (15+ MiB)
> +  "shared-lib" ;libgcc_s, libgomp, etc. (5+ MiB)
> +  "static-lib" ;object code libraries and 
> internal data files of GCC. (10+ MiB)

The convention is to use “lib” for shared libraries and “static” for
static libraries.

Is libgomp in “lib”?  Is it found when linking with ‘-fopenmp’?

Thanks for this work; we really need to do something about package
sizes!

Ludo’.

Re: [PATCH guix-artwork v2] website: posts: Add Dissecting Guix, Part 1: Derivations.

[Ludovic Courtès]

Hello,

"("  skribis:

> * website/posts/dissecting-guix-1-derivations.md: New blog post.

Neat!  I think your plan for blog posts is really great; I’m sure it
will be of great use to many.

Perhaps we could schedule the first one a few days after the release
(which should be on Monday, 19th)?

And then schedule subsequent posts once per month or something?

Anyway, I like this first post!  Here are cosmetic suggestions:

> +These concepts were originally described by Eelco Dolstra, the author of 
> Nix, in

s/author/original author/

> +# `.drv` Files
> +
> +You've probably seen these being printed by the Guix CLI now and again.

Please avoid abbreviations; if you want to use them, you can write “Guix
command-line interface (CLI)” the first time and just “CLI” on
subsequent iterations.  Some abbreviations may look obvious to us, but I
think it’s important to reduce assumptions about what the reader already
knows, especially since the goal is to help them learn.

> +Derivations, represented in the daemon's eyes by `.drv` files, contain
> +instructions for building store items.  We can retrieve the paths of these
> +`.drv` files with the `guix build --derivations` command:

Perhaps you can add a paragraph showing package definitions, explaining
that they get “lowered” to derivations, but that packagers and users
only ever manipulate high-level objects such as packages or operating
systems, not derivations?

> +The procedure we use to turn a high-level object like `` into a
> +derivation is called `lower-object`; more on that in a future post.  However,
> +this doesn't produce a derivation:
> +
> +```scheme
> +(pk (lower-object irssi))
> +;;; (#)
> +```

Maybe beforehand you can mention “,lower irssi”, to show that it exists
and that there’s a simple way to peek at derivations, and only then
dissect “,lower”?

> +The returned object is a procedure that needs to be evaluated in the context 
> of

s/is a procedure/is a monadic value [in the store monad](…)/

> +a store connection.  We do this by first using `with-store` to connect to the
> +store and bind the connection to a name, then wrapping the `lower-object` 
> call
> +with `run-with-store`:
> +
> +```scheme
> +(define irssi-drv
> +  (pk (with-store %store
> +(run-with-store %store
> +  (lower-object irssi)
> +;;; (# /gnu/store/zcgmhac8r4kdj2s6bcvcmhh4k35qvihx-irssi-1.4.3.drv => 
> /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 7fe1902b6140>)
> +
> +(define glib-drv
> +  (pk (with-store %store
> +(run-with-store %store
> +  (lower-object glib)
> +;;; (# /gnu/store/81qqs7xah2ln39znrji4r6xj85zi15bi-glib-2.70.2.drv => 
> /gnu/store/lp7k9ygvpwxgxjvmf8bix8d2aar0azr7-glib-2.70.2-bin 
> /gnu/store/22mkp8cr6rxg6w8br9q8dbymf51b44m8-glib-2.70.2-debug 
> /gnu/store/a6qb5arvir4vm1zlkp4chnl7d8qzzd7x-glib-2.70.2 
> /gnu/store/y4ak268dcdwkc6lmqfk9g1dgk2jr9i34-glib-2.70.2-static 7fe17ca13b90>)
> +```

Personally I’d leave ‘with-store’, ‘run-with-store’, and ‘lower-object’
for a subsequent post, to avoid muddying the waters.  In this one I’d
just use “,lower” and “,build”, which is enough to peek at derivations
(we discussed it earlier on IRC and ISTR you were not quite convinced
though :-)).

> +Derivations are one of Guix's most important concepts, but are fairly easy to

Maybe: 
[Derivations](https://guix.gnu.org/manual/devel/en/html_node/Derivations.html)

> +4. `derivation-system`, specifying the Nix system a derivation will be 
> compiled
> +   for

s/Nix system(.*)/system type\1—e.g., `"x86_64-linux"`/

This is great, thanks a lot for your work!

Ludo’.

Re: WIP: zig-build-system

[Efraim Flashner]

I'm going to add my comments while reading through instead of reading
through, digesting, and then commenting.

On Thu, Dec 15, 2022 at 12:12:59PM +, Ekaitz Zarraga wrote:
> Hi all,
> 
> I'm working on a zig-build-system and I have something working.
> 
> I'd like to discuss some of the problems I found because I don't
> know what's the best solution:
> 
> - I don't know how to configure the cross-compilation

cross-compilation can come later. It's not uncommon when writing new
build systems.

> - The `zig` command uses a compiler to find the libc it needs to use
>   we should be able to remove the `gcc-toolchain` from the
>   dependencies if we just add the libc to the build system properly
>   (this point is mixed with the point above)

Are you sure about removing gcc-toolchain? I don't have a problem with
it if it is possible, especially since zig does provide a 'zig cc'
command. We'd still likely need to use something like the
make-gcc-toolchain to properly use ld-wrapper, unless we somehow
wouldn't need that either.

> I need suggestions on these...
> 
> I attach two patches, one for the current build system I made and
> a second one for an example package that actually works but has
> some weird needs you can find in the comments.
> 
> Cheers,
> Ekaitz

> From c19c7161cf0864be5ffee12e8baac248d2d9874a Mon Sep 17 00:00:00 2001
> From: Ekaitz Zarraga 
> Date: Thu, 15 Dec 2022 13:02:25 +0100
> Subject: [PATCH 2/2] Add a sample package for testing the zig build system
> 
> ---
>  gnu/packages/zig.scm | 43 ++-
>  1 file changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/packages/zig.scm b/gnu/packages/zig.scm
> index cda93bed2e..7bce76ed51 100644
> --- a/gnu/packages/zig.scm
> +++ b/gnu/packages/zig.scm
> @@ -25,7 +25,9 @@ (define-module (gnu packages zig)
>#:use-module ((guix licenses) #:prefix license:)
>#:use-module (guix build-system cmake)
>#:use-module (gnu packages)
> -  #:use-module (gnu packages llvm))
> +  #:use-module (gnu packages llvm)
> +  #:use-module (guix build-system zig)
> +  #:use-module (gnu packages commencement))
>  
>  (define-public zig
>(package
> @@ -104,3 +106,42 @@ (define-public zig
>  ;; https://github.com/ziglang/zig/issues/6485
>  (supported-systems %64bit-supported-systems)
>  (license license:expat)))
> +

I'm not looking at the actual package definition itself, that can be
left to another time as needed.

> +(define-public tigerbeetle
> +  (let ((commit-id "2022-12-12-weekly")
> +(revision "0"))
> +(package
> +  (name "tigerbeetle")
> +  (version (string-append revision "-" commit-id))
> +  (source
> +(origin
> +  (method git-fetch)
> +  (uri (git-reference
> + (url "https://github.com/tigerbeetledb/tigerbeetle.git;)
> + (commit commit-id)))
> +  (file-name (git-file-name name version))
> +  (sha256
> +(base32 
> "18rawl8rhyplw8hpa3fzbq9fqg088x0calz688c7zdff6y6f6mcr"
> +  (build-system zig-build-system)
> +  (inputs (list gcc-toolchain))

Isn't gcc-toolchain part of %standard-packages in a build-system? Did I
miss it not being there or does it also need to be added here for the
reason you listed below?

> +  (arguments
> + `(#:phases
> +   (modify-phases %standard-phases
> +  ;; TODO: Zig needs the gcc-toolchain in order to find the libc.
> +  ;;   we need to think about how to solve this in the build 
> system
> +  ;;   directly: --libc

by default glibc is named 'libc' in the build system, and when
cross-compiling 'libc' is generally the correct libc that you'd be
looking for. Also I'd be curious about reusing the libc vendored in zig
itself or if that's not actually possible/only for embedded uses.

Also if you just need libc you could import glibc-final for the
non-cross-build as a standard native-input (input?) and then you'd have
it available.

> +  (add-before 'build 'set-env
> +(lambda _
> +  (setenv "CC" "gcc"))

If you really don't need gcc by default you could consider something
like what we have in the cargo-build-system:

(when (assoc-ref inputs "openssl")
  (setenv "OPENSSL_DIR" (assoc-ref inputs "openssl")))

could be:

 (cond
  ((assoc-ref inputs "gcc") (setenv "CC" "gcc"))
  ((assoc-ref inputs "clang") (setenv "CC" "llvm"))
  (_ (setenv "CC" "zig cc")))

> +  (synopsis "Distributed financial accounting database designed for 
> mission
> +criti cal safety and performance")
> +
> +  (description "Financial accounting database designed for mission 
> critical
> +safet y and performance to power the future of financial
> +servi ces.")
> +  (home-page "https://github.com/tigerbeetledb/tigerbeetle.git;)
> +  (supported-systems %64bit-supported-systems)
> +  (license license:asl2.0
> -- 
> 2.38.0
> 

> 

shellcheck updates to 64?

[jgart]

Hi, is this a bug? I ran `guix refresh -u` on shellcheck and it updated
shellcheck to version 64 but the latest stable release which was released
2 days ago is 0.9.0:

--
 (define-public shellcheck
   (package
 (name "shellcheck")
-(version "0.8.0")
+(version "64")
 (source
  (origin
(method url-fetch)
(uri (string-append
- "https://hackage.haskell.org/package/ShellCheck/ShellCheck-;
+ 
"https://github.com/koalaman/shellcheck/releases/download/stable/ShellCheck-;
  version ".tar.gz"))
(sha256
-(base32 "05jlapp4m997w36h2wszdxz9gvczdczaylypsbn14jqpb650w232"))
+(base32 "08kn81xwkwsqjczn0w2kbf724p3q3acavmdnlbpb9i7g5n8fq6p3"))
(file-name (string-append name "-" version ".tar.gz"
 (build-system haskell-build-system)
 (arguments

WDYT

WIP: zig-build-system

[Ekaitz Zarraga]

Hi all,

I'm working on a zig-build-system and I have something working.

I'd like to discuss some of the problems I found because I don't
know what's the best solution:

- I don't know how to configure the cross-compilation
- The `zig` command uses a compiler to find the libc it needs to use
  we should be able to remove the `gcc-toolchain` from the
  dependencies if we just add the libc to the build system properly
  (this point is mixed with the point above)

I need suggestions on these...

I attach two patches, one for the current build system I made and
a second one for an example package that actually works but has
some weird needs you can find in the comments.

Cheers,
EkaitzFrom c19c7161cf0864be5ffee12e8baac248d2d9874a Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga 
Date: Thu, 15 Dec 2022 13:02:25 +0100
Subject: [PATCH 2/2] Add a sample package for testing the zig build system

---
 gnu/packages/zig.scm | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/zig.scm b/gnu/packages/zig.scm
index cda93bed2e..7bce76ed51 100644
--- a/gnu/packages/zig.scm
+++ b/gnu/packages/zig.scm
@@ -25,7 +25,9 @@ (define-module (gnu packages zig)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix build-system cmake)
   #:use-module (gnu packages)
-  #:use-module (gnu packages llvm))
+  #:use-module (gnu packages llvm)
+  #:use-module (guix build-system zig)
+  #:use-module (gnu packages commencement))
 
 (define-public zig
   (package
@@ -104,3 +106,42 @@ (define-public zig
 ;; https://github.com/ziglang/zig/issues/6485
 (supported-systems %64bit-supported-systems)
 (license license:expat)))
+
+
+(define-public tigerbeetle
+  (let ((commit-id "2022-12-12-weekly")
+(revision "0"))
+(package
+  (name "tigerbeetle")
+  (version (string-append revision "-" commit-id))
+  (source
+(origin
+  (method git-fetch)
+  (uri (git-reference
+ (url "https://github.com/tigerbeetledb/tigerbeetle.git;)
+ (commit commit-id)))
+  (file-name (git-file-name name version))
+  (sha256
+(base32 "18rawl8rhyplw8hpa3fzbq9fqg088x0calz688c7zdff6y6f6mcr"
+  (build-system zig-build-system)
+  (inputs (list gcc-toolchain))
+
+  (arguments
+ `(#:phases
+   (modify-phases %standard-phases
+  ;; TODO: Zig needs the gcc-toolchain in order to find the libc.
+  ;;   we need to think about how to solve this in the build system
+  ;;   directly: --libc
+  (add-before 'build 'set-env
+(lambda _
+  (setenv "CC" "gcc"))
+
+  (synopsis "Distributed financial accounting database designed for mission
+criti cal safety and performance")
+
+  (description "Financial accounting database designed for mission critical
+safet y and performance to power the future of financial
+servi ces.")
+  (home-page "https://github.com/tigerbeetledb/tigerbeetle.git;)
+  (supported-systems %64bit-supported-systems)
+  (license license:asl2.0
-- 
2.38.0

From 4dd02f0ea421bc1f4081380e847f048998131873 Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga 
Date: Thu, 15 Dec 2022 13:01:23 +0100
Subject: [PATCH 1/2] WIP: Add a zig-build-system

---
 Makefile.am   |   2 +
 etc/snippets/yas/scheme-mode/guix-package |   5 +-
 guix/build-system/zig.scm | 119 ++
 guix/build/zig-build-system.scm   |  82 +++
 4 files changed, 206 insertions(+), 2 deletions(-)
 create mode 100644 guix/build-system/zig.scm
 create mode 100644 guix/build/zig-build-system.scm

diff --git a/Makefile.am b/Makefile.am
index b54288c0fc..4cc7c2e5cf 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -179,6 +179,7 @@ MODULES =	\
   guix/build-system/scons.scm			\
   guix/build-system/texlive.scm			\
   guix/build-system/trivial.scm			\
+  guix/build-system/zig.scm			\
   guix/ftp-client.scm\
   guix/http-client.scm\
   guix/gnupg.scm\
@@ -263,6 +264,7 @@ MODULES =	\
   guix/build/graft.scm\
   guix/build/bournish.scm			\
   guix/build/qt-utils.scm			\
+  guix/build/zig-build-system.scm		\
   guix/build/make-bootstrap.scm			\
   guix/search-paths.scm\
   guix/packages.scm\
diff --git a/etc/snippets/yas/scheme-mode/guix-package b/etc/snippets/yas/scheme-mode/guix-package
index 724a392f81..3bb6307659 100644
--- a/etc/snippets/yas/scheme-mode/guix-package
+++ b/etc/snippets/yas/scheme-mode/guix-package
@@ -43,8 +43,9 @@
   "scons-build-system"
   "texlive-build-system"
   "trivial-build-system"
-  "waf-build-system")})
+  "waf-build-system"
+   

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Svante Signell]

On Thu, 2022-12-15 at 01:24 -0600, Nathan Dehnel wrote:
> You could try seeing what they're doing here to cross-build
> https://github.com/flavioc/cross-hurd
> It worked last time I ran it (which was admittedly a while ago)

Hi,

The problem is probably that you need to add --enable-add-ons=libpthread to
configure when building first version of cross-glibc. This is to obtain weak
references when building libcstd++ of cross-gcc:

nm --dynamic /cross-tools/lib/libstdc++.so.6.0.30|grep pthread
...
w __pthread_key_create
w pthread_key_create
w pthread_key_delete
...

Then that build of cross-gcc will succeed in building the Hurd version of
libstdc++ etc.
nm --dynamic /tools/lib/libstdc++.so.6.0.30|grep pthread


The problem is due to that with recent versions of glibc libpthread is included
for Linux, but not for Hurd.

Note that don't issue autoreconf gcc (in my case 12.2.0) unless you have only
autoconf2.69 installed (or what is needed for your version of upstream gcc).

My scripts to cross-build Hurd on Debian/GNU Linux: hurd-cross (hurdX) will soon
be published on Savannah under the Hurd umbrella. Note the name difference:
hurd-cross vs cross-hurd. As of current these scripts include up-to-date
versions of all packages used, with git versions of mig, gnumach and hurd.

(The scripts of hurd-cross were based on the work by Flavio in 2019, thank you
Flavio. However they have diverged considerably since then, and are not easily
merged into his work at github)

Good luck!