content/posts/debuginfod-for-debian.md

@@ -96,7 +96,7 @@ consumed by GDB nor `debuginfod` (for a good example of a distribution
 that does that, see Fedora's `debugsource` packages).  Let me show you
 an example of debugging GDB itself (using `debuginfod`) on Debian:
 
-```console
+```
 $ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
 Reading symbols from gdb...
 Downloading separate debug info for /tmp/gdb...
@@ -176,7 +176,7 @@ package.  Notice that the last directory's name in both paths is the
 same, so in this case we can use GDB's `set substitute-path` command
 do the job for us (in this example `$PWD` is `/tmp/`):
 
-```console
+```
 $ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
 Reading symbols from gdb...
 Reading symbols from /tmp/.cache/debuginfod_client/02046bac4352940d19d9164bab73b2f5cefc8c73/debuginfo...
@@ -224,7 +224,7 @@ whether she wants to use our service by default.
 If you would like to start using the service right now, all you have
 to do is set the following environment variable in your shell:
 
-```bash
+```
 DEBUGINFOD_URLS="https://debuginfod.debian.net"
 ```
 

content/posts/fedora-on-acer-c720p.md

@@ -122,9 +122,8 @@ We're almost there! The last step before you boot your Fedora LiveUSB is
 to actually enable SeaBIOS. Just go inside your superuser shell (from
 the previous step) and type:
 
-```console
+    #!bash
     > crossystem dev_boot_usb=1 dev_boot_legacy=1
-```
 
 And that's it!
 
@@ -150,9 +149,8 @@ You can solve that by passing the `mem` parameter to Linux. So, when
 GRUB complains that it was unable to load the specified image, it will
 give you a command prompt (`boot:`), and you just need to type:
 
-```console
+   #!bash
    boot: linux mem=1980M
-```
 
 And that's it, things should work.
 
@@ -222,18 +220,16 @@ bug](https://bugzilla.redhat.com/show_bug.cgi?id=1045821#c63)), I found
 out about a few Linux flags that I could provide in boot time. To save
 you time, this is what I have now in my `/etc/default/grub` file:
 
-```console
+    #!bash
     GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
-```
 
 The final `...` means that you should keep whatever was there before you
 included those parameters, of course. Also, after you edit this file,
 you need to regenerate the GRUB configuration file on `/boot`. Run the
 following command as `root`:
 
-```console
+    #!bash
     > grub2-mkconfig -o /boot/grub2/grub.cfg
-```
 
 Then, after I rebooted the system, I found that only adding those flags
 was still not enough. I saw a bunch of errors on `dmesg`, which showed
@@ -251,17 +247,16 @@ because the system is using the touchpad and the touchscreen to
 determine whether it should resume from suspend or not. So basically
 what you have to do is to disable those sources of events:
 
-```console
+    #!bash
     echo TPAD > /proc/acpi/wakeup
     echo TSCR > /proc/acpi/wakeup
-```
 
 And voilà! Now everything should work as expected :-). You might want to
 issue those commands every time you boot the system, in order to get
 suspend to work every time, of course. To do that, you can create a
 `/etc/rc.d/rc.local`, which gets executed when the system starts:
 
-```console
+    #!bash
     > cat /etc/rc.d/rc.local
     #!/bin/bash
 
@@ -274,13 +269,11 @@ suspend_tricks()
     suspend_tricks
 
     exit 0
-```
 
 Don't forget to make this file executable:
 
-```console
+    #!bash
     > chmod +x /etc/rc.d/rc.local
-```
 
 Conclusion
 ----------

content/posts/gdb-and-systemtap-probes-part-1.md

@@ -30,7 +30,7 @@ systems, you can obtain this header file by installing the package
 
 Here's a simple example of an application with a one-argument probe:
 
-```c
+    #!c
     #include <sys/sdt.h>
 
     int
@@ -42,14 +42,12 @@ main (int argc, char *argv[])
 
       return 0;
     }
-```
 
 As you can see, this is a very simple program with one probe, which
 contains one argument. You can now compile the program:
 
-```console
+    #!bash
     $ gcc test_program.c -o test_program
-```
 
 Now you must be thinking: "*Wait, wait... Didn't you just forget to link
 this program against some SystemTap-specific library or something?*" And
@@ -61,7 +59,7 @@ As Tom said in [his blog post](http://tromey.com/blog/?p=687), this is
 If you want to make sure your probe was inserted in the binary, you can
 use `readelf` command:
 
-```console
+    #!bash
     $ readelf -x .note.stapsdt ./test_program
 
     Hex dump of section '.note.stapsdt':
@@ -70,7 +68,6 @@ Hex dump of section '.note.stapsdt':
       0x00000020 00000000 00000000 00000000 74657374 ............test
       0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
       0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...
