Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Ludovic Courtès]

Hi Per,

Per Bothner  skribis:

> On 4/2/19 2:37 AM, Ludovic Courtès wrote:
>> Yet I’m not completely sold to the everything in the browser approach,
>> and everything in JavaScript.  In an ideal world (for me), we’d rather
>> provide a local documentation viewer
>
>  I don't think we're aiming for "everything in the browser".  A closer
> approximation  is "everything using html+javascript".

Yeah, that’s what I meant.  :-)

I find things like DOMTerm very impressive, and it’s true that
HTML/JS/CSS nowadays constitute an unequaled UI framework (to the point
that GNOME Shell is also written in JS + CSS.)

That would be a good argument in favor of doing things this way.  Yet, I
have to say that this is not a direction that I like, technically and
otherwise (we’re talking about code bases orders of magnitudes bigger
than all of Texinfo including info-stnd, and code bases under the
control of a couple of companies.)

>> that renders Texinfo directly.
>
> That's a lot of work, and I see little benefit to it.

I was mentioning this because it’s an experiment that Andy Wingo did
about 15 years (?!) ago.  Andy wrote the Texinfo parser that’s now part
of Guile, and then had a Guile-GTK program that used a tree widget to
show the contents, had clickable links, text would reflow, etc.  (See
.
Unfortunately the screenshot has disappeared.)

That said, it surely is quite a bit of work, but I think it’s an option
we could consider.

>> When talking about ease of access, we can’t ignore keyword searches.
>> How would you do ‘info -k’?  How would you even simply point your
>> browser to a specific manual?  What about inter-manual cross-references?
>
> You can still have an 'info' command, which would parse the command-line,
> find the appropriate html file, and then start up an Electron/Qt/browser
> window.

Sounds like a plan.

>> Would we need a mechanism similar to ‘hxmlxref.cnf’ but that would
>> browse local manuals?  What would be the recommended solution for Emacs
>> and console users?
>
> I think the best approach for Emacs is a hybrid of eww and info modes:
> Instead of reading an info file, it would read an html file, which would
> be displayed using eww.  However, the keybindings and search/navigation logic
> would be based on that of info mode.
>
> On a plain terminal, info could either create a fresh window, or it
> could delegate to 'emacs -nw'.

Yes.

>> There’s a side issue, which is that HTML documentation tends to take
>> quite a lot of space, but we’ll see whether that’s a problem.
>
> It does require some more space, but it should compress fairly well.
> What I do for the Kawa manual is generate an 'epub' archive, which is
> basically a zip archive, with compression.  It is fairly simple for a
> web server to extract a zip member and send it to a browser directly
> as a gzip-compressed file, without actually decompressing the file
> (until it gets to the browser).  I contributed support for this to
> https://libwebsockets.org/, which is a compact C-language http server.
> DomTerm uses this to "serve" the JavaScript files to the browser,
> and a revamped 'info' program could do the same.

A simpler solution might be to use ‘Content-Encoding: gzip’.

Thanks,
Ludo’.

Re: librsvg & Rust

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> Ludovic Courtès  writes:

[...]

> I don't have a strong opinion, so I restored the previous librsvg
> variant for now and kept the Rust one as 'librsvg-next' with commit
> f67417a1b4d3fbd3a2e1593d32422e0d901ba367.

Great.

> Let's "freeze" and try to merge this branch soon.  Are there any pending
> patches?

I don’t think so, let’s try to merge ‘staging’!

Thanks,
Ludo’.

Re: Software Heritage & Guix

[Ludovic Courtès]

Hi!

Giovanni Biscuolo  skribis:

> mikadoZero  writes:
>
>> Ludovic Courtès writes:
>>
>>> ... 
>>> Long-term archival is something that cannot be left to peer-to-peer
>>> networks:
>
> I disagree here: P2P/decentralized archival is a _resilient_ archival
> method and is _not_ in contrast with long-term: a group of users
> (including institutions at various levels) can decide that some or all
> of a "decentralized Software Heritage" archive deserves availability
> guarantees :-)

My point is: the availability guarantee stems from the commitment of a
non-profit to provide the infrastructure and to sustain it.  Whether
it’s IPFS or something else doesn’t matter much.  It’s largely an
organizational matter more than a technical one.

