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

[(]

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

This patch adds instructions for suppressing colours and readline support in
``guix repl'' on Guix System.

 .../posts/dissecting-guix-1-derivations.md| 435 ++
 1 file changed, 435 insertions(+)
 create mode 100644 website/posts/dissecting-guix-1-derivations.md

diff --git a/website/posts/dissecting-guix-1-derivations.md 
b/website/posts/dissecting-guix-1-derivations.md
new file mode 100644
index 000..e3b6b71
--- /dev/null
+++ b/website/posts/dissecting-guix-1-derivations.md
@@ -0,0 +1,435 @@
+title: Dissecting Guix, Part 1: Derivations
+date: TBC
+author: (
+tags: Dissecting Guix, Functional package management, Programming interfaces, 
Scheme API
+---
+To a new user, Guix's functional architecture can seem quite alien, and 
possibly
+offputting.  With a combination of extensive `#guix`-querying, determined
+manual-reading, and plenty of source-perusing, they may eventually figure out
+how everything fits together by themselves, but this can be frustrating and
+often takes a fairly long time.
+
+However, once you peel back the layers, the "Nix way" is actually rather
+elegant, if perhaps not as simple as the mutable, imperative style implemented
+by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and
+[`pacman`](https://wiki.archlinux.org/title/pacman).
+This series of blog posts will cover basic Guix concepts, taking a "ground-up"
+approach by dealing with lower-level concepts first, and hopefully make those
+months of information-gathering unnecessary.
+
+Before we dig in to Guix-specific concepts, we'll need to learn about one
+inherited from [Nix](https://nixos.org), the original functional package 
manager
+and the inspiration for Guix; the idea of a _derivation_ and its corresponding
+_store items_.
+
+These concepts were originally described by Eelco Dolstra, the author of Nix, 
in
+their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see
+_§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_.
+
+# Store Items
+
+As you almost certainly know, everything that Guix builds is stored in the
+_store_, which is almost always the `/gnu/store` directory.  It's the job of 
the
+[`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html)
+to manage the store and build things.  If you run
+[`guix build 
PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html),
+`PKG` will be built or downloaded from a substitute server if available, and a
+path to an item in the store will be displayed.
+
+```
+$ guix build irssi
+/gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3
+```
+
+This item contains the final result of building [`irssi`](https://irssi.org).
+Let's peek inside:
+
+```
+$ ls $(guix build irssi)
+bin/  etc/  include/  lib/  share/
+$ ls $(guix build irssi)/bin
+irssi*
+```
+
+`irssi` is quite a simple package.  What about a more complex one, like
+[`glib`](https://docs.gtk.org/glib)?
+
+```
+$ guix build glib
+/gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin
+/gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug
+/gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc
+/gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3
+/gnu/store/4c8ycz501n2d0xdi4blahvnbjhd5hpa8-glib-2.73.3-static
+```
+
+`glib` produces five `/gnu/store` items, because it's possible for a package to
+produce multiple 
[outputs](https://guix.gnu.org/manual/en/html_node/Packages-with-Multiple-Outputs.html).
+Each output can be referred to separately, by prefixing a package's name with
+`:OUTPUT` where supported.  For example, this
+[`guix 
install`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html)
+invocation will add `glib`'s `bin` output to your profile:
+
+```
+$ guix install glib:bin
+```
+
+The default output is `out`, so when you pass `glib` by itself to that command,
+it will actually install `glib:out` to the profile.
+
+`guix build` also provides the `--source` flag, which produces the store item
+corresponding to the given package's downloaded source code.
+
+```
+$ guix build --source irssi
+/gnu/store/cflbi4nbak0v9xbyc43lamzl4a539hhb-irssi-1.4.3.tar.xz
+$ guix build --source glib
+/gnu/store/d22wzjq3xm3q8hwnhbgk2xd3ph7lb6ay-glib-2.73.3.tar.xz
+```
+
+But how does Guix know how to build these store outputs in the first place?
+That's where derivations come in.
+
+# `.drv` Files
+
+You've probably seen these being printed by the Guix CLI now and again.
+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:
+
+```
+$ guix build --derivations irssi
+/gnu/store/zcgmhac8r4kdj2s6bcvcmhh4k35qvihx-irssi-1.4.3.drv
+```
+
+`guix build` can actually also accept derivation paths as an argument, in lieu
+of a package, like so:
+
+```
+$ guix build 

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

[(]

Heya,

On Mon Dec 12, 2022 at 9:06 PM GMT, Mekeor Melire wrote:
> As noted in , Guix System 
> users, who use the =~/.guile= file which is created by default, 
> will need to pass the =INSIDE_EMACS= environment variable to =guix 
> repl=, like this:
>
> #+begin_src sh
> INSIDE_EMACS=true guix repl --listen=tcp:37146 &
> #+end_src

Ah!  That was the problem :)  Thanks!

-- (


signature.asc
Description: PGP signature

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

[Mekeor Melire]

I have one remark.

2022-12-12 19:31 pa...@disroot.org:


+If you're using Emacs, you can instead install
+[Geiser](https://nongnu.org/geiser), which provides a 
comfortable Emacs UI for
+various Lisp REPLs, invoke `guix repl --listen=tcp:37146 &`, 
and type
+`M-x geiser-connect RET RET RET` to connect to the running 
Guile instance.


As noted in , Guix System 
users, who use the =~/.guile= file which is created by default, 
will need to pass the =INSIDE_EMACS= environment variable to =guix 
repl=, like this:


#+begin_src sh
INSIDE_EMACS=true guix repl --listen=tcp:37146 &
#+end_src

Otherwise, they'll experience a freeze (which they'll need to 
break with C-g).

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

[Mekeor Melire]

2022-12-12 19:31 pa...@disroot.org:

This patch adds an updated blog post, taking the critiques on 
this thread into

account.

* Changed post name to just "Derivations"
* Removed subjective "simple" language
* Added subheadings to "Exploring ``"
* Added field recap to "Conclusion"
* Added "Utilising ``", with examples for 
READ-DERIVATION,
  READ-DERIVATION-FROM-FILE, WRITE-DERIVATION, and 
  BUILD-DERIVATION

* Wrapped lines to 80 columns


looks good to me :)

Re: Python Packaging Policy

[Efraim Flashner]

On Thu, Dec 08, 2022 at 11:48:42AM +0100, zimoun wrote:
> Hi,
> 
> On Wed, 07 Dec 2022 at 17:22, jgart  wrote:
> 
> > What is our policy then for updating Python packages in our Python
> > library collection?
> 
> The policy is to not break the other packages; guix refresh -l python-.
> 
> 
> > How are we assuring that all Python libraries are working well together?
> 
> How?  With a lot of love. :-)

Yeah, basically. The 'sanity-check phase helps a lot though ...

-- 
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: Status of hibernation (suspend to disk) in Guix

[Ivan Vilata i Balaguer]

Mekeor Melire (2022-12-10 01:00:24 +) wrote:

> 2022-12-09 23:10 mek...@posteo.de:
> 
> > 2022-12-05 17:23 i...@selidor.net:
> >
> > > in #59746 I skipped documenting `resume_offset` with more detail, even
> > > if it's needed for resuming from a swap file. The reason is that
> > > according to [swsusp doc][1], some specific tool may be needed to
> > > compute the swap file offset. There is [swap-offset][2] from the
> > > uswsusp suite, which is missing from Guix and no longer shipped with
> > > Debian.
> >
> > What about the "filefrag" executable from the "e2fsprogs" package.
> > According to this article, it can be used in place of the deprecated
> > uswsusp suite:
> >
> > https://www.linuxuprising.com/2021/08/how-to-enable-hibernation-on-ubuntu.html
> 
> I just tried this out. And it worked like a charm! I have hibernated and
> resumed successfully - first time with Guix System. I'm so happy :)
> 
> Would you like to add instructions for swap-files to your
> patch-series #59746?
> 
> What I did: First, determine offset:
> 
> --8<---cut here---start->8---
> $ sudo filefrag -v /swapfile
> Filesystem type is: ef53
> File size of /swapfile is 1717986918 (4194304 blocks of 4096 bytes)
>  ext: logical_offset:physical_offset: length:   expected: flags:
>0:0..   0:5308416..   5308416:  1:
> --8<---cut here---end--->8---
> 
> Then, use offset in operating-system declaration:
> 
> --8<---cut here---start->8---
>   (kernel-arguments
> (cons*
>   "resume=/dev/mapper/cryptroot"
>   "resume_offset=5308416"
>   %default-kernel-arguments))
> --8<---cut here---end--->8---
> 
> Caveat: IIUC, this does not work with Btrfs.

Good find!  Besides the issue of `filefrag` being ExtFS-specific, another
thing that worries me is [this check][1] that `swap-offset` does about the
swap header being physically contiguous on disk, which would need to be made
manually with `filefrag`.

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-utils.git/tree/swap-offset.c#n114

I guess that swap header fragmentation won't happen in most cases, but I also
see that the instructions in "(guix)Keyboard Layout, Networking, and
Partitioning" to create a swap file use `dd` instead of something less prone
to fragmentation like `fallocate` (which then may or may not work depending on
the particular FS).

So I'm not completely at ease with extending the instructions for swap files,
but someone more versed in the topic may. `:)`

Cheers,

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature

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

[(]

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

This patch adds an updated blog post, taking the critiques on this thread into
account.

* Changed post name to just "Derivations"
* Removed subjective "simple" language
* Added subheadings to "Exploring ``"
* Added field recap to "Conclusion"
* Added "Utilising ``", with examples for READ-DERIVATION,
  READ-DERIVATION-FROM-FILE, WRITE-DERIVATION, and BUILD-DERIVATION
* Wrapped lines to 80 columns

 .../posts/dissecting-guix-1-derivations.md| 426 ++
 1 file changed, 426 insertions(+)
 create mode 100644 website/posts/dissecting-guix-1-derivations.md

diff --git a/website/posts/dissecting-guix-1-derivations.md 
b/website/posts/dissecting-guix-1-derivations.md
new file mode 100644
index 000..18cdc3a
--- /dev/null
+++ b/website/posts/dissecting-guix-1-derivations.md
@@ -0,0 +1,426 @@
+title: Dissecting Guix, Part 1: Derivations
+date: TBC
+author: (
+tags: Dissecting Guix, Functional package management, Programming interfaces, 
Scheme API
+---
+To a new user, Guix's functional architecture can seem quite alien, and 
possibly
+offputting.  With a combination of extensive `#guix`-querying, determined
+manual-reading, and plenty of source-perusing, they may eventually figure out
+how everything fits together by themselves, but this can be frustrating and
+often takes a fairly long time.
+
+However, once you peel back the layers, the "Nix way" is actually rather
+elegant, if perhaps not as simple as the mutable, imperative style implemented
+by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and
+[`pacman`](https://wiki.archlinux.org/title/pacman).
+This series of blog posts will cover basic Guix concepts, taking a "ground-up"
+approach by dealing with lower-level concepts first, and hopefully make those
+months of information-gathering unnecessary.
+
+Before we dig in to Guix-specific concepts, we'll need to learn about one
+inherited from [Nix](https://nixos.org), the original functional package 
manager
+and the inspiration for Guix; the idea of a _derivation_ and its corresponding
+_store items_.
+
+These concepts were originally described by Eelco Dolstra, the author of Nix, 
in
+their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see
+_§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_.
+
+# Store Items
+
+As you almost certainly know, everything that Guix builds is stored in the
+_store_, which is almost always the `/gnu/store` directory.  It's the job of 
the
+[`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html)
+to manage the store and build things.  If you run
+[`guix build 
PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html),
+`PKG` will be built or downloaded from a substitute server if available, and a
+path to an item in the store will be displayed.
+
+```
+$ guix build irssi
+/gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3
+```
+
+This item contains the final result of building [`irssi`](https://irssi.org).
+Let's peek inside:
+
+```
+$ ls $(guix build irssi)
+bin/  etc/  include/  lib/  share/
+$ ls $(guix build irssi)/bin
+irssi*
+```
+
+`irssi` is quite a simple package.  What about a more complex one, like
+[`glib`](https://docs.gtk.org/glib)?
+
+```
+$ guix build glib
+/gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin
+/gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug
+/gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc
+/gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3
+/gnu/store/4c8ycz501n2d0xdi4blahvnbjhd5hpa8-glib-2.73.3-static
+```
+
+`glib` produces five `/gnu/store` items, because it's possible for a package to
+produce multiple 
[outputs](https://guix.gnu.org/manual/en/html_node/Packages-with-Multiple-Outputs.html).
+Each output can be referred to separately, by prefixing a package's name with
+`:OUTPUT` where supported.  For example, this
+[`guix 
install`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html)
+invocation will add `glib`'s `bin` output to your profile:
+
+```
+$ guix install glib:bin
+```
+
+The default output is `out`, so when you pass `glib` by itself to that command,
+it will actually install `glib:out` to the profile.
+
+`guix build` also provides the `--source` flag, which produces the store item
+corresponding to the given package's downloaded source code.
+
+```
+$ guix build --source irssi
+/gnu/store/cflbi4nbak0v9xbyc43lamzl4a539hhb-irssi-1.4.3.tar.xz
+$ guix build --source glib
+/gnu/store/d22wzjq3xm3q8hwnhbgk2xd3ph7lb6ay-glib-2.73.3.tar.xz
+```
+
+But how does Guix know how to build these store outputs in the first place?
+That's where derivations come in.
+
+# `.drv` Files
+
+You've probably seen these being printed by the Guix CLI now and again.
+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 

Re: Hi from a new committer!

[(]

Heya,

On Mon Dec 12, 2022 at 4:21 PM GMT, John Kehayias wrote:
> 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.

Congratulations!  Your previous contributions (FHS shell is brilliant!) have 
really
benefitted the project, so I suppose we can look forward to more of that! :D

-- (


signature.asc
Description: PGP signature

Re: Dissecting Guix -- blog post series

[(]

Heya,

On Mon Dec 12, 2022 at 1:43 AM GMT, Mekeor Melire wrote:
> Or auto-fill-mode? :)

I'm pretty new to Emacs, so I dunno which way is best -.o.-

> Personally, I felt kind of fooled at that point, because it felt 
> like I had made needless efforts to read an irrelevant code 
> snippet.

Fair enough, but I also think if I remove it people will be left wondering how
``recursive?'' is serialised.

I think that code snippet might be irrelevant anyway, since I can just show the
result of serialising a derivation with ``recursive? #t''.

> By the way, sorry for the malformatted e-mail; I was tweaking 
> around with my mail-client's settings. (I'm now using f=f and 
> non-broken lines.) Hope my mails are well readable at your end. 
> Please let me know if they're not.

They're perfectly readable, but the lines are quite short.

-- (


signature.asc
Description: PGP signature

Re: Hi from a new committer!

[Luis Felipe]

Hi John,

> 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.

Excelent \o/ Thank you for your commitment :)

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Hi from a new committer!

[John Kehayias]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hi Guix!

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.

As per the committer process, my primary key and signing subkey
fingerprints are below. You can also see the same signing subkey
associated with my GitLab account:  and
GitHub: , though perhaps not publicly
visible. It should also be available on your favorite keyserver as well,
associated with this email account, john.kehay...@protonmail.com.

Primary key fingerprint:
7E9F 5BF6 1680 4367 127B 7A87 F9E6 9FB8 5A75 54F1

Signing Subkey fingerprint:
A420 7B56 C255 109F 2CB3  157E 4990 97AE 5EA8 15D9

This email should be signed with that same signing (sub)key. I've had
some difficulties with this in the past, so please let me know if this
does not show as properly signed for you so I can correct that.

Below is a little introduction to me and Guix. In short, I love hacking
away on Guix and am happy to add my efforts as a committer now. Find me
on IRC and say hi! And feel free to point me to lingering patches,
especially short and simple ones, to get my feet wet.

Sincerely,
John Kehayias


First off, you may know me as "podiki" on the IRC channel. I'm very
appreciative of the reviews and guidance everyone has given to me so far
and can't wait to contribute more to Guix.

Let me briefly tell you about myself and Guix. And actually, you can
find out more from my Guix Days talk "My experiences as a newcomer to
Guix" at

if you haven't already seen it.

In short, I currently work teaching writing at UPenn in the US, but my
background is as a theoretical physicist with 5 years as a postdoc at a few
places doing some fun research. Not much official computing (beyond
Mathematica on occasion), but that has been a hobby for as long as I can
remember.

I found out about Guix about 1.5 years ago, as a "Nix but better
language," and as an everything Lisp lover couldn't resist. I dove in
with my first patches for updating Mesa in that most recent core-updates
cycle adventure. I use Guix exclusively on my desktop (which I wrote
about here
)
and enjoy staying on the latest and greatest as best I can.

So that means my contributions have been rather varied, plenty on adding
or fixing packages I'm familiar with and rely on in my typical usage,
but also random things that have come up, like in the core-updates bug
fixing push. Most recently I worked on adding the '--emulate-fhs' option
to 'guix shell' containers (blog post forthcoming!). My next big effort
will be a patch series to add some Go packages and the peroxide
package/service (a bridge for using ProtonMail locally), which you can
see in its WIP form here (and I use daily, so far so good!):
.
But priority number one is helping others with patches that have been
submitted and need review.

Let me wrap up by saying why I applied for commit access and what I hope
to do. In Guix I've found my forever distro home and I love working on
making it better. I try to be helpful on IRC (and other channels) and
want to be more involved in reviewing other's patches. Commit access
will help tackle that ever growing backlog of patches we get and be
continued motivation (responsibility) to keep contributing however I
can. I recently joined another channel and found that spurred me to help
keep packages up to date there, push fixes, and try to organize others
for larger changes. I also like to help other newcomers and do whatever
I can to continue to make Guix as great and enjoyable to use as
possible. This is what commit access will help me do.

Thanks for reading I look forward to continuing to work with all of you
in the wonderful Guix community, truly our greatest feature.

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEEpCB7VsJVEJ8ssxV+SZCXrl6oFdkFAmOXVOcdHGpvaG4ua2Vo
YXlpYXNAcHJvdG9ubWFpbC5jb20ACgkQSZCXrl6oFdktbg//WCeVLjERxDu2wN65
uW5tYfJU04t2gYdVLiyx8Mmd7cnRUvLWzVUHYADfID1Hw4XOSISmH6RNOwdY7tCW
zmoUOvEtKU7BIZ0mrU4QPHW9/jm31IX+ZThSIYpj/++GuQiwZpkCKqNuZ4y7jRXk
ympDUsK+DgkgsiBX9nIgPqubVg1cSpo6+7DuTvSB9hg8nFL1x8psAVyXnHr2+f/4
w+QT7ZxwO0M0jGtcjpuTglA2FmRXBydAYnYxSGPcMCEpe8JDDzjrbUVmwY30cWe/
rIkNq1Hl0Jqyyni22mxuDiQGQq+4I+JGuddcecHFvh8Drbc2tN6vdWaf5wFe2iLR
3hUcntLx6A2XISOH7Oll1HlH8gguLMW2vW+9xX1zsP2XHSzM1m+4bScm51aZWgU0
b5sz+fMZqKGuw83XEcbA3ufsMjhkHFfjf4Fcu/HfwVnKof6HuD8tdcle6jrDchaF
hIbItB6OZ/AHONvCVSLxNg+HyGX0+b8F7X4jFkEifp0Xp37iuP7jKISOvv9sMxFH

Re: Packaging big generated data files?

[zimoun]

Hi,

On Wed, 07 Dec 2022 at 11:33, Denis 'GNUtoo' Carikli 
 wrote:

> The issue here is probably the size of the generated files: they are
> huge, so if they are packaged, they will most likely take significant
> resources in the Guix infrastructure.
>
> So what would be the way to go here? Would Guix accept patches to add
> packages for these files in Guix proper?  

>From my point of view, the data and the code should be packaged
separately; the package data using copy-build-system would be an input
for the package code.

> If so, does it needs to be done like with the ZFS (kernel module)
> package where "#:substitutable? #f" is used to avoid redistributing
> package builds? Or are other ways better for such use cases?

Yes, ’#:substitutable? #f’ seems the first way to go.


Cheers,
simon

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

[Efraim Flashner]

On December 12, 2022 1:47:29 PM UTC, "Ludovic Courtès"  wrote:
>Hello,
>
>guix-comm...@gnu.org skribis:
>
>> commit 9782c4529249c8300501202112c095a6589845d3
>> Author: Efraim Flashner 
>> AuthorDate: Sun Dec 11 22:35:06 2022 +0200
>> 
>> gnu: coreutils-boot0: Fix building on arm architectures.
>> 
>> * gnu/packages/commencement.scm (coreutils-boot0)[arguments]: When
>> building for arm architectures skip building some programs.
>
>[…]
>
>> +   ,@(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.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Ludovic Courtès]

Hello,

guix-comm...@gnu.org skribis:

> commit 9782c4529249c8300501202112c095a6589845d3
> Author: Efraim Flashner 
> AuthorDate: Sun Dec 11 22:35:06 2022 +0200
> 
> gnu: coreutils-boot0: Fix building on arm architectures.
> 
> * gnu/packages/commencement.scm (coreutils-boot0)[arguments]: When
> building for arm architectures skip building some programs.

[…]

> +   ,@(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’.

Re: Dissecting Guix -- blog post series

[Bengt Richter]

Hi,

On +2022-12-09 17:25:35 +, ( wrote:
> Heya,
> 
> On Fri Dec 9, 2022 at 9:32 AM GMT,  wrote:
> > How does a gullible noob like me know what the dangers might be, (e.g. 
> > http:)
> > and how to avoid (most of) them by finding a guix version that has been
> > gone through with a fine-tooth comb by trusted guix devs and has been
> > re-hosted at gitlab or gnu.org, etc ... for added security?
> 
> Sorry, I don't really understand; how is this relevant to derivations? :)
> 
> -- (

Maybe I mis-imagine your assumptions about your audience.

For myself, I would like an emacs M-x idiot-mode
so I could run a boot-bricker-test.sh script someone
has posted, without worrying that in plain cli context,
it will /actually/ brick my machine :)

I am assuming if your lowlevel examples are really good,
they will be used as bases for cut/paste variants that people
will then post and implicitly prompt each other to try..

I don't trust that everything thus posted
will be both benevolent and competently avoiding security vulns.

I can't even trust my own stuff. I make too many mistakes :)

So, narrowly focusing on derivations, maybe trust is not technically
relevant, but in the larger social context gullible noobs like me
need all the help we can get about recognizing potentially dangerous
code.

And I think derivations can potentially contain or generate or activate
code one should not trust.

So that's how I see asking for trust info being relevant to derivations :)
--
Regards,
Bengt Richter

Re: geiser and guix repl

[Mekeor Melire]

2022-12-12 13:17 luis.felipe...@protonmail.com:


There's this bug report which seems to be related:

Connecting Geiser to Guile listening to a socket: No prompt 
found! (.guile to blame) https://issues.guix.gnu.org/35727.


Yes, thank you. I also think that's exactly this bug. Let's 
continue discussion in that thread!

Re: geiser and guix repl

[Luis Felipe]

Hi,

On Monday, December 12th, 2022 at 10:28, Antonio Carlos Padoan Junior 
 wrote:

> Mekeor Melire mek...@posteo.de writes:
> 

> > By the way, personally, starting "guix repl --listen=tcp:37146"
> > from terminal and then running M-x geiser-connect makes Emacs
> > freeze for me. Do you experience the same?
> 

> Yes, that was exactly my issue.
> 

> The .guile file that you mentioned, the one provided automatically by
> Guix system (I was not aware of it), was responsible for the problem at
> the end. This script provide colors and other utilities when using guile
> from a terminal. If you connect to the guile session using geiser, you
> have a session in emacs with a colored prompt as well (it is necessary
> to use C-g to escape the hang). The colors in prompt are not properly parsed
> by geiser, I think so.
> 

> I deleted my .guix file and tried again. Everything was fine.
> 

> Now that I learned that .guix file was automatically created (and it was not
> something I eventually created myself), I think this issue is something
> that should be documented/clarified somewhere or improved.

There's this bug report which seems to be related:

Connecting Geiser to Guile listening to a socket: No prompt found! (.guile to 
blame)
https://issues.guix.gnu.org/35727.

I still can reproduce it on Guix System f0ee77a.

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: geiser and guix repl

[Antonio Carlos Padoan Junior]

Mekeor Melire  writes:

>
> By the way, personally, starting "guix repl --listen=tcp:37146" 
> from terminal and then running M-x geiser-connect makes Emacs 
> freeze for me. Do you experience the same?
>

Yes, that was exactly my issue.

The .guile file that you mentioned, the one provided automatically by
Guix system (I was not aware of it), was responsible for the problem at
the end. This script provide colors and other utilities when using guile
from a terminal. If you connect to the guile session using geiser, you
have a session in emacs with a colored prompt as well (it is necessary
to use C-g to escape the hang). The colors in prompt are not properly parsed
by geiser, I think so.

I deleted my .guix file and tried again. Everything was fine.

Now that I learned that .guix file was automatically created (and it was not
something I eventually created myself), I think this issue is something
that should be documented/clarified somewhere or improved.

I will try to launch guix repl from a eshell and check if the .guile
script recognizes that the color should be disabled.

Best regards,
-- 
Antonio Carlos PADOAN JUNIOR
GPG fingerprint:
243F 237F 2DD3 4DCA 4EA3  1341 2481 90F9 B421 A6C9