-```
 
 *(I will think about writing an explanation on how the probes are laid
 out on the binary, but for now you just have to care if you actually
@@ -78,10 +75,9 @@ see an output from this* `readelf` *command.)*
 
 You can also use SystemTap to perform this verification:
 
-```console
+    #!bash
     $ stap -L 'process("./test_program").mark("*")'
     process("./test_program").mark("my_probe") $arg1:long
-```
 
 So far, so good. If you see an output like the one above, it means your
 probe is correctly inserted. You could obviously use SystemTap to

content/posts/gdb-and-systemtap-probes-part-2.md

@@ -33,10 +33,9 @@ It is not the goal of this post to explain it in detail, but you might
 want to give it a try by compiling your binary with debuginfo support
 (use the `-g` flag on `GCC`), and do something like:
 
-```console
+    #!bash
 	$ stap -e 'probe process("/bin/foo").function("name") { log($$parms) }' -c /bin/foo
 	$ stap -e 'probe process("/bin/foo").statement("*@file.c:443") { log($$vars) }' -c /bin/foo
-```
 
 And that's it. You can read SystemTap's documentation, or
 [this](http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps)
@@ -49,7 +48,7 @@ Well, now let's get to the interesting part. It is time to make `GDB`
 work with the `SDT` probe that we have put in our example code. Let's
 remember it:
 
-```c
+    #!c
 	#include <sys/sdt.h>
 
 	int
@@ -61,7 +60,6 @@ main (int argc, char *argv[])
 
 	  return 0;
 	}
-```
 
 It is a very simple example, and we will have to extend it later in
 order to show more features. But for now, it will do.
@@ -70,7 +68,7 @@ The first thing to do is to open `GDB` (with SystemTap support, of
 course!), and check to see if it can actually see probe inserted in our
 example.
 
-```console
+	#!bash
 	$ gdb ./test_program
 	GNU gdb (GDB) 7.5.50.20121014-cvs
 	Copyright (C) 2012 Free Software Foundation, Inc.
@@ -79,7 +77,6 @@ License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
 	(gdb) info probes
 	Provider     Name     Where              Semaphore Object
 	test_program my_probe 0x00000000004004ae           /home/sergio/work/src/git/build/gdb/test_program
-```
 
 Wow, it actually works! :-)
 
@@ -94,10 +91,9 @@ use the `SDT` support.
 Anyway, now it is time to start using this support. The first thing I
 want to show you is how to put a breakpoint in a probe.
 
-```console
+	#!bash
 	(gdb) break -probe-stap my_probe
 	Breakpoint 1 at 0x4004ae
-```
 
 That's all! We have chosen to extend the `break` command in order to
 support the new `-probe-stap` parameter. If you're wondering *... why
@@ -116,13 +112,12 @@ the one reported by `break`: they should be the same.
 Ok, so now, with our `breakpoint` in place, let's run the program and
 see what happens.
 
-```console
+	#!bash
 	(gdb) run
 	Starting program: /home/sergio/work/src/git/build/gdb/test_program
 
 	Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8
 	8  STAP_PROBE1 (test_program, my_probe, a);
-```
 
 As you can see, `GDB` stopped at the exact location of the probe.
 Therefore, you are now able to put marks (i.e., probes) in your source
@@ -140,12 +135,11 @@ inspect the probe's arguments? Yes, let's do it now!
 Just remember that, in `SDT`'s parlance, the current probe's argument is
 `a`. So let's print its value.
 
-```console
+	#!bash
 	(gdb) p $_probe_arg0
 	$1 = 10
 	(gdb) p a
 	$2 = 10
-```
 
 *"Hey, captain, it seems the boat really floats!"*
 

content/posts/gdb-and-systemtap-probes-part-3.md

@@ -59,7 +59,7 @@ Ok, so now we have to learn how to put `tracepoints` in our code, and
 how to define actions for them. But before that, let's remember our
 example program:
 
-```c
+	#!c
 	#include <sys/sdt.h>
 
 	int
@@ -71,7 +71,7 @@ main (int argc, char *argv[])
 
      	return 0;
 	}
-```
+
 
 Very simple, isn't it? Ok, to the `tracepoints` now, my friends.
 
@@ -94,11 +94,10 @@ First of all, make sure you have `gdbserver` installed. If you use
 Fedora, the package name you will have to install is `gdb-gdbserver`. If
 you have it installed, you can do:
 
-```console
+	#!bash
 	$ gdbserver :3001 ./test_program
 	Process ./test_program created; pid = 17793
 	Listening on port 3001
-```
 
 The second argument passed to `gdbserver` instructs it to listen on the
 port 3001 of your loopback interface, a.k.a. `localhost`.
@@ -110,7 +109,7 @@ for new connections to arrive. Don't worry, we will connect to it soon!
 
 Now, go to another terminal and start `GDB` with our program:
 
-```console
+	#!bash
 	$ gdb ./test_program
 	...
 	(gdb) target remote :3001
