Re: Program to build the on-line manuals (HTML + PDF)

[pelzflorian (Florian Pelz)]

Gavin Smith from Texinfo has made numerous commits there at Texinfo in
the past years to support xelatex to support UTF-8, but I could not
get it to work.  Maybe Gavin Smith knows how to produce the non-Latin
PDF manuals?  It seems it is undocumented.

On Mon, May 20, 2019 at 11:52:53PM +0200, Ricardo Wurmus wrote:
> I haven’t been able to successfully run it yet.  I’m on the master
> branch and issued
> 
> GUIX_MANUAL_VERSION=1.0.1 ../pre-inst-env guix build -f build.scm
> 
> from within the “doc” directory, but this is what I get:
> 
> --8<---cut here---start->8---
> ;;; (repo "/home/rekado/dev/gx/branches/master/doc/..")
> guix build: error: failed to load 'build.scm':
> git/branch.scm:101:8: Git error: cannot locate remote-tracking branch 
> 'origin/version-1.0.1'
> --8<---cut here---end--->8---
> 

I do `GUIX_MANUAL_VERSION=1.0.1 guix build -f doc/build.scm`; it works
for me.

Regards,
Florixsan

gnome-shell and LD_LIBRARY_PATH

[Ricardo Wurmus]

Hi Guix,

I just noticed that LD_LIBRARY_PATH is set in my shell environments.
Looking at the directories it contains I realised that this is because
of gnome-shell.

When I set LD_LIBRARY_PATH in the “wrap-programs” phase of the
“gnome-shell” package I did not expect all running programs in a GNOME
session to inherit it.

What do you think: can we find a way to get rid of it?  Either from
the gnome-shell package or from the GNOME environment in which other
applications are started?

--
Ricardo

Re: Video narration

[Laura Lazzati]

Hi!


> For what is worth, they could also be uploaded to https://archive.org/
Interesting! I was thinking about sth internal for the community first
but the environment for the creation is available, so no problem for
me. What do the others think?

BTW, I finished generating the videos.
Sth weird happens with totem. I end up having a segmentation fault,
here is the output.
I found the issue with the first cli session video of the installation
tutorial. - I will be updating the output with the new release info ;)

Version: totem3.26.2, Ubuntu 18.04 foreign distro.
guix (GNU Guix) 7a890145e3bc9d7aebd753ab2ccc3ba1aecfaf06

<-start-->
totem 01-installation-from-script.webm
Gtk-Message: 22:12:19.594: Failed to load module "canberra-gtk-module"
Gtk-Message: 22:12:19.596: Failed to load module "canberra-gtk-module"

(totem:1963): Gtk-WARNING **: 22:12:19.870:
gtk_window_present_with_time() should not be called with 0, or
GDK_CURRENT_TIME as a timestamp, the timestamp should instead be
gathered at the time the user initiated the request for the window to
be shown

(totem:1963): Gtk-WARNING **: 22:12:20.221: Drawing a gadget with
negative dimensions. Did you forget to allocate a size? (node slider
owner GtkScale)

(totem:1963): libpeas-WARNING **: 22:15:13.273: Type not found in
introspection: 'PeasActivatable'

(totem:1963): libpeas-WARNING **: 22:15:13.274: Method
'PeasActivatable.deactivate' was not found
Segmentation fault (core dumped)
<-end-->

/var/log/kern.log:
<-start-->

May 20 22:11:47 ada kernel: [  101.858689] ..totem-real-re[1841]:
segfault at 0 ip 7f3a61cc78ad sp 7fff1fa7f120 error 4 in
libmovie-properties.so[7f3a61cc6000+3000]
May 20 22:15:13 ada kernel: [  307.229149] ..totem-real-re[1963]:
segfault at 0 ip 7ff15f39c8ad sp 7fffdb0fe3c0 error 4 in
libmovie-properties.so[7ff15f39b000+3000]

<-end-->