Ludo’.

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

> To summarize, we’re just missing ‘--with-video=fbdev,drm2d’ and then
> we’re done, right?

Reading the kmscon source code (configure.ac), it seems that the default
is "fbdev,drm2d,drm3d".

I suspect that the drm hangs the kernel in Florian's case.

It indeed might make sense to try whether "--with-video=fbdev,drm2d"
(i.e. without "drm3d") improves things, and if not, just disable drm
modesetting at bootup.  If it's not there then it can't break :P


pgphAFaoSStKq.pgp
Description: OpenPGP digital signature

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Danny Milosavljevic  skribis:

>> I suggest that we use fbdev (maybe at runtime, but maybe just disable 
>> everything
>> else :P).
>
> Selecting it at runtime should work well.
>
> I've read kmscon source now and they wait for udev events in order to choose 
> backends.
>
> Once an udev event arrives, they check the result of 
> udev_device_get_subsystem().
> If it's "drm", they'll use [drm3d or] drm2d.
> If it's "graphics", they'll use fbdev.
>
> So it supports fbdev just fine and will select it when drm is unavailable.

To summarize, we’re just missing ‘--with-video=fbdev,drm2d’ and then
we’re done, right?

That’d be sweet.

Ludo’.

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Danny Milosavljevic  skribis:

> On Wed, 03 Apr 2019 09:19:01 +0200
> Mathieu Othacehe  wrote:
>
>> Hello Florian,
>> 
>> > Not using KMScon would prevent support for the Chinese and Japanese
>> > language during install, would it not?  
>> 
>> Yes and for other languages too.
>
> Yeah, but doesn't kmscon support vesa?  I mean I know the name kinda implies
> kernel modesetting, but doesn't it have a framebuffer fallback?
>
> I do mean we keep graphics terminal, but just use vesa instead of kms in order
> to set the graphics mode up.  (If that works)

I agree that this would be the best option, if it’s possible.  (I’m
surprised kmscon doesn’t automatically fall back to the framebuffer on
these AMD things.)

Ludo’.

Re: custom kernel config

[Efraim Flashner]

On Wed, Apr 03, 2019 at 09:49:59PM +0200, Pierre Neidhardt wrote:
> Thank you Efraim, this is awesome!
> 
> Efraim Flashner  writes:
> 
> > For the first one I used the #:extra-options route and compiled a list.
> > The second one I tried I created a custom kernel and left #:defconfig as
> > #f and inherited that to add a kconfig to the native-inputs.
> 
> Oh, I think I had missed the #:defconfig option when I tried.
> 
> > Once I read a bit more of the kernel documentation it wasn't too bad to
> > create a list of what I needed.
> 
> Which documentation in particular?

Documentation/admin-guide/README.rst from inside the kernel tarball
source.

> 
> > tar xf $(guix build linux-libre -S)
> > cd linux-libre
> > touch .config
> > guix environment linux-libre
> > make localmodconfig
> >
> > copy that into .config
> 
> Copy what into .config?

the .config you just created at the root of the source tarball

> 
> > and fix the formatting
> >
> > make localmodconfig
> 
> Why fixing the formatting?  How?  With a second `make localmodconfig'?
> 

running make localconfig spits out a bunch of pseudo-error messages
about modules that are missing in .config. If you copy that whole
message, minus the lines starting with 'WARING', into .config and
then format it as UPERCASE_OPTION=(y|m) it gives the kernel a config
that is usable for it.

so turning lines that look like:
module nouveau did not have configs CONFIG_DRM_NOUVEAU

into lines that look like:
CONFIG_DRM_NOUVEAU=m

> > if that works well enough then add "CONFIG_MODULES=y" to .config and
> > you're ready to try it out.
> 
> What does CONFIG_MODULES=y change?  (Not on my computer now, can't check
> in my local linux checkout.)

CONFIG_MODULES=y lets the modules be loaded and installed separately, if I
remember correctly. Either way, without it the build errors right at the
beginning of the install phase:

starting phase `install'

