Typst training slides conversion

[AdamLab5]

Converted the slides of 8 trainings: Audio, Buildroot, Debugging, Embedded-linux, Kernel, Networking, Preempt-RT and Yocto.
As well as common shared files and bootlin packages.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[AdamLab5]

I have read the CLA Document and I hereby sign the CLA.

[alexandrebelloni]

I have a very small patch to fix some issues that probably don't make sense to fix in the automated conversion, I'll apply after this is merged.

[Tropicao]

As discussed with other trainers, the new slides do not have the same size as the former one (on my machine, for debugging training, 12.2MB after, 8.9MB before). As it is suspected to be a reason for the lags observed in pdf viewers when displaying the new materials, I've taken a deeper look into it:

• when using the new theme, we are using a proper 16:9 ratio, resulting in a 11.69in x 6.58in (not a "true A4", as it should rather be 11.69in x 8.27in)
• with the older theme, we also set a 16:9 ratio, but it is interpreted by Beamer as 160mm x 90mm, or 6.30in x 3.54in (sigh)
  So even if our former slides size looks questionable, I tried to replicate it in the new typst theme with the following diff:

diff --git a/typst/local/bootlin/0.1.0/lib.typ b/typst/local/bootlin/0.1.0/lib.typ
index 3d7dc5b79a5f..7962cbf20b1c 100644
--- a/typst/local/bootlin/0.1.0/lib.typ
+++ b/typst/local/bootlin/0.1.0/lib.typ
@@ -515,10 +515,11 @@
   set list(spacing: 0.6em)
   show: touying-slides.with(
     config-page(
-      paper: "presentation-" + aspect-ratio,
+      // paper: "presentation-" + aspect-ratio,
       margin: (x: 2em, top: 20mm, bottom: 6mm),
       footer-descent: 0.5mm,
       header-ascent: 1mm,
+      ..(width: 6.30in, height: 3.54in)
     ),
     config-common(
       slide-fn: slide,

Unfortunately:

• the size remains exactly the same with the adjusted slide size
• the slide set is then broken because everything is too big, resulting in more than twice the correct amount of slides (likely because the new materials heavily use absolute sizes rather than em)

So IMHO it is preferable to keep this new size

[Tropicao]

For the record, I did a quick local test at automating formatting and checked the impact on the branch (checked only for debugging training):

make full-debugging-slides.pdf && cp full-debugging-slides.pdf full-debugging-slides-pre.pdf
find . -name "*typ" -exec /usr/bin/typstyle -i {} \;
make full-debugging-slides.pdf
diff-pdf full-debugging-slides-pre.pdf full-debugging-slides.pdf -s -m --output-diff=diff.pdf

And saw that only a single slide was affected by the reformatting, and the diff looked ok (slight size variation). It could be worth checking the impact for other trainings the impact, and if worth, running this formatting for the whole slides (that would allow to get rid of all the weird indentations, the blanks lines, etc). I'll try to add this as well in the github actions in the next steps.

None of my comments are blocking, every raised point can be handled post-merge. Thanks for your work

[Tropicao]

The intent behind this change is not really clear from the commit message, but I suspect that it does nothing.

[tleb]

Before it meant "ignore PDFs in the root directory", now it means "ignore all PDFs". Are there any PDFs we don't want to ignore?

If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular .gitignore file itself. Otherwise the pattern may also match at any level below the .gitignore level.
— https://git-scm.com/docs/gitignore

[Tropicao]

Ah, then yes, I see plenty of images stored as pdf in the repository, so this change may be undesired

[Tropicao]

I know that it is not really related to your PR, but I'm a bit confused by the manipulation here:

• is it really for evince ? I guess that's rather for the makefile to detect changes, right?
• if so, that's rather that we have a broken rule, because make is supposed to detect change (but I can understand that we may break this with our way to deal with chapters). But wouldn't a bare touch work then ?
• could we remove 'Maxime's feature" ? It does not bring any info

That's ok to integrate it though, but I'm at least writing it down as a todo for the next improvements

[miquelraynal]

IIRC, it is not Makefile related, this is really related to the reader that might not reload the file after mv (?). To be checked again, because things may have changed since this quirk was first introduced.

[alexandrebelloni]

I know that it is not really related to your PR, but I'm a bit confused by the manipulation here:

* is it really for evince ? I guess that's rather for the _makefile_ to detect changes, right?

* if so, that's rather that we have a broken rule, because `make` is supposed to detect change (but I can understand that we may break this with our way to deal with chapters). But wouldn't a bare `touch` work then ?

* could we remove 'Maxime's feature" ? It does not bring any info

That's ok to integrate it though, but I'm at least writing it down as a todo for the next improvements

This is required, using cat updates an existing file vs mv that creates a new file so if you work on slides with the pdf opened by evince/papers, updating the file works while creating a new file doesn't, probably because the fd still points to the old file that has been removed.

[tleb]

This trick can be dropped now (sorry Maxime's feature, we'll remember you). On my system Papers (replacement of evince) reloads if I open out/full-linux-kernel-slides.pdf then update it with make full-linux-kernel-slides.pdf.

The fact that evince didn't reload previously was an issue with how the file was generated by LaTex.

[Tropicao]

This is required, using cat updates an existing file vs mv that creates a new file so if you work on slides with the pdf opened by evince/papers, updating the file works while creating a new file doesn't, probably because the fd still points to the old file that has been removed.

Ok, thanks for the clarification

This trick can be dropped now (sorry Maxime's feature, we'll remember you). On my system Papers (replacement of evince) reloads if I open out/full-linux-kernel-slides.pdf then update it with make full-linux-kernel-slides.pdf.

TIL about Papers

[miquelraynal]

@tleb have you tried with the top level full-linux-kernel-slides.pdf instead?

[miquelraynal]

I just tested with papers and evince: no problem, pdf readers get the update automatically, even with a mv.

This hack can be dropped.

[Tropicao]

As discussed already, the new slides look good overal (focusing on the debugging training on my side)l. Just a few nits here and there that I'm repeating here to keep those saved as a todo list:

• a few kernel links are dead (eg 51, 67). The code is making those point on the latest version, which may be not desirable, as it can make the links silently rot
• there are quite a lot of spaces added for items between parenthesis (43, 54, 67, 75, 79, 84, 85)
• a raw block is broken (62)
• many raw blocks are using console for the type, but it does not trigger any syntax color. It should rather be sh (172, 175, 185..)
• the text in raw code block seems to be very close to the raw block borders. It may be worth adjusting inset
• a few spacing oddities around raw inline (286, 287)

[tleb]

We want bold that is bold not orange. :-) Maybe making it available under a function like #boolin()?

[tleb]

Footnotes overflow a bit in the footer.

[tleb]

Line height inbetween paragraphs is too small. I don't know where that is configured. Before/after:

[tleb]

No files have newlines at the end. This is uncommon in our world (why I'm not sure). This means my editor automatically adds one and that makes a diff. Notice how GH shows it with a stop-sign symbol.

[miquelraynal]

In the kernel training I observe that most pictures look bigger than before which makes the reading uncomfortable. Perhaps the font is also a bit larger than before, which overflows some lines.

[tleb]

In the kernel training I observe that most pictures look bigger than before which makes the reading uncomfortable. Perhaps the font is also a bit larger than before, which overflows some lines.

(I can't target a specific message to reply to as it's not a review comment.)

Can you point at examples? Only one I could find is p226 which is an issue with the slide's #table() definition. I've got a patch to apply on top to fix it. But I didn't see anything else.

[miquelraynal]

Can you point at examples? Only one I could find is p226 which is an issue with the slide's #table() definition. I've got a patch to apply on top to fix it. But I didn't see anything else.

Indeed, it is image dependent, I found one or two slightly larger but it is actually ok, please discard this comment, we will figure it out manually later, if we even need to eventually act.