/var/log/syslog
<-start-->
May 20 22:11:00 ada /usr/lib/gdm3/gdm-x-session[940]: (II) modeset(0):
EDID vendor "VBX", prod id 0
May 20 22:11:00 ada /usr/lib/gdm3/gdm-x-session[940]: (II) modeset(0):
DDCModeFromDetailedTiming: 1315x669 Warning: We only handle separate
sync.
May 20 22:11:00 ada /usr/lib/gdm3/gdm-x-session[940]: (II) modeset(0):
Using hsync ranges from config file
May 20 22:11:00 ada /usr/lib/gdm3/gdm-x-session[940]: (II) modeset(0):
Using vrefresh ranges from config file
May 20 22:11:01 ada org.gnome.Shell.desktop[1113]: Window manager
warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a
timestamp of 0 for 0x2a00013 ()
May 20 22:11:27 ada gnome-software[1864]: plugin appstream took 3,3
seconds to do setup
May 20 22:11:27 ada gnome-software[1864]: enabled plugins: os-release,
packagekit-offline, packagekit-refresh, packagekit-proxy,
packagekit-local, systemd-updates, shell-extensions, fwupd,
packagekit-upgrade, packagekit, packagekit-refine-repos, ubuntuone,
packagekit-url-to-app, desktop-categories, appstream, modalias,
hardcoded-featured, rewrite-resource, hardcoded-popular, odrs,
hardcoded-blacklist, packagekit-refine, generic-updates,
desktop-menu-path, steam, snap, provenance, packagekit-history,
provenance-license, icons, key-colors, key-colors-metadata
May 20 22:11:27 ada gnome-software[1864]: disabled plugins: dummy,
repos, dpkg, epiphany
May 20 22:11:28 ada dbus-daemon[633]: [system] Activating via systemd:
service name='org.freedesktop.fwupd' unit='fwupd.service' requested by
':1.69' (uid=1000 pid=1864 comm="/usr/bin/gnome-software
--gapplication-service " label="unconfined")
May 20 22:11:28 ada systemd[1]: Starting Firmware update daemon...
May 20 22:11:28 ada fwupd[1887]: disabling plugin because: failed to
startup dell: Firmware updating not supported
May 20 22:11:28 ada fwupd[1887]: disabling plugin because: failed to
startup uefi: UEFI firmware updating not supported
May 20 22:11:28 ada fwupd[1887]: disabling plugin because: failed to
coldplug amt: Unable to find a ME interface
May 20 22:11:28 ada fwupd[1887]: disabling plugin because: failed to
coldplug thunderbolt_power: No support for force power via kernel or
bolt
May 20 22:11:28 ada fwupd[1887]: disabling plugin because: failed to
coldplug synapticsmst: MST firmware updating not supported by OEM
May 20 22:11:28 ada fwupd[1887]: using plugins: unifying, ebitdo,
steelseries, thunderbolt, colorhug, udev, upower, altos, wacomhid,
dfu, nitrokey, csr
May 20 22:11:28 ada fwupd[1887]: Daemon ready for requests
May 20 22:11:29 ada dbus-daemon[633]: [system] Successfully activated
service 'org.freedesktop.fwupd'
May 20 22:11:29 ada systemd[1]: Started Firmware update daemon.
May 20 22:11:30 ada PackageKit: get-updates transaction /206_bcbdaaac

Re: Program to build the on-line manuals (HTML + PDF)

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Here’s a build program I used to generate all the gnu.org/s/guix/manual
> hierarchy, with all the languages, HTML and PDF.
>
> You can drop in your Guix tree and run, say:
>
>   GUIX_MANUAL_VERSION=1.0.1 guix build -f build.scm
>
> to build the manual for 1.0.1.

Neat!

It seems that this must be run from the “doc” directory, because it
assumes that the git repository root is in the parent directory of the
current working directory.

I haven’t been able to successfully run it yet.  I’m on the master
branch and issued

GUIX_MANUAL_VERSION=1.0.1 ../pre-inst-env guix build -f build.scm

from within the “doc” directory, but this is what I get:

--8<---cut here---start->8---
;;; (repo "/home/rekado/dev/gx/branches/master/doc/..")
guix build: error: failed to load 'build.scm':
git/branch.scm:101:8: Git error: cannot locate remote-tracking branch 
'origin/version-1.0.1'
--8<---cut here---end--->8---

> Regarding PDFs, I failed to use something smaller than the big ‘texlive’
> package.  I’d very much welcome help in that area!

I’ll try to debug this and report back.

-- 
Ricardo

Re: More progress with the Guix Data Service

[Christopher Baines]

Ludovic Courtès  writes:

>> As well as listening to the Guix Commits mailing list for emails about
>> new revisions, more of the information in these emails is now stored, in
>> particular, the time they were sent, and the branch the email applies
>> to. This can be seen on the new Branches page [4].
>>
>> 4: https://prototype-guix-data-service.cbaines.net/branches
>
> This is really nice.
>
> This information could also be gathered directly from the repo though,
> right?
>
> I would expect only patch submission info, and possibly commit
> notifications, to be grabbed from email, while the rest would be
> extracted from the repo, thereby hopefully limiting the risk of
> misinterpreting email.  WDYT?

So, currently the branch name, commit hash and date are taken from the
email. As far as I know, git branches are just pointers to commits, and
don't have any date/time associated with them. The commit date, or
author date in the commits could be stored and used, but I think these
are less interesting, and often misleading. The author date is often
quite different from the time a commit is pushed, and the commit date is
often different by some amount as well.

Currently, if you actually want to know what was the state of a
particular branch in the Guix git repository on Savannah was, at a
particular time, I think the most reliable way of checking would
probably be to check the guix-commits mailing list.

As the branch name, and commit hash both relate to the date, I don't see
that much problem with storing them.

One thing I've also been thinking about is loading in the guix-commits
mailing list archives. That would backfill the branch information, which
might be useful/interesting...

I did consider trying to access the clone of the Git repository that's
managed by the (guix inferiors) module, but I couldn't see an easy way
to do it, and as above, I'm not sure the date/time information is as
useful as what you can get from the mailing list.

>> There's now a basic search function on the packages page [5], and the
>> location, and the licenses for packages is now being stored (which can
>> be seen on the page for a package, for example [6]).
>>
>> 5: 
>> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages?search_query=Guile=version=synopsis_name=_results=1000
>> 6: 
>> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/package/0ad/0.0.23b-alpha
>
> Nice!
>
> One thing that be great is a page similar to
> ,
> but keyed by package, where you get a list of the recent package
> versions (and/or derivations) and map them to specific commits.

Interesting, yeah, were you thinking of filtering that data for a
specific branch (like master or staging), or showing data for all
branches?

>> The URL is a bit long, but I think that is now close to being possible
>> with the Guix data service. I haven't got something working yet to
>> easily access data for the latest revision, but for a particular
>> revision, you can request a JSON file containing all the information I
>> think Repology currently gets about all packages. For example:
>>
>>   
>> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages.json?field=version=synopsis=description=home-page=location=licenses_results=9
>
> Awesome.  (I advise passing “limit_results=900” though, because the URL
> above gives a pretty big result.  ;-))