The present kernel configuration has modules disabled.
Type 'make config' and enable loadable module support.
Then build a kernel with module support enabled.

make: *** [Makefile:1318: modules_install] Error 1

> 
> This walkthrough is invaluable in my opinion.  So far I was under the
> impression that many members of the Guix community were annoyed by
> kernel compilation time and had tried to customize it, but it's really
> hard.  This process would make for an excellent blog article in my
> opinion! :D

I'll try to go ahead and write it up more nicely then. Custom compiling
a kernel sounds really scary, but with Guix's rollbacks and declarative
everything it's actually not too bad.


Currently this doesn't take into account the initrd.

-- 
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: Video narration

[Laura Lazzati]

Hi!

> I had help from a sound engineer who is familiar with the microphone
> set-up and the recording process.
>
GREAT!
>
>
> For the cli sessions we used the timings in your recordings as a guide
> to synchronize my voice with the screen.  I notice that there are
> 'sleep' commands in the session files so it might be possible to fine-
> tune the timing if necessary.
Yes! I am working on them to have the best match we can :)

Regards :)
Laura

Re: Video narration

[sirgazil]

El 3/04/19 a las 9:05 a. m., Paul Garlick escribió:

Hi Laura,

The recording session went very well yesterday.  We were able to make
all the recordings in a studio without having to worry about background
noise.

I had help from a sound engineer who is familiar with the microphone
set-up and the recording process.


Nice and clear voice. Great!


--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: Video narration

[Gábor Boskovits]

Hello Paul,

Paul Garlick  ezt írta (időpont: 2019.
ápr. 3., Sze 16:05):

> Hi Laura,
>
> The recording session went very well yesterday.  We were able to make
> all the recordings in a studio without having to worry about background
> noise.
>

That's wonderful. Thanks so much. I will listen to them as soon as I get
better.

>
> I had help from a sound engineer who is familiar with the microphone
> set-up and the recording process.
>
> > Great!  :)  Let me know when you have time to push them  - no rush,
> > just to test  :) -
>
> I have pushed the first set of audio files, for the 01-installation-
> from-script video.  I have been able to re-build the video to check
> that it works.  It does!
>
> For the cli sessions we used the timings in your recordings as a guide
> to synchronize my voice with the screen.  I notice that there are
> 'sleep' commands in the session files so it might be possible to fine-
> tune the timing if necessary.
>
> Best regards,
>
> Paul.
>

Best regards,
g_bor

>
>

Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Ricardo Wurmus]

Per Bothner  writes:

> On 4/2/19 1:12 PM, Ricardo Wurmus wrote:
>> As far as I know GNOME’s Yelp is a frontend to different kinds of
>> documentation and it does support Info files.
>
> That reads *info* files.  We're talking about reading *html* files.
> See Gavin's original message for why we want to use html.

FWIW Yelp also reads HTML files (and many more formats), though I
haven’t yet tried this successfully with our Guix manual.

Yelp unfortunately doesn’t utilize the Info manual’s index, which is a
great loss in my opinion.  The info files are rendered with hard line
breaks; the info format seems to make it hard to support variable width
paragraphs, syntax highlighting in code snippets / examples, etc,
because it doesn’t seem to retain markup.

Yelp has a few bugs when rendering Info files; links to other Info
documents don’t seem to work (e.g. references to the Guile manual in the
Guix manual), for example, and images are not shown either.

--
Ricardo

Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Per Bothner]

On 4/3/19 7:23 AM, sirgazil wrote:


Sorry, I don't understand. Documents in Yelp seem to adapt to some extent to 
the screen width (text reflows, for example). Videos an images don't adapt well 
to the screen width in the version I'm using, and info documents seem to have a 
fixed width.


Yes, that's what we're talking about: info documents.
This is not a matter of improving Yelp: the info file format inherently
does not support reflow, or mixing a variable-width font (for main text)
with a fixed-width font (for code).

That is why we're talking about having makeinfo convert texinfo to html
instead of info, and installing html in distributions.
--
--Per Bothner
p...@bothner.com   http://per.bothner.com/

Re: Video narration

[sirgazil]

El 3/04/19 a las 9:05 a. m., Paul Garlick escribió:

Hi Laura,

The recording session went very well yesterday.  We were able to make
all the recordings in a studio without having to worry about background
noise.

I had help from a sound engineer who is familiar with the microphone
set-up and the recording process.


Great!  :)  Let me know when you have time to push them  - no rush,
just to test  :) -


I have pushed the first set of audio files, for the 01-installation-
from-script video.  I have been able to re-build the video to check
that it works.  It does!



Yay!

--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: Any interest in using HTML for locally-installed Texinfo documentation?

[sirgazil]

El 3/04/19 a las 3:43 a. m., Gavin Smith escribió:

On Tue, Apr 02, 2019 at 06:09:40PM -0500, sirgazil wrote:

El 2/04/19 a las 5:10 p. m., Per Bothner escribió:

On 4/2/19 1:12 PM, Ricardo Wurmus wrote:

As far as I know GNOME’s Yelp is a frontend to different kinds of
documentation and it does support Info files.


That reads *info* files.  We're talking about reading *html* files.
See Gavin's original message for why we want to use html.


Isn't it more about "increase the ease of
accessing documentation, including documentation locally installed on
a user's own computer.  When a user is using a bitmapped display (e.g.
with X11), this could become the default way that they access
documentation."?


Variation of fonts and text reflowing, as I said in my original message.


Sorry, I don't understand. Documents in Yelp seem to adapt to some 
extent to the screen width (text reflows, for example). Videos an images 
don't adapt well to the screen width in the version I'm using, and info 
documents seem to have a fixed width.


As for fonts, Yelp seems to use the same fonts for the kind of documents 
it supports. Isn't it desirable to present all documents uniformly?


However, Yelp seems to use WebKit (I'm not sure), and GNOME and GTK 
components are being modified to adapt to different screen sizes to 
support mobile devices. So problems of adaptability of the content to 
the size of the screen will likely disappear...



--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: Video narration

[Paul Garlick]

Hi Laura,

The recording session went very well yesterday.  We were able to make
all the recordings in a studio without having to worry about background
noise.

I had help from a sound engineer who is familiar with the microphone
set-up and the recording process.

> Great!  :)  Let me know when you have time to push them  - no rush,
> just to test  :) -

I have pushed the first set of audio files, for the 01-installation-
from-script video.  I have been able to re-build the video to check
that it works.  It does!

For the cli sessions we used the timings in your recordings as a guide
to synchronize my voice with the screen.  I notice that there are
'sleep' commands in the session files so it might be possible to fine-
tune the timing if necessary.

Best regards,

Paul.

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

Hi Mathieu,

> I don't get very well the Linux graphics stack but my understanding is
> that passing "nomodeset" to Linux will disable KMS and thus kmscon won't
> work. Is that correct ?

I don't know.  It might be the case but I doubt it.  Why would kmscon remove
a perfectly fine fallback that's pretty similar to use anyway?

There's an example in kmscon's README that has:

$ ./configure --with-video=fbdev,drm2d [...]

Reading configure.ac, I get the impression that this means that there are two
backends then, fbdev and drm2d, and the user can select one.

I suggest that we use fbdev (maybe at runtime, but maybe just disable everything
else :P).

I'm very much minimalist especially in system installers.  So many things can
go wrong and it's much better to have *some* system than to have no system
installed :)


pgpxmba2DxlBD.pgp
Description: OpenPGP digital signature

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

On Wed, 03 Apr 2019 09:19:01 +0200
Mathieu Othacehe  wrote:

> Hello Florian,
> 
> > Not using KMScon would prevent support for the Chinese and Japanese
> > language during install, would it not?  
> 
> Yes and for other languages too.

Yeah, but doesn't kmscon support vesa?  I mean I know the name kinda implies
kernel modesetting, but doesn't it have a framebuffer fallback?

I do mean we keep graphics terminal, but just use vesa instead of kms in order
to set the graphics mode up.  (If that works)