@@ -118,7 +117,6 @@ Remote debugging using :3001
 	Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
 	Loaded symbols for /lib64/ld-linux-x86-64.so.2
 	0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2
-```
 
 The command you have to use inside `GDB` is `target remote`. It takes as
 an argument the host and the port to which you want to connect. In our
@@ -137,10 +135,9 @@ Ok, so now it is time to start our *trace experiment*!
 
 In your `GDB` prompt, put a `tracepoint` in the probe named `my_probe`:
 
-```console
+	#!bash
 	(gdb) trace -probe-stap my_probe
 	Tracepoint 1 at 0x4005a9
-```
 
 As you can see, the `trace` command takes exactly the same arguments as
 the `break` command. Thus, you need to use the `-probe-stap` modified in
@@ -155,14 +152,13 @@ For this example, we will use only the `collect` keyword, which tells
 `GDB` to... hm... collect something :-). In our case, it will collect
 the probe's first argument, or `$_probe_arg0`, as you may remember.
 
-```console
+	#!bash
 	(gdb) actions 
 	Enter actions for tracepoint 1, one per line.
 	End with a line saying just "end".
 	>collect $_probe_arg0
 	>end
 	(gdb)
-```
 
 Simple as that. Finally, we have to define a `breakpoint` in the last
 instruction of our program, because it is necessary to keep it running
@@ -178,7 +174,7 @@ Ok, time to run our trace experiment. First, we must issue a `tstart` to
 tell `GDB` to start monitoring the `tracepoints`. And then, we can
 continue our program normally.
 
-```console
+	#!bash
 	(gdb) tstart 
 	(gdb) continue
 	Continuing.
@@ -187,7 +183,6 @@ Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
 	10        return 0;
 	(gdb) tstop
 	(gdb)
-```
 
 Remember, `GDB` is **not** going to stop your program, because
 `tracepoints` are designed to not interfere with the execution of it.
@@ -198,13 +193,12 @@ Now, we will be able to examine what the `tracepoint` has collected.
 First, we will the `tfind` command to make sure the `tracepoint` has
 hit, and then we can inspect what we ordered it to collect:
 
-```console
+	#!bash
 	(gdb) tfind start
 	Found trace frame 0, tracepoint 1
 	8         STAP_PROBE1 (test_program, my_probe, a);
 	(gdb) p $_probe_arg0
 	$1 = 10
-```
 
 And it works! Notice that we are printing the probe argument using the
 same notation as with `breakpoints`, even though we are not exactly

content/posts/gnupg-encrypt-to-self.md

@@ -47,9 +47,8 @@ to always encrypt the message to myself too.
 You basically have to edit your `$HOME/.gnupg/gpg.conf` file and put
 this setting there:
 
-```console
+    #!bash
     hidden-encrypt-to ID
-```
 
 That's it. Now, whenever I send an encrypted message, GnuPG encrypts it
 for me as well, so I just need to go to my “Sent/” folder, and decrypt

content/posts/improve-gcore-elf-headers.md

@@ -66,13 +66,11 @@ the binutils guys to fix it, which meant less work for us :-).
 With a lot of help from Keith Seitz, I was able to bisect the problem
 and found that it started with the following commit:
 
-```
 	commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
 	Author: H.J. Lu <hjl.tools@gmail.com>
 	Date:   Tue Feb 27 11:34:20 2018 -0800
 
 		ld: Add --enable-separate-code
-```
 
 This is a commit that touches the linker, which is part of binutils.
 So that means this is not GDB's problem, right?!?  Hmm.  No,
@@ -97,7 +95,6 @@ everything (code and data) was put together in the same memory
 region.  What this means in practice is that, before, you would see
 something like this when you examined `/proc/PID/smaps`:
 
-```
 	00400000-00401000 r-xp 00000000 fc:01 798593                             /file
 	Size:                  4 kB
 	KernelPageSize:        4 kB
@@ -120,11 +117,9 @@ SwapPss:               0 kB
 	Locked:                0 kB
 	THPeligible:    0
 	VmFlags: rd ex mr mw me dw sd
-```
 
 And now, you will see two memory regions instead, like this:
 
-```
 	00400000-00401000 r--p 00000000 fc:01 799548                             /file
 	Size:                  4 kB
 	KernelPageSize:        4 kB
@@ -169,7 +164,6 @@ SwapPss:               0 kB
 	Locked:                0 kB
 	THPeligible:    0
 	VmFlags: rd ex mr mw me dw sd
