Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi Ludo’ and Guixers,

Before I get to some quick responses, I wanted to share some FHS container 
examples I've been testing. I hope others can try as I did get a response on 
IRC that one didn't work as expected. I think it might be when needing to 
expose some of the host for things like hardware access.

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

--8<---cut here---start->8---
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
--8<---cut here---end--->8---

where the first line is a cheat I like to get lots of libraries often needed 
for graphical applications (development inputs of ungoogled-chromium) though it 
is a bit overkill if the AppImage does actually bundle everything (they 
don't!). Next line is for display on the host's X server, the one after for 
DBus communication, and lastly exposing some of the host hardware for rendering 
(perhaps can be disabled in VSCodium somehow?). This is what may need some 
tweaking for others, but I'm not sure.

Note that we can't run an AppImage with out the 'appimage-extract-and-run' as 
it will want to use fuse to mount the image which we can't do from the 
container. I have some more details on this and actually did get this to mount, 
though it wasn't visible from the container, in the coming blog post draft.

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


--8<---cut here---start->8---
$ mkdir ~/temphome

$ guix shell -NCF bash coreutils curl grep nss-certs gcc:lib gcc-toolchain 
pkg-config glib cairo atk pango@1.48.10 gdk-pixbuf gtk+ git 
--share=$HOME/temphome=$HOME

~/temphome [env]$ curl --proto '=https' --tlsv1.2 -sSf  | 
sh
--8<---cut here---end--->8---

where I first created a '~/temphome' directory to use as $HOME in the container 
and included a bunch of libraries for the next example.

Finally, we can build a Rust project of desktop widgets, 
, following their directions 
 Ultimately this uses just 'cargo build 
--release' and this builds after downloading all the needed libraries. It needs 
similar stuff from the host as the VSCodium example to get things to run and 
display, which I'll detail in the blog post.

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

Now, back to the rest of the email.

On Tue, Dec 06, 2022 at 11:41 AM, Ludovic Courtès wrote:

> Hello!
>
> John Kehayias  skribis:
>
>> One question: what is appropriate or recommended for examples concerning 
>> things like
>> pre-built binaries? As an example, I had tested the FHS container by running 
>> the Siril
>> appimage, which has since been packaged for Guix (nice work!). There are 
>> ones that I
>> don't see that happening for anytime soon, like an Electron-based app. 
>> Something like
>> VSCodium is very popular, free (as in freedom and I believe the FSDG sense), 
>> but just
>> not something you can package fully from source due to JavaScript as I 
>> understand it. It
>> runs in the FHS container.
>
> A good example might be a free application not currently packaged in
> Guix, for example due to being full of JavaScript, or nightly builds as
> you wrote provided by an upstream project.
>

I used VSCodium above, though honestly I've only seen that it opens and seems 
to work fine. Open to other suggestions but that one will probably get some 
attention :)

>> Here is a current (rough!) draft. For the ease of plain text email I've 
>> exported from
>> the org source to text with some light edits:
>
> Note that the blog takes Markdown¹, but hopefully the Org-to-markdown
> export works well.
>
> ¹ 
>

Thanks, and I saw simon's email about this as well. I may have to tweak the 
Markdown a little, but should work easily enough.

> The post looks great to me!  I have minor suggestions below:
>

Thank you!

>> GNU Guix is different from most other GNU/Linux distributions and
>> perhaps nowhere is that more obvious than the organization of the
>> filesystem: Guix does not conform to the [File Hierarchy Standard]
>> (FHS). In practical terms, this means there is no global `/lib'
>
> It’s “Filesystem Hierarchy Standard”.
>
>> To that end, we've [recently added] a new option for Guix containers,
>> `--emulate-fhs' 

Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi simon,

On Fri, Dec 09, 2022 at 06:56 PM, zimoun wrote:

> Hi,
>
> On Mon, 05 Dec 2022 at 02:32, John Kehayias  
> wrote:
>
>> Here is a current (rough!) draft. For the ease of plain text email
>> I've exported from the org source to text with some light edits:
>
> Nice!  If you can turn the draft into Markdown and format a patch for
> guix-artwork [1] under website/drafts, it could be awesome! :-)
>
> Then you could send the patch to guix-devel, guix-blog or guix-patches.
>
> 1: 
>
>

Ah, thanks for this info, I'll take care of that. In the meantime I'll at least 
send out the current examples I've been using, as I want to make sure they work 
pretty generally. Of course they should since they will produce the same 
environment (until perhaps what is run in the environment), but a few of the 
commands may depend on what needs to be shared from the host. For example, to 
get graphical support.

I'll get the markdown formatted patch sent too and update everyone on that.