Well, not that big? Icecat tells me it's 12MB. Also, I've recently added
a "All results" checkbox/query parameter, so you no longer have to make
up a large number. I wanted to make it possible to get all the data as a
single file, as that could simplify processing it, but there's also some
support for pagination.

  
https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages.json?field=version=synopsis=description=home-page=location=licenses_results=on

The all results option is especially important as I've now done some
work on caching. That page should be served with a max-age of a day, it
could probably be even longer as well, as the only thing that will
change the contents is software changes. NGinx is also now caching
responses, and you can see what it's doing by looking at the
X-Cache-Status header in the response.

>> This is just the software side of the problem though. If this was to be
>> used by Repology, it would have to be a more permanent thing, similar to
>> the Cuirass and Mumi services that are currently setup around Guix. Does
>> anyone have any thoughts on this?
>
> I’d suggest having a Guix service for the whole thing, and making a
> branch in guix-maintenance.git such that bayfront (say) can run the
> service.
>
> Then we’ll have to reach consensus on guix-sysadmin as to which machine
> to 

Re: guix pack -f docker and name ?

[Ricardo Wurmus]

zimoun  writes:

>> You’ve already proposed other improvements to ‘guix pack -f’, and I
>> think you should email a concise reminder to each specific improvement
>> to bug-guix so we keep track of them.  I may be able to work on them
>> soonish.
>
> Ok.
> You mean one "ticket" by minor "feature"?
> Or one "ticket" collecting all the minor improvements (items)?

