migrate more stuff

6 files changed, 274 insertions, 72 deletions

diff --git a/content/posts/2018-08-01-dxvk-gentoo.es.md b/content/posts/2018-08-01-dxvk-gentoo.es.md
new file mode 100644
index 0000000..0a899a3
--- /dev/null
+++ b/content/posts/2018-08-01-dxvk-gentoo.es.md
@@ -0,0 +1,131 @@
+---
+layout: post
+title: Compilando las DLLs de DXVK en Gentoo
+tags:
+- wine
+- dxvk
+- gentoo
+
+TocOpen: true
+ShowToc: true
+---
+
+La forma mas sencilla de compilar DXVK en Gentoo es con una chroot de Debian, pero... Donde está la diversión en eso? La primera vez que lo intenté me topé con varios problemas y no encontré documentado el proceso en ningún sitio. Esta entrada es un intento de resolver ese problema.
+
+<hr>
+
+# Dependencias
+
+Según la documentación oficial necesitamos:
+
+ - wine 3.10 or newer
+ - Meson build system (at least version 0.43)
+ - MinGW64 compiler and headers (requires threading support)
+ - glslang front end and validator
+
+Todas menos MinGW las puedes instalar directamente:
+
+```
+emerge virtual/wine dev-util/meson dev-util/glslang
+```
+
+## MinGW64
+
+Se necesita MinGW con threads de POSIX. Por suerte existe `crossdev`, el
+problema es que por defecto compila GCC con threads de Win32.
+
+Se crea primero la toolchain, la tupla para x86 es `i686-w64-mingw32` y para
+x64 `x86_64-w64-mingw32`.
+
+```
+crossdev -t i686-w64-mingw32
+crossdev -t x86_64-w64-mingw32
+```
+
+Para arreglar GCC se necesitan dos cosas, indicar que lo queremos con POSIX
+threads y las librerías que hacen falta para compilarlo.
+
+1. Habilita los POSIX threads:
+
+    ```
+    mkdir /etc/portage/{env,package.env}
+    echo 'EXTRA_ECONF="--enable-threads=posix"' > /etc/portage/env/mingw32_posix_threads
+    echo -e 'cross-i686-w64-mingw32/gcc mingw32_posix_threads\ncross-x86_64-w64-mingw32/gcc mingw32_posix_threads' > /etc/portage/package.env/mingw32_posix_threads
+    ```
+
+1. Añade la `USE` `libraries`:
+
+    ```
+    cross-i686-w64-mingw32/mingw64-runtime libraries
+    cross-x86_64-w64-mingw32/mingw64-runtime libraries
+    ```
+
+Por último recompila `mingw64-runtime` y `gcc` por separado, en ese orden:
+
+```
+emerge -1 cross-i686-w64-mingw32/mingw64-runtime cross-x86_64-w64-mingw32/mingw64-runtime
+emerge -1 cross-i686-w64-mingw32/gcc cross-x86_64-w64-mingw32/gcc
+```
+
+Dependiendo de la versión del runtime, puede que se instalen algunas librerias
+en el lugar equivocado y esto impide compilar GCC, si es el caso basta con
+hacer enlaces (Bug #653246):
+
+```
+ln -s /usr/x86_64-w64-mingw32/usr/lib64/{libmangle.a,libpthread.a,libpthread.dll.a,libwinpthread.a,libwinpthread.dll.a,libwinpthread.la} /usr/x86_64-w64-mingw32/usr/lib/
+```
+
+El resultado final debe ser este:
+
+```
+i686-w64-mingw32-gcc -v
+x86_64-w64-mingw32-gcc -v
+...
+Thread model: posix
+...
+```
+
+# Compilar las DLLs
+
+```
+# su user
+$ cd
+$ git clone https://github.com/doitsujin/dxvk.git
+$ cd dxvk
+
+### 32-bit build. For 64-bit builds, replace
+### build-win32.txt with build-win64.txt
+### build.w32 with build.w64
+
+$ meson --cross-file build-win32.txt --prefix /some/install/prefix build.w32
+$ cd build.w32/
+$ meson configure -Dbuildtype=release
+$ ninja
+$ ninja install
+```
+```
+$ ls /some/install/prefix/bin
+d3d11.dll  dxgi.dll  setup_dxvk.sh
+```
+
+Estas son las toolchains que usé y que producen binarios que funcionan:
+
+```
+cross-i686-w64-mingw32/binutils-2.30-r3
+cross-i686-w64-mingw32/gcc-7.3.0-r3
+cross-i686-w64-mingw32/mingw64-runtime-5.0.4
+
+cross-x86_64-w64-mingw32/binutils-2.30-r3
+cross-x86_64-w64-mingw32/gcc-7.3.0-r3
+
+### Requiere symlinkear de ...lib64/ -> ...lib/
+cross-x86_64-w64-mingw32/mingw64-runtime-5.0.4
+```
+
+----
+
+**Fuentes**:
+
+- [DXVK Github](https://github.com/doitsujin/dxvk)
+- [Bug #631460](https://bugs.gentoo.org/631460)
+- [Bug #653246](https://bugs.gentoo.org/653246)
diff --git a/content/posts/2018-08-01-dxvk-gentoo.md b/content/posts/2018-08-01-dxvk-gentoo.md
index e71cac3..93b554b 100644
--- a/content/posts/2018-08-01-dxvk-gentoo.md
+++ b/content/posts/2018-08-01-dxvk-gentoo.md
@@ -1,14 +1,17 @@
 ---
 layout: post
-draft: true
 title: Building DXVK's DLLs on Gentoo
+tags:
+- wine
+- dxvk
+- gentoo
 
 TocOpen: true
 ShowToc: true
 ---
 
 By far the easiest way to do it is on a Debian chroot, but that ain't as fun as
-building your own toolchains and do it on Gentoo.
+building your own toolchain and do it on Gentoo.
 
 <hr>
 
@@ -21,81 +24,73 @@ According to the official documentation:
 - MinGW64 compiler and headers (requires threading support)
 - glslang front end and validator
 
-{% highlight code %}
+All but MinGW you can install directly from portage:
 
-# emerge virtual/wine dev-util/meson dev-util/glslang
-
-{% endhighlight %}
+```
+emerge virtual/wine dev-util/meson dev-util/glslang
+```
 
 ## MinGW64
 
-MinGW with POSIX threads is needed, problem is by default crossdev will compile
-GCC with Win32 threads.
-
-Start by creating your toolchains, tuple for x86 is `i686-w64-mingw32` and
-`x86_64-w64-mingw32` for x64.
-
-{% highlight code %}
-
-# crossdev -t i686-w64-mingw32
-
-# crossdev -t x86_64-w64-mingw32
+MinGW with POSIX threads is required, problem is, by default `crossdev` will
+compile GCC with Win32 threads instead of POSIX. Start by creating your
+toolchain with `crossdev`, tuple for x86 is `i686-w64-mingw32` and
+`x86_64-w64-mingw32` for x64:
 
-{% endhighlight %}
+```
+crossdev -t i686-w64-mingw32
+crossdev -t x86_64-w64-mingw32
+```
 
-Fix GCC by enabling POSIX threads and adding the `libraries` USE to
-`mingw64-runtime`.
+Fix GCC by enabling POSIX threads:
 
-{% highlight code %}
+```
+mkdir /etc/portage/{env,package.env}
+echo 'EXTRA_ECONF="--enable-threads=posix"' > /etc/portage/env/mingw32_posix_threads
+echo -e 'cross-i686-w64-mingw32/gcc mingw32_posix_threads\ncross-x86_64-w64-mingw32/gcc mingw32_posix_threads' > /etc/portage/package.env/mingw32_posix_threads
+```
 
-# mkdir /etc/portage/{env,package.env}
+Then add the `libraries` `USE` to `mingw64-runtime`:
 
-# echo 'EXTRA_ECONF="--enable-threads=posix"' > /etc/portage/env/mingw32_posix_threads
-
-# echo -e 'cross-i686-w64-mingw32/gcc mingw32_posix_threads\ncross-x86_64-w64-mingw32/gcc mingw32_posix_threads' > /etc/portage/package.env/mingw32_posix_threads
-
-{% endhighlight %}
-
-{% highlight code %} cross-i686-w64-mingw32/mingw64-runtime libraries
-cross-x86_64-w64-mingw32/mingw64-runtime libraries {% endhighlight %}
+```
+cross-i686-w64-mingw32/mingw64-runtime libraries
+cross-x86_64-w64-mingw32/mingw64-runtime libraries
+```
 
 Rebuild `mingw64-runtime` and `gcc`. Order matters, `mingw64-runtime` with
-`libraries` provides `pthreads.h` and other stuff that is needed to compile GCC
-with POSIX thread model.
-
-{% highlight code %}
-
-# emerge -1 cross-i686-w64-mingw32/mingw64-runtime cross-x86_64-w64-mingw32/mingw64-runtime
+`libraries` provides `pthreads.h` and other stuff that's required to compile
+GCC with the POSIX thread model.
 
-# emerge -1 cross-i686-w64-mingw32/gcc cross-x86_64-w64-mingw32/gcc
+```
+emerge -1 cross-i686-w64-mingw32/mingw64-runtime cross-x86_64-w64-mingw32/mingw64-runtime
+emerge -1 cross-i686-w64-mingw32/gcc cross-x86_64-w64-mingw32/gcc
+```
 
-{% endhighlight %}
+Depending on the runtime version, libraries may end up in the wrong place (see
+bug #653246), if that's the case sysmlink those and then rebuild GCC:
 
-_Depending on the runtime version, libraries may end up in the wrong place (see
-bug #653246), if that is the case sysmlink those and then rebuild GCC._ _eg_
-{% highlight code %}
-
-# ln -s /usr/x86_64-w64-mingw32/usr/lib64/{libmangle.a,libpthread.a,libpthread.dll.a,libwinpthread.a,libwinpthread.dll.a,libwinpthread.la} /usr/x86_64-w64-mingw32/usr/lib/
-
-{% endhighlight %}
+```sh
+ln -s /usr/x86_64-w64-mingw32/usr/lib64/{libmangle.a,libpthread.a,libpthread.dll.a,libwinpthread.a,libwinpthread.dll.a,libwinpthread.la} \
+    /usr/x86_64-w64-mingw32/usr/lib/
+```
 
 Final result should be:
 
-{% highlight code %}
+```
+i686-w64-mingw32-gcc -v
 
-# i686-w64-mingw32-gcc -v
+... Thread model: posix ...
 
-# x86_64-w64-mingw32-gcc -v
+x86_64-w64-mingw32-gcc -v
 
-... Thread model: posix ... {% endhighlight %}
+... Thread model: posix ...
+```
 
 # Crosscompiling DLLs
 
-{% highlight code %}
-
-# su user
-
-$ cd $ git clone https://github.com/doitsujin/dxvk.git $ cd dxvk
+```
+git clone https://github.com/doitsujin/dxvk.git
+cd dxvk
 
 ### 32-bit build. For 64-bit builds, replace
 
@@ -103,22 +98,28 @@ $ cd $ git clone https://github.com/doitsujin/dxvk.git $ cd dxvk
 
 ### build.w32 with build.w64
 
-$ meson --cross-file build-win32.txt --prefix /some/install/prefix build.w32 $
-cd build.w32/ $ meson configure -Dbuildtype=release $ ninja $ ninja install
-{% endhighlight %} {% highlight code %} $ ls /some/install/prefix/bin d3d11.dll
-dxgi.dll setup_dxvk.sh {% endhighlight %}
+meson --cross-file build-win32.txt --prefix /some/install/prefix build.w32
+cd build.w32/
+meson configure -Dbuildtype=release
+ninja
+ninja install
+```
 
-These are the toolchains I used.
+```
+ls /some/install/prefix/bin
+d3d11.dll dxgi.dll setup_dxvk.sh
+```
 
-{% highlight code %} cross-i686-w64-mingw32/binutils-2.30-r3
-cross-i686-w64-mingw32/gcc-7.3.0-r3 cross-i686-w64-mingw32/mingw64-runtime-5.0.4
+These are the toolchains I used.
 
-cross-x86_64-w64-mingw32/binutils-2.30-r3 cross-x86_64-w64-mingw32/gcc-7.3.0-r3
+```
+cross-i686-w64-mingw32/binutils-2.30-r3
+cross-i686-w64-mingw32/gcc-7.3.0-r3
+cross-i686-w64-mingw32/mingw64-runtime-5.0.4
+cross-x86_64-w64-mingw32/binutils-2.30-r3
+cross-x86_64-w64-mingw32/gcc-7.3.0-r3
 
 ### symlinks from ...lib64/ -> ...lib/ required! see bug #653246
 
-cross-x86_64-w64-mingw32/mingw64-runtime-5.0.4 {% endhighlight %}
-
----
-
-#### [Original in spanish](/gnu/linux/2018/08/01/dxvk-gentoo/)
+cross-x86_64-w64-mingw32/mingw64-runtime-5.0.4
+```
diff --git a/content/posts/2019-2-1-compiling-memory-requirements.md b/content/posts/2019-2-1-compiling-memory-requirements.md
new file mode 100644
index 0000000..567dcb2
--- /dev/null
+++ b/content/posts/2019-2-1-compiling-memory-requirements.md
@@ -0,0 +1,33 @@
+---
+layout: post
+title: there is NOT at least X GiB RAM
+category: GNU/Linux
+tags:
+  - gentoo
+---
+
+Recently, while compiling latest Rust version I came across a problem on my very
+old Macbook where `emerge` complained about not enough RAM to compile Rust.
+
+The `check-reqs_pkg_setup` from `check-reqs.eclass` takes care of this check:
+
+```bash
+...
+pre_build_checks() {
+    CHECKREQS_DISK_BUILD="7G"
+    CHECKREQS_MEMORY="4G"
+...
+    check-reqs_pkg_setup
+}
+```
+
+If you don't have enough memory, the quick and dirty solution is to add enough
+swap and run `emerge` again with `${I_KNOW_WHAT_I_AM_DOING}` set.
+
+```
+fallocate -l 8G /mnt/swap.swap
+mkswap /mnt/swap.swap
+swapon /mnt/swap.swap
+chmod 600 /mnt/swap.swap
+I_KNOW_WHAT_I_AM_DOING=1 emerge -1 rust
+```
diff --git a/content/posts/2019-2-24-walking-netstat-with-awk.md b/content/posts/2019-2-24-walking-netstat-with-awk.md
new file mode 100644
index 0000000..1094bce
--- /dev/null
+++ b/content/posts/2019-2-24-walking-netstat-with-awk.md
@@ -0,0 +1,18 @@
+---
+layout: post
+title: Walking /proc/net/netstat like a pro with awk
+category: GNU/Linux
+tags:
+  - networking
+---
+
+Little snippet to parse `/proc/net/netstat` and format the output:
+
+```bash
+awk '{for(i=1;i<=NF;i++)title[i] = $i; getline; print title[1]; for(i=2;i<=NF;i++)printf " %s: %s\n", title[i], $i }' /proc/net/netstat
+
+TcpExt:
+ ...
+IpExt:
+ ...
+```
diff --git a/content/posts/2019-3-11-cpanm-module-error.md b/content/posts/2019-3-11-cpanm-module-error.md
new file mode 100644
index 0000000..698ba71
--- /dev/null
+++ b/content/posts/2019-3-11-cpanm-module-error.md
@@ -0,0 +1,19 @@
+---
+layout: post
+title: cpanm error "No such file or directory opening compressed index"
+category: Perl
+tags:
+  - cpan
+---
+
+If you ever get this error while installing a module `cpanm`:
+
+```
+! Finding install on cpanmetadb failed.
+! cannot open file '/root/.cpanm/sources/http%www.cpan.org/02packages.details.txt.gz': No such file or directory opening compressed index
+! Couldn't find module or a distribution install
+```
+
+The problem is caused by not having the `LWP::Protocol::https` module
+installed, and the solution is to run `cpanm` with the `--no-lwp` option or
+installing `LWP::Protocol::https`.
diff --git a/content/posts/2021-02-03-gentoo-no-desktop-lag.md b/content/posts/2021-02-03-gentoo-no-desktop-lag.md
index 812b7d4..d5c9d20 100644
--- a/content/posts/2021-02-03-gentoo-no-desktop-lag.md
+++ b/content/posts/2021-02-03-gentoo-no-desktop-lag.md
@@ -23,10 +23,10 @@ tags:
    systemctl enable --now portage.slice
    ```
 
-   CPUShares option defaults to 1024, `systemd` will create a user slice for
+   `CPUShares` option defaults to 1024, `systemd` will create a user slice for
    each user with an active session, and all processes that user run will be
-   assigned to that slice, anything that a user may run will receive 4 times the
-   CPU time of processes assigned to the portage slice.
+   assigned to that slice, anything that a user may run will receive 4 times
+   the CPU time of processes assigned to the portage slice.
 
    ```sh
    ➜  ~ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/cpu.shares
@@ -48,5 +48,5 @@ tags:
 
    The `cgroup.procs` file is present in every cgroup and contains a list of
    processes that are members of that particular cgroup. Writing a PID to this
-   file will move all threads in that process at once to the cgroup. And that,
-   is awesome :D
+   file will move all threads in that process at once to the cgroup, and that,
+   is awesome.