Thanks!
John

Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi Wojtek,

Thanks for your input!

On Mon, Dec 05, 2022 at 07:51 AM, Wojtek Kosior wrote:

> Hello,
>
>
>> Hi Guixers!
>>
>> I've started working on a little blog post about our new
>> --emulate-fhs option for Guix containers. In short, this sets up an
>> FHS-like (Filesystem Hierarchy Standard) container which has things
>> like /lib and /bin.
>>
>> I would like to get some suggestions on good examples to include.
>> More general feedback, questions, and other comments are also
>> welcome! I've included a rough draft of the beginning of the post,
>> leading up to showing some examples.
>
> Hi,
>
> One recent real-life example of `--emulate-fhs` being useful is with
> Python's virtualenv. I mentioned it in one help-guix thread which
> you can see here[1] :)
>
> Wojtek
>
> [1] 
>

I took a look but wasn't sure the exact commands I would use to show this, I 
guess it is when invoking vitualenv and using Guix python packages? I'm not a 
virtualenv user, so apologies for the simple question!

Though I'm happy to generally mention this as an example use and point to the 
linked email thread.

Thanks again,
John

Re: Dissecting Guix -- blog post series

[Mekeor Melire]

2022-12-11 10:08 pa...@disroot.org:


On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote:

> By the way, the text does not seem to strictly fill columns at 
> a certain line width. So I did not bother to fill columns in 
> the "patch".


Right, I should set up FILL-COLUMNS-INDICATOR... :)


Or auto-fill-mode? :)

> If the purpose is out of scope, then we should not dive in 
> that deeply. Especially, I'd suggest skip the code snippet.


I'm not sure about this.


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


> I think an example for invoking read-derivation-from-file 
> would round up this tutorial really nicely because it'd close 
> the circle between .drv-files and -objects.


Okay!  And one for write-derivation, too.


Sure :)

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.

Re: geiser and guix repl

[Mekeor Melire]

2022-12-11 12:39 acpadoa...@yahoo.com.br:


I figure out that the issue was indeed the colors.

I had an .guile file forcing it to use colors.


Ah, I guess that's why Guix System ships with the following 
~/.guile file. At least that's where I think I got it from, if I 
remember correctly.