Let’s have one bug per independent feature.  It’s very motivating to be
able to implement a small feature and close its associated bug report —
much more so than to bite off a small piece of a large report that you
don’t get to close afterwards :)

-- 
Ricardo

Re: guix pack -f docker and name ?

[zimoun]

Hi ludo,

On Mon, 20 May 2019 at 17:42, Ludovic Courtès  wrote:
>
> Hi Simon,
>
> zimoun  skribis:
>
> > 1.
> > The name of the tar is given at the end of the command `guix pack`. If
> > you forget to track it, then you need to re-run `guix pack` (obviously
> > with the very same parameters) to get it again.
> > It is not super user-friendly. :-)
> >
> > What to think to add an option to name a symbolic link to this file in
> > the store ?
> >
> > Currently, I am doing that by hand:
> >   guix pack -f docker ...
> >   # copy the name /gnu/store/-docker-pack.tar
> >   ln -s paste my-name
> >
> > In general, I choose my-name as - with 
> > something to quickly remember what it is and the  to be sure of
> > what it is.
>
> I think ‘guix pack’ should have a ‘-r/--root’ option like ‘guix build’
> so you can do:
>
>   guix pack -r my-image -f docker foo bar baz
>
> WDYT?

Yes, it better fits what I am more or less doing by hand.
Nice `guix pack` owns this option.

>
> > 2.
> > Once loaded with `docker load < /gnu/store/-docker-pack.tar`
> > then `docker image ls` list all the images. The REPOSITORY and TAG are
> > not super helpful. :-)
> > It is always: profile and .
> >
> > Maybe REPOSITORY should be guix and TAG should be -.
> > Because when one has more than 2 images, after holidays it is not
> > possible to remember or they needs to track in a separate file what it
> > is.
>
> I agree, we can do better here.  :-)
>
> We could allow for user-provided names, and/or, when ‘--save-provenance’
> is used, we could show the commit ID or something.
>
> Ideas?

I was proposing:
 guix pack -f docker -r foo
generates the file:
/gnu/store/-docker-pack.tar
where the symlink foo to this file and the field REPOSITORY should be
guix and the field TAG should `foo-` where `
is let say 6 characters.

I do not know if it is the right way. What do people using Docker think ?


> You’ve already proposed other improvements to ‘guix pack -f’, and I
> think you should email a concise reminder to each specific improvement
> to bug-guix so we keep track of them.  I may be able to work on them
> soonish.

Ok.
You mean one "ticket" by minor "feature"?
Or one "ticket" collecting all the minor improvements (items)?

All the best,
simon

Re: [BLOG] custom kernel config

[Efraim Flashner]

On Mon, May 20, 2019 at 04:57:28PM +0200, Ludovic Courtès wrote:
> Hello Efraim,
> 
> Like I wrote before, I like the tone and how the post addresses the
> topic.  So I just have minor cosmetic suggestions, and then I guess you
> can push to guix-artwork.git and we can put it on-line maybe tomorrow?
> 
> Efraim Flashner  skribis:
> 
> > Guix is, at its core, a source based distribution with substitutes, and
>  ^~
> Perhaps link to
> 
> here.
> 

Done

> > as such building packages from their source code is an expected part of
> > regular package installations and upgrades.  Given this starting point,
> > it makes sense that efforts are made to reduce the amount of time spent
> > compiling packages, and recent changes and upgrades to the building and
> > distribution of substitutes continues to be a topic of discussion within
> > Guix.  One of the packages which I prefer to not build myself is the
>^
> Start a new paragraph here?
> 

Ok

> > The linux-libre kernel package definition is actually a procedure which
>   ^
> Please make sure to write `linux-libre` (with backquotes) for all the
> identifiers, file names, and commands that appears in the post, notably
> all the CONFIG_* identifiers.
> 
> Perhaps you can also link to
> ?
> 

I also added one when I got to the snippet referencing line 379.

> > (define-public linux-libre-macbook41
> >   ;; XXX: Access the internal 'make-linux-libre' procedure, which is
> >   ;; private and unexported, and is liable to change in the future.
> >   ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) 
> > %linux-libre-version)
> 
> Can this one be rewritten using the ‘inherit’ idiom that was discussed?
> If not, that’s probably OK since you explicitly write that this is not
> the recommended approach.

Unfortunately I don't think it's possible. We're modifying the output
from the `make-linux-libre` procedure, not the package and its inputs
it's wrapped in. I don't think it's possible without calling the
procedure, at which point we may as well call it directly.

I also didn't parameterize the %linux-libre-5.1-patches reference, but
buyer beware on that kernel definition :)

> 
> Thanks for your work!
> 
> Ludo’.

-- 
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: gold linker and collect2: fatal error: cannot find 'ld'

[Ludovic Courtès]

Hi Pierre,

Pierre Neidhardt  skribis:

> So it seems that the following change to make-ld-wrapper triggers a
> rebuild of the world on every "guix build".  Any idea why?  Ludo?

“Everything” depends on ‘ld-wrapper’ (see commencement.scm), so you have
to come up with changes that do not modify the default ‘ld-wrapper’.

>  (ld  ,(if target
> -  `(string-append bin "/" ,target "-ld")
> -  '(string-append bin "/ld")))
> +  `(string-append bin "/" ,target "-" 
> ,linker-name)
> +  `(string-append bin "/" ,linker-name)))

In these two cases, you’re changing the generated code from:

  (string-append bin "/" … "-ld")
  (string-append bin "/ld")

to:

  (string-append bin "/" … "-" "ld")
  (string-append bin "/" "ld")

To avoid a rebuild, you’ll have to special-case “ld” such that the
generated code is unchanged.

HTH!

Ludo’.

Re: guix pack -f docker and name ?

[Ludovic Courtès]

Hi Simon,

zimoun  skribis:

> 1.
> The name of the tar is given at the end of the command `guix pack`. If
> you forget to track it, then you need to re-run `guix pack` (obviously
> with the very same parameters) to get it again.
> It is not super user-friendly. :-)
>
> What to think to add an option to name a symbolic link to this file in
> the store ?
>
> Currently, I am doing that by hand:
>   guix pack -f docker ...
>   # copy the name /gnu/store/-docker-pack.tar
>   ln -s paste my-name
>
> In general, I choose my-name as - with 
> something to quickly remember what it is and the  to be sure of
> what it is.

I think ‘guix pack’ should have a ‘-r/--root’ option like ‘guix build’
so you can do:

  guix pack -r my-image -f docker foo bar baz

WDYT?

> 2.
> Once loaded with `docker load < /gnu/store/-docker-pack.tar`
> then `docker image ls` list all the images. The REPOSITORY and TAG are
> not super helpful. :-)
> It is always: profile and .
>
> Maybe REPOSITORY should be guix and TAG should be -.
> Because when one has more than 2 images, after holidays it is not
> possible to remember or they needs to track in a separate file what it
> is.

I agree, we can do better here.  :-)

We could allow for user-provided names, and/or, when ‘--save-provenance’
is used, we could show the commit ID or something.

Ideas?

You’ve already proposed other improvements to ‘guix pack -f’, and I
think you should email a concise reminder to each specific improvement
to bug-guix so we keep track of them.  I may be able to work on them
soonish.

Thank you!

Ludo’.

Re: More progress with the Guix Data Service

[Ludovic Courtès]

Christopher Baines  skribis:

>>>
>>> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages.json?field=version=synopsis=description=home-page=location=licenses_results=9
>>
>> FWIW it is very slow.

This particular request is asking for a *lot* of data, and I guess
IceCat takes a while to simply parse and pretty-print that data.

> To be honest, I'm actually pretty happy with the speed! I was worried
> that NGinx was going to time out and that it wasn't even going to work.

I found everything to be snappy, kudos!

Ludo’.

Re: More progress with the Guix Data Service

[Ludovic Courtès]

Hi!

Christopher Baines  skribis:

> Since then, I've made some more progress. There's a new statistics page
> [2]. I've got used to using Sqitch [3] to help manage the database
> schema, and I've added some basic tests.

The URL for [2] is actually:

  https://prototype-guix-data-service.cbaines.net/statistics

(with an ‘s’.)  See, I paid attention!   ;-)

> As well as listening to the Guix Commits mailing list for emails about
> new revisions, more of the information in these emails is now stored, in
> particular, the time they were sent, and the branch the email applies
> to. This can be seen on the new Branches page [4].
>
> 4: https://prototype-guix-data-service.cbaines.net/branches

This is really nice.

This information could also be gathered directly from the repo though,
right?

I would expect only patch submission info, and possibly commit
notifications, to be grabbed from email, while the rest would be
extracted from the repo, thereby hopefully limiting the risk of
misinterpreting email.  WDYT?

> There's now a basic search function on the packages page [5], and the
> location, and the licenses for packages is now being stored (which can
> be seen on the page for a package, for example [6]).
>
> 5: 
> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages?search_query=Guile=version=synopsis_name=_results=1000
> 6: 
> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/package/0ad/0.0.23b-alpha

Nice!

One thing that be great is a page similar to
,
but keyed by package, where you get a list of the recent package
versions (and/or derivations) and map them to specific commits.

> The URL is a bit long, but I think that is now close to being possible
> with the Guix data service. I haven't got something working yet to
> easily access data for the latest revision, but for a particular
> revision, you can request a JSON file containing all the information I
> think Repology currently gets about all packages. For example:
>
>   
> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages.json?field=version=synopsis=description=home-page=location=licenses_results=9

Awesome.  (I advise passing “limit_results=900” though, because the URL
above gives a pretty big result.  ;-))

> This is just the software side of the problem though. If this was to be
> used by Repology, it would have to be a more permanent thing, similar to
> the Cuirass and Mumi services that are currently setup around Guix. Does
> anyone have any thoughts on this?

I’d suggest having a Guix service for the whole thing, and making a
branch in guix-maintenance.git such that bayfront (say) can run the
service.

Then we’ll have to reach consensus on guix-sysadmin as to which machine
to use depending on the resources it needs, but if you have the config,
I’d argue that we can happily run it on bayfront or perhaps berlin.  And
we can give you access to the machine so you can reconfigure once in a
while.

WDYT?

Thanks,
Ludo’.

Re: [BLOG] custom kernel config

[Ludovic Courtès]

Hello Efraim,

Like I wrote before, I like the tone and how the post addresses the
topic.  So I just have minor cosmetic suggestions, and then I guess you
can push to guix-artwork.git and we can put it on-line maybe tomorrow?

Efraim Flashner  skribis:

> Guix is, at its core, a source based distribution with substitutes, and
 ^~
Perhaps link to

here.

> as such building packages from their source code is an expected part of
> regular package installations and upgrades.  Given this starting point,
> it makes sense that efforts are made to reduce the amount of time spent
> compiling packages, and recent changes and upgrades to the building and
> distribution of substitutes continues to be a topic of discussion within
> Guix.  One of the packages which I prefer to not build myself is the
   ^
Start a new paragraph here?

> The linux-libre kernel package definition is actually a procedure which
  ^
Please make sure to write `linux-libre` (with backquotes) for all the
identifiers, file names, and commands that appears in the post, notably
all the CONFIG_* identifiers.

Perhaps you can also link to
?

> (define-public linux-libre-macbook41
>   ;; XXX: Access the internal 'make-linux-libre' procedure, which is
>   ;; private and unexported, and is liable to change in the future.
>   ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) 
> %linux-libre-version)

Can this one be rewritten using the ‘inherit’ idiom that was discussed?
If not, that’s probably OK since you explicitly write that this is not
the recommended approach.

Thanks for your work!

Ludo’.

Program to build the on-line manuals (HTML + PDF)

[Ludovic Courtès]

Hello Guix!

Here’s a build program I used to generate all the gnu.org/s/guix/manual
hierarchy, with all the languages, HTML and PDF.

You can drop in your Guix tree and run, say:

  GUIX_MANUAL_VERSION=1.0.1 guix build -f build.scm

to build the manual for 1.0.1.

It’s rough on the edges so I’d like to polish it and then commit it
under doc/ I guess.  In the meantime, it can be used, for instance to
update the copy of the manual at guix.info.

Regarding PDFs, I failed to use something smaller than the big ‘texlive’
package.  I’d very much welcome help in that area!

Unfortunately, Texinfo cannot produce PDFs for non-Latin alphabets
currently.  It would be nice to see how we can fix it or work around it.

Feedback welcome!

Ludo’.

;;; Copyright © 2019 Ludovic Courtès
;;;
;;; This file is under the GNU General Public License, version 3 or any later
;;; version.

(use-modules (guix)
 (guix gexp)
 (guix git)
 (gnu packages base)
 (gnu packages gawk)
 (gnu packages gettext)
 (gnu packages guile)
 (gnu packages texinfo)
 (gnu packages tex)
 (srfi srfi-11)
 (srfi srfi-19))

(define file-append*
  (@@ (guix self) file-append*))

(define translated-texi-manuals
  (@@ (guix self) translate-texi-manuals))

(define info-manual
  (@@ (guix self) info-manual))

(define %languages
  '("de" "en" "es" "fr" "ru" "zh_CN"))

(define (texinfo-manual-images source)
  "Return a directory containing all the images used by the user manual, taken
from SOURCE, the root of the source tree."
  (define graphviz
(module-ref (resolve-interface '(gnu packages graphviz))
'graphviz))

  (define images
(file-append* source "doc/images"))

  (define build
(with-imported-modules '((guix build utils))
  #~(begin
  (use-modules (guix build utils)
   (srfi srfi-26))

  (define (dot->image dot-file format)
(invoke #+(file-append graphviz "/bin/dot")
"-T" format "-Gratio=.9" "-Gnodesep=.005"
"-Granksep=.5" "-Nfontsize=9"
"-Nheight=.1" "-Nwidth=.1"
"-o" (string-append #$output "/"
(basename dot-file ".dot")
"." format)
dot-file))

  ;; Build graphs.
  (mkdir-p #$output)
  (for-each (lambda (dot-file)
  (for-each (cut dot->image dot-file <>)
'("png" "pdf")))
(find-files #$images "\\.dot$"))

  ;; Copy other PNGs.
  (for-each (lambda (png-file)
  (install-file png-file #$output))
(find-files #$images "\\.png$")

  (computed-file "texinfo-manual-images" build))

(define* (texinfo-manual-source source #:key
(version "0.0")
(languages %languages)
(date 1))
  "Gather all the source files of the Texinfo manuals from SOURCE--.texi file
as well as images, OS examples, and translations."
  (define documentation
(file-append* source "doc"))

  (define examples
(file-append* source "gnu/system/examples"))

  (define build
(with-imported-modules '((guix build utils))
  #~(begin
  (use-modules (guix build utils)
   (srfi srfi-19))

  (define (make-version-texi language)
;; Create the 'version.texi' file for LANGUAGE.
(let ((file (if (string=? language "en")
"version.texi"
(string-append "version-" language ".texi"
  (call-with-output-file (string-append #$output "/" file)
(lambda (port)
  (let* ((version #$version)
 (time(make-time time-utc 0 #$date))
 (date(time-utc->date time)))
;; FIXME: Date.
(format port "
@set UPDATED ~a
@set UPDATED-MONTH ~a
@set EDITION ~a
@set VERSION ~a\n"
(date->string date "~e ~B ~Y")
(date->string date "~B ~Y")
version version))

  (install-file #$(file-append* documentation "/htmlxref.cnf")
#$output)

  (for-each (lambda (texi)
  (install-file texi #$output))
(append (find-files #$documentation "\\.(texi|scm)$")
(find-files #$(translated-texi-manuals source)
"\\.texi$")))

  ;; Create 'version.texi'.
  (for-each make-version-texi '#$languages)

  ;; Copy configuration templates that the manual includes.
  (for-each (lambda (template)
  (copy-file