pgpDbTMgy9Vbz.pgp
Description: OpenPGP digital signature

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Wed, Apr 03, 2019 at 06:17:25AM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 02, 2019 at 01:42:38PM +0200, pelzflorian (Florian Pelz) wrote:
> > The more current commit 0e558640361b6ab4aac0f424cb587b21a642bab8
> > without the patch runs into a Guile prompt because of an error in
> > resolve-variable of something with setuid-binaries on grandma’s laptop
> > and into a different error and a Guile prompt on QEMU with
> > [   9.426604] random: dbus-uuidgen: uninitialized urandom read (12 bytes 
> > read)
> > [   9.518845] attempt to access beyond end of device
> > [   9.519037] sda: rw=524288, want=3194596, limit=3184000
> > ERROR: In procedure primitive-load:
> > In procedure fport_read: Input/output error
> > 
> > 0e558640361b6ab4aac0f424cb587b21a642bab8 with the AMD Radeon patch
> > runs into a kernel panic on QEMU and grandma’s laptop.  I have not
> > tested AMD Radeon.
> > 
> > Regards,
> > Florian
> > 
> 
> I am still bisecting.  Will report back.
> 

For me QEMU does not work since commit
45c0d1d790f01ebc020fc4b2787a6abcdaa3f383

But reverting it means creating the ISO runs out of memory, so I
cannot currently test if Mathieu’s patch works on my AMD GPU PC.

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

Ludovic Courtès  writes:

> Mathieu Othacehe  skribis:
>
>> Here's a patch that fallback to mingetty if kmscon is not supported. I
>> don't have a machine with AMD GPU for testing so if Florian or Pierre
>> could test the patch that would be very helpful :)
>
> That was fast, thanks!
>
> We’ll wait for your feedback Florian & Pierre.  :-)

Sadly it didn't work for me.
Commit 44e06f9cf39e50f91ba61f3e66981b8d10ad545c, linux 5.0.5.
The kernel boots until those 2 messages:

--8<---cut here---start->8---
[drm amdgpu kernel modesetting enabled
fb0: switching to amdgpudrmfb from EFI VGA
--8<---cut here---end--->8---

From there it hangs, Alt-f2 does not do anything.
Only Ctrl-Alt-Del works :/

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Quicklisp importer bug in tarball->extract->parse

[Pierre Neidhardt]

Hi,

thanks for your work!  I'll look into it Very Soon™.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Gavin Smith]

On Tue, Apr 02, 2019 at 06:09:40PM -0500, sirgazil wrote:
> El 2/04/19 a las 5:10 p. m., Per Bothner escribió:
> >On 4/2/19 1:12 PM, Ricardo Wurmus wrote:
> >>As far as I know GNOME’s Yelp is a frontend to different kinds of
> >>documentation and it does support Info files.
> >
> >That reads *info* files.  We're talking about reading *html* files.
> >See Gavin's original message for why we want to use html.
> 
> Isn't it more about "increase the ease of
> accessing documentation, including documentation locally installed on
> a user's own computer.  When a user is using a bitmapped display (e.g.
> with X11), this could become the default way that they access
> documentation."?

Variation of fonts and text reflowing, as I said in my original message.

Re: Software Heritage & Guix

[Giovanni Biscuolo]

Hello Guix!

mikadoZero  writes:

> Ludovic Courtès writes:
>
>> ... 
>> Long-term archival is something that cannot be left to peer-to-peer
>> networks:

I disagree here: P2P/decentralized archival is a _resilient_ archival
method and is _not_ in contrast with long-term: a group of users
(including institutions at various levels) can decide that some or all
of a "decentralized Software Heritage" archive deserves availability
guarantees :-)

[...]

> There is a relevant section in their documentation on pinning services
> which seems to address this directly:
>
> https://docs.ipfs.io/guides/concepts/pinning
>
> So maybe peer to peer data storage networks can do long-term archival.

so maybe Software Heritage could have a decentralized storage model
instead of a centralized one... but this have direct implications on
what content swh can store (I mean non-free sofware)

anyway decentralized storage (IPFS/gnu:net)is already in Guix radar,
could be in swh radar too :-)

"decentralized software heritage" could even be an interesting
application on top secushare :-O

thanks! Gio

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: custom kernel config

[Chris Marusich]

Efraim Flashner  writes:

> I'm playing around with the idea of creating a custom kernel

Cool!  I'm curious to know how you're passing the custom config in.  Are
you using the #:extra-options keyword argument of the make-linux-libre
procedure?  Are you passing in a procedure to generate the entire custom
configuration via the #:configuration-file keyword argument?  Something
else?

-- 
Chris


signature.asc
Description: PGP signature

Re: Building custom kernel modules (e.g. VHBA for CDEmu)

[Chris Marusich]

Pierre Neidhardt  writes:

> The only thing we need, beside a C compiler, is this KDIR, which on Guix
> _could_ be found at
>
>   /gnu/store/…-linux-libre-5.0.1/lib/modules/5.0.1/build
>
> Sadly, for us it's a dangling link to
> /tmp/guix-build-linux-libre-5.0.1.drv-0/linux-5.0.1.
>
> I presume that the answer is simple: replace the link with the folder.
> But that would eat up significantly more disk space.  So we could
> replace the link with a link to a new "build" output of the linux-libre
> package, which would contain this "build" folder.

If that's all it takes, then it makes sense to me.  Do we have any
experienced kernel hackers on the list who can comment more on this?

-- 
Chris


signature.asc
Description: PGP signature

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

Hey Danny,

I don't get very well the Linux graphics stack but my understanding is
that passing "nomodeset" to Linux will disable KMS and thus kmscon won't
work. Is that correct ?

I'm going to try it on my hardware today to see how it goes anyway.

Thank you,

Mathieu

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Wed, Apr 03, 2019 at 09:19:01AM +0200, Mathieu Othacehe wrote:
> 
> Hello Florian,
> 
> > Not using KMScon would prevent support for the Chinese and Japanese
> > language during install, would it not?
> 
> Yes and for other languages too.
> 

Other languages could work with a console font appropriate for the
language, I think.  Only a limited number of characters can be
supported, but the limited number is sufficient for other languages
once the appropriate subset of characters is selected.  Nevertheless
Chinese characters are important and too many.




> > Currently there is no support because
> >
> > · the Chinese and Japanese locales are not added to the installer, it
> >   only includes glibc-utf8-locales,
> >
> > · there is no translated PO file for the installer yet anyway,
> >
> > but otherwise it would work, would it not?
> 
> Yes, I tried to add Japanese translations into an existing PO and it
> worked fine with the installer.
> 
> >
> > However, this means in particular that
> >
> > · when using KMScon, the installer should change the locale that gets
> >   used once it is selected,
> 
> It's done :)
> 
> >
> > · when using mingetty, the locale should only be changed for languages
> >   other than Chinese and Japanese,
> 
> When using mingetty, the logic with the patch you tested is to fallback
> to a raw terminal and force a "manual" install.
> 
> >
> > · the console font should be changed to match the locale similar to
> >   console-setup on Debian.
> 
> The installer uses GNU Unifont so that most unicode characters are
> covered.
> 
> Mathieu

OK, thank you!

Re: create a symlink

[Chris Marusich]

Hi Rene,

Rene  writes:

> On the other hand, in linux there is `--system` argument, how does this
> argument work?, Is there a script that uses it?. To test `--system`, I
> removed it from my linux system and when loging in with my user it does not
> detect any command.
>
> BOOT_IMAGE=/gnu/store/fiqgyafknihbvmz4j62ddb67p79kfcbk-linux-libre-4.19.13/bzImage
>  --root=my-root --system=/var/guix/profiles/system-87-link 
> --load=/var/guix/profiles/system-87-link/boot

To see how the Linux kernel argument "--system" is used, check out the
"boot-time-system" procedure in gnu/build/activation.scm.  Ultimately
this is used by the activation-service-type, defined in
gnu/services.scm.

In short, when the system boots, the activation service will atomically
flip the "/run/current-system" symlink. and then run all the activation
scripts defined by services that extend the activation service.  The
value of "--system" can be overridden by setting the GUIX_NEW_SYSTEM
environment variable; in fact, we do that in the switch-to-system
procedure in guix/scripts/system.scm, which is used when running
commands like "guix system reconfigure", "guix system roll-back," and
"guix system switch-generation".

Hopefully that helps!

-- 
Chris


signature.asc
Description: PGP signature