--8<---cut here---start->8---
(cond ((false-if-exception (resolve-interface '(ice-9 readline)))
  =>
  (lambda (module)
;; Enable completion and input history at the REPL.
((module-ref module 'activate-readline
 (else
  (display "Consider installing the 'guile-readline' package 
  for

convenient interactive line editing and input history.\n\n")))

 (unless (getenv "INSIDE_EMACS")
   (cond ((false-if-exception (resolve-interface '(ice-9 
   colorized)))

  =>
  (lambda (module)
;; Enable completion and input history at the 
REPL.

((module-ref module 'activate-colorized
 (else
  (display "Consider installing the 'guile-colorized' 
  package

for a colorful Guile experience.\n\n"
--8<---cut here---end--->8---


Antonio Carlos Padoan Junior  writes:

> I'm facing some trouble using guix repl and geiser with 
> company-mode enabled. Emacs is hanging. I saw in documentation 
> that the issue is probably the regex used to parse the prompt.

>
> However, the default prompt regex looks fine. The only 
> difference I noticed between a geiser's session working 
> correctly (started from emacs) and guix's session (started 
> from terminal + geiser-connect) is the prompt colors.


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?

Re: guile-ssh and libssh updates

[Vagrant Cascadian]

On 2022-11-02, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> On 2022-10-28, Vagrant Cascadian wrote:
>>> I've been poking at updating guile-ssh to 0.16.0 and libssh to 0.10.4 in
>>> guix, but hit a few blockers.
>>>
>>> Updating guile-ssh to 0.16.0 actually went mostly smoothly, except
>>> guix-jupytertest suites fail.
...
>>> Updating libssh to 0.10.4 mostly works, but breaks guile-ssh tests:
>>>
>>>   https://github.com/artyom-poptsov/guile-ssh/issues/34
>>>
>>> Updating libssh to 0.10.4 with tests disabled for guile-ssh,
>>> guix-jupyter and kodi and kodi-wayland fail to build...
>>
>> For clarity, I used:
>>
>> ./pre-inst-env guix build --keep-going $(./pre-inst-env guix refresh 
>> --list-dependent libssh guile-ssh | cut -d : -f 2 | sed -e 
>> 's,guix-daemon,guix,g' | tr ' ' '\n' | grep -v kodi | grep -v jupyter)

So regarding libssh... what I discovered is that libssh deprecates the
DSA key algorithm (it is of dubious strenth, after all), and 0.10.x
disables DSA by default. Passing -DWITH_DSA=on to re-enable DSA support
in the libssh build helps guile-ssh pass most tests, but some tests
still fail. Since libssh plans to entirely remove DSA support in future
versions, may as well adapt sooner than later...

For Debian at the moment, I've patched out the DSA code from the
guile-ssh test suites, and that seems to work fine.

More details on the upstream guile-ssh bug report referenced above...


> You can also test Guix SSH functionality, to be on the safe side, for
> example by running ‘guix copy’ on the ‘guix’ package built with these
> new versions.

Clearly this has been a blocker for me... I don't have any systems where
I use that functionality, and I haven't taken the time to set them up to
test myself.

Anyone willing to offer some "guix copy" testing to have greater
confidence in updating guile-ssh? :)


> And then feel free to push!  (Guix-Jupyter has been failing tests for
> unrelated reasons.)

So, here we are... :)


live well,
  vagrant


signature.asc
Description: PGP signature

Re: geiser and guix repl

[Antonio Carlos Padoan Junior]

I figure out that the issue was indeed the colors.

I had an .guile file forcing it to use colors.


Antonio Carlos Padoan Junior  writes:

> Hello,
>
> I'm facing some trouble using guix repl and geiser with company-mode
> enabled. Emacs is hanging. I saw in documentation that the issue is
> probably the regex used to parse the prompt.
>
> However, the default prompt regex looks fine. The only difference I
> noticed between a geiser's session working correctly (started from
> emacs) and guix's session (started from terminal + geiser-connect) is
> the prompt colors. Guix's guile repl prompt is colored. I'm wondering if
> colors are affecting the regex somehow.
>
> Anyone else is facing the same issue? Any clues to fix it? I would like
> to have company-mode working correctly.
>
> Best regards,

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

Re: File search

[Ludovic Courtès]

Hi!

"Antoine R. Dumont (@ardumont)"  skribis:

> |---+-+--+--|
> | Iteration | Host System | Time (s) | Packages |
> |---+-+--+--|
> | 1st   | Debian  |   121.88 |  284 |
> |   | Guix System |   413.55 |  749 |
> |---+-+--+--|
> | 2nd   | Debian  |  1.3 |  101 |
> |   | Guix System |11.54 |  354 |
> |---+-+--+--|

Ah, that’s a significant difference.

I guess we can keep both methods: the exhaustive one that goes over all
packages, and the quick one.  Then we can have a switch to select the
method.

Typically, we may want to use the expensive one on the build farm to
publish a full database, while on user’s machines we may want to default
to the cheaper one.

>> Oh, and progress bars too.
>
> I'm a bit unsettled on this. Hopefully it was mostly a joke ;)

It wasn’t.  :-)

In the manifest case, we get ‘all-profiles’ is almost instantaneous, so
we immediately known the number of manifests we’ll be working on.

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

The (guix progress) module provides helpers.

But anyway, that’s more like icing on the cake, we can leave that for
later.

Thanks,
Ludo’.

Re: Packaging big generated data files?

[Ludovic Courtès]

Hi,

Denis 'GNUtoo' Carikli  skribis:

> On Thu, 08 Dec 2022 14:46:51 +0100
> Csepp  wrote:
>> Could ZIM files be downloaded over bittorrent as fixed output
>> derivations?  They can be pretty huge.  Also if the system started
>> seeding them as well, that would be pretty cool.
> I've no idea how to generate fixed output derivations.

Origins are lowered into “fixed-output derivations”.  They’re
“fixed-output” because their content hash is known in advance, and thus,
the method you used to produce them doesn’t matter (info "(guix)
Derivations").

So you could specify an origin with ‘bittorrent-fetch’ (to be written)
instead of ‘url-fetch’.

HTH,
Ludo’.

Re: Dissecting Guix -- blog post series

[(]

Heya,

On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote:
> I think it'd also be fine to come up with the titles during the process of 
> writing as sometimes that process itself is insightful. E.g. I could imagine 
> parts 2 and 4 to collapse. Maybe, maybe not, you'll see.

Perhaps.  I think monads are complex enough to warrant their own post, though.

> How'd this part differ from section "12.18 Defining Services" of the manual?

Along with a low-level description of the workings of services, it'd contain a
complex, concrete example of a service.  The manual mostly has an API reference
and some high-level-ish examples.

> How'd this part differ from sections 22 and "22.6 Submitting Patches" from 
> the manual?

Again, it'd be more concrete than what the manual shows.  It'd explain the
process by demonstrating the development of an *actual patch*, and showing how
it could be sent to guix-patc...@gnu.org.

> By the way, the text does not seem to strictly fill columns at a certain line 
> width. So I did not bother to fill columns in the "patch".

Right, I should set up FILL-COLUMNS-INDICATOR... :)

> If the purpose is out of scope, then we should not dive in that deeply. 
> Especially, I'd suggest skip the code snippet.

I'm not sure about this.  

> Here you write "pretty simple". Later you also write "self-explanatory" and 
> "obviously". I suggest to let the reader decide what's simple.

Fair.

> Before this point, the record fields have been called '"argument"'s all the 
> time. I think it's not nice style to carry on a quoted term through many 
> paragraphs like this. Let's simply write "record field" all the time, instead.

This is fair too :)

> I think an example for invoking read-derivation-from-file would round up this 
> tutorial really nicely because it'd close the circle between .drv-files and 
> -objects.

Okay!  And one for write-derivation, too.

> Here, in the conclusion, IMHO, there could be another brief listing of all 
> fields of a derivation.

Good idea.

-- (


signature.asc
Description: PGP signature

geiser and guix repl

[Antonio Carlos Padoan Junior]

Hello,

I'm facing some trouble using guix repl and geiser with company-mode
enabled. Emacs is hanging. I saw in documentation that the issue is
probably the regex used to parse the prompt.

However, the default prompt regex looks fine. The only difference I
noticed between a geiser's session working correctly (started from
emacs) and guix's session (started from terminal + geiser-connect) is
the prompt colors. Guix's guile repl prompt is colored. I'm wondering if
colors are affecting the regex somehow.

Anyone else is facing the same issue? Any clues to fix it? I would like
to have company-mode working correctly.

Best regards,

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

GNU Guix 1.4.0rc2 available for testing!

[Ludovic Courtès]

Hello Guix!

The second release candidate of the upcoming 1.4.0 release is now
available for testing, fixing issues that were reported for rc1:

  source:
https://alpha.gnu.org/gnu/guix/guix-1.4.0rc2.tar.gz

  binary tarball (to install on a “foreign distro”):
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.aarch64-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.armhf-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.i686-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.powerpc64le-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.x86_64-linux.tar.xz

  system installation:
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.i686-linux.iso
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.x86_64-linux.iso

  virtual machine image:

https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.4.0rc2.x86_64-linux.qcow2

SHA256 hashes:

  3b6c676615ce0b9de7c66ead528a91bb8520b74d2c391edac8d4c76d2d52  
guix-1.4.0rc2.tar.gz
  3566bfe5f0615f9b2167db7d1a2f1c88c02e8cc5013563b3e1eb95636a58f850  
guix-binary-1.4.0rc2.aarch64-linux.tar.xz
  18741b6780e9d0f8985d2514e5dff32110091cdf4da106062d1a2cf5cd6ed6a4  
guix-binary-1.4.0rc2.armhf-linux.tar.xz
  3d8348c2dbed8f9c6ab90f2ddc0df8c10d45c042612aed1fe7dcc7eabbc18b70  
guix-binary-1.4.0rc2.i686-linux.tar.xz
  4731126cc4f3f22265ae430e2acc3f67489ec311e42de346b634656740258033  
guix-binary-1.4.0rc2.powerpc64le-linux.tar.xz
  542e53a09fddedbddd75dfc745509ad9365cb7a76750d9bf8575b589c97dc286  
guix-binary-1.4.0rc2.x86_64-linux.tar.xz
  b35f94609942b9715acefa978166189c5505934c9576b1c3e14417beb5c48d6d  
guix-system-install-1.4.0rc2.i686-linux.iso
  880a1ee977f6999f63535d5667930d1d859a607c723573c86bd9f6c2ae69  
guix-system-install-1.4.0rc2.x86_64-linux.iso
  8bc98e42ba9370f49cfc2b051083121d8682c760ac3dac614b3f478d174c8756  
guix-system-vm-image-1.4.0rc2.x86_64-linux.qcow2

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
 [0].

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
 download  and uncomment the
 ‘GNU_URL’ variable assignment that refers to alpha.gnu.org.  It
 should pick up 1.4.0rc2 automatically.

  2. Testing the graphical installer of Guix System (the ISO images).

  3. Testing the VM image, along the lines of
 .

Please report success to guix-devel@gnu.org, and report bugs and
annoyances to bug-g...@gnu.org.

If not serious problems are reported, we may release 1.4.0 on Dec. 19th.

Thanks in advance!

Ludo’.

[0] Replacing https://sv.gnu.org/people/viewgpg.php?user_id=127547 by
https://sv.gnu.org/people/viewgpg.php?user_id=15145 in the
instructions.  This will only be reflected on the website after the
release is made.


signature.asc
Description: PGP signature