-```
 
 A few minor things have changed, but the most important of them is the
 fact that, before, the whole memory region **had** anonymous data in
@@ -246,8 +240,9 @@ Linux also makes these checks, by the way.
 The patch, finally
 ------------------
 
-I submitted [the
+I
-patch](https://sourceware.org/ml/gdb-patches/2019-04/msg00479.html) to
+submitted
+[the patch](https://sourceware.org/ml/gdb-patches/2019-04/msg00479.html) to
 the mailing list, and it was approved fairly quickly (with a few minor
 nits).
 
@@ -258,7 +253,8 @@ interesting to come up with a solution that extended the work I did a
 few years ago.  I was also able to close a few bug reports upstream,
 as well as the one reported against Fedora GDB.
 
-The patch has been
+The patch has
+been
 [pushed](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=57e5e645010430b3d73f8c6a757d09f48dc8f8d5),
 and is also present at the latest version of Fedora GDB for Rawhide.
 It wasn't possible to write a self-contained testcase for this

content/posts/installing-gerrit-and-keycloak.md

@@ -180,12 +180,10 @@ Java 8, but unlike Keycloak, it doesn't work out of the box with
 OpenJDK 11.  I had to make a small but important addition in the file
 `etc/gerrit.config`:
 
-```ini
 	[container]
         ...
         javaOptions = "--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
         ...
-```
 
 After that, I was able to start gerrit.  And then I started trying to
 set it up for OAuth2 authentication using Keycloak.  This took a
@@ -200,7 +198,6 @@ causing a very strange error on Gerrit (as you can see, a
 `java.lang.StringIndexOutOfBoundsException`!), which didn't make
 sense.  In the end, my Apache config file looks like this:
 
-```apacheconf
 	<VirtualHost *:80>
 		ServerName gnutoolchain-gerrit.osci.io
 
@@ -247,7 +244,6 @@ sense.  In the end, my Apache config file looks like this:
 			ProxyPass /r/ http://127.0.0.1:8081/ nocanon
 			#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
 	</VirtualHost>
-```
 
 I confess I was almost giving up Keycloak when I finally found
 the problem...
@@ -263,12 +259,10 @@ gerrit that the user was already logged in, and gerrit would
 automatically log the user in again!  I was able to solve this by
 redirecting the user to Keycloak's logout page, like this:
 
-```ini
     [auth]
         ...
         logoutUrl = https://keycloak-url:port/auth/realms/REALM/protocol/openid-connect/logout?redirect_uri=https://gerrit-url/
         ...
-```
 
 After that, it was already possible to start worrying about configure
 gerrit itself.  I don't know if I'll write a post about that, but let

content/posts/migration-jabberd2-to-prosody.md

@@ -156,11 +156,10 @@ here](http://sergiodj.net/~sergio/jabberd2-migration/j2to1.txt). Save
 the file as `j2to1.pl`, and run the script (don't forget to edit the
 source code in order to provide the database name/file):
 
-```console
+	#!bash
     $> perl j2to1.pl jabberd14-dir/
     Converting user@host...
     $>
-```
 
 This will convert the database from Jabberd2 to Jabberd14, and put the
 XML file of each Jabber user in the server into `jabberd14-dir/host/`.
@@ -172,9 +171,8 @@ page](https://github.com/Kev/sleekmigrate) on how to set it up, you can
 run it on your Jabberd14 data directory in order to finally generate a
 XEP-0227 XML file that will be imported into Prosody.
 
-```console
+	#!bash
     $> ./sleekmigrate.py -j /path/to/jabberd14-dir/
-```
 
 This should create a file called `227.xml` on your current directory,
 which is the exported version of the Jabberd14 data directory. As a side
@@ -196,17 +194,15 @@ working. I also had to build some POSIX module of Prosody in order to
 make everything work. To do that, unpack the `tar.gz` file, go to the
 Prosody source code directory, and do:
 
-```console
+	#!bash
 	$> apt-get build-dep prosody && ./configure --ostype=debian && make
-```
 
 Only after I did that I could finally run the conversion script
 successfully. The script is locate inside the `tools/` directory. To run
 it:
 
-```console
+	#!bash
 	$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
-```
 
 And yay! I **finally** had everything imported into Prosody!!!! Then it
 was just a matter of finishing the server configuration, initializing

content/posts/using-wireguard-host-services-home.md

@@ -42,7 +42,7 @@ little configuration.
 On the server side (i.e., VPS or dedicated server), you will create
 the first endpoint.  Something like the following should do:
 
-```ini
+```nil
 [Interface]
 PrivateKey = PRIVATE_KEY_HERE
 Address = 10.0.0.1/32
@@ -73,7 +73,7 @@ A few interesting points to note:
 
 At your home, you will configure the peer:
 
-```ini
+```nil
 [Interface]
 PrivateKey = PRIVATE_KEY_HERE
 Address = 10.0.0.2/32