diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b10a25f4a9f57b46bb19f64f262b81543813e6fb..504a95f966faae123a8282ec181c83646f704b4b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,4 +1,4 @@
-# Contributing 
+# Contributing
 
 Whether you've got a bugfix, documentation update, or new feature for us, these are the steps to follow to contribute code back into the main trisquel repo.
 
@@ -6,34 +6,27 @@ Whether you've got a bugfix, documentation update, or new feature for us, these
 
 
 
- 1. Install needed packages for both, sources and binary builds
+ 1. Install needed packages for running the helpers
 ```
-sudo apt-get install  dpkg-dev devscripts git pbuilder quilt patch sed rpl parsewiki
+sudo apt-get install cdbs devscripts dpkg-dev git gnupg patch quilt rpl sed
 ```
 
- 1. Configure build environment for binary packages
+ 1. Get the Trisquel build environment and follow the [README](https://gitlab.trisquel.org/trisquel/trisquel-builder/-/blob/master/README.md) to setup your system for building
 ```
-git clone https://devel.trisquel.info/trisquel/trisquel-builder.git
-ln -s $(readlink -f trisquel-builder/pbuilderrc) ~/.pbuilderrc
-sudo ln -s $(readlink -f trisquel-builder/hooks) /var/cache/pbuilder/hooks.d
-```
-
- 1. Create the build environment for each distribution/architecture you want to work with
-```
-sudo BUILDDIST=belenos BUILDARCH=amd64 pbuilder create 
+git clone https://gitlab.trisquel.org/trisquel/trisquel-builder.git
 ```
 
 
 ## 2. Get the latest code from gitlab
 
-You'll need to understand a little bit about how git and gitlab work before this step (GitHub works the same way, but we like free software). In simple terms, log in [here](https://devel.trisquel.info/users/sign_in?redirect_to_referer=yes), visit the [trisquel/package-helpers project page](https://devel.trisquel.info/trisquel/package-helpers), and click the "fork" button to create your own copy of the repo.  You will push your changes to this new repo under your own git account, and we will pull changes into the main repo from there.
+You'll need to understand a little bit about how git and gitlab work before this step (GitHub works the same way, but we like free software). In simple terms, log in [here](https://gitlab.trisquel.org/users/sign_in?redirect_to_referer=yes), visit the [trisquel/package-helpers project page](https://gitlab.trisquel.org/trisquel/package-helpers), and click the "fork" button to create your own copy of the repo.  You will push your changes to this new repo under your own git account, and we will pull changes into the main repo from there.
 
 For the sake of the rest of the examples in this guide, we're going to assume your gitlab username is "**richardtorvalds**" and you will be working with the  "**hello**" package, and use those in our examples.
 
 Now, we want to grab the latest from this newly created repository and pull it down to your local machine. Getting the latest code from your repo is simple, just clone it:
 
 ```bash
-git clone https://devel.trisquel.info/richardtorvalds/package-helpers.git
+git clone https://gitlab.trisquel.org/richardtorvalds/package-helpers.git
 cd package-helpers
 ```
 
@@ -44,7 +37,7 @@ This will give you a directory called "package-helpers" on your local machine wi
 One thing you'll need to do to make things easier to integrate and keep up to date in your fork is to add the main repo as a remote reference. This way you can fetch the latest code from the production version and integrate it. So, here's how to set that up:
 
 ```bash
-git remote add upstream https://devel.trisquel.info/trisquel/package-helpers.git
+git remote add upstream https://gitlab.trisquel.org/trisquel/package-helpers.git
 git remote   (this will list out your remotes, showing the new one we added)
 ```
 
@@ -52,14 +45,14 @@ Then, when you need to pull the latest from the main trisquel repo, you just fet
 
 ```bash
 git fetch upstream
-git merge upstream/belenos
+git merge upstream/nabia
 ```
 
-You can also use *git pull upstream belenos* if you want it all in one step.
+You can also use *git pull upstream nabia* if you want it all in one step.
 
 ## 4. Making a branch for your changes
 
-When adding features or bug fixes, please create a separate branch for each changeset you want us to pull in, either with the issue number in the branch name or with an indication of what the feature is (feature, bugfix...). 
+When adding features or bug fixes, please create a separate branch for each changeset you want us to pull in, either with the issue number in the branch name or with an indication of what the feature is (feature, bugfix...).
 
 ```bash
 git branch   (lists your current branches)
@@ -75,7 +68,7 @@ cd helpers
 cp make-apache2 make-hello
 ```
 
-For importing free packages from ppa's or other sources, check [make-toxcore](https://devel.trisquel.info/trisquel/package-helpers/blob/belenos/helpers/make-toxcore) and update the _EXTERNAL_ , _SIGNKEY_ and _changelog_ lines  with your own values.
+For importing free packages from ppa's or other sources, check [make-tor](https://gitlab.trisquel.org/trisquel/package-helpers/blob/nabia/helpers/make-tor) and update the _EXTERNAL_ , _SIGNKEY_ and _changelog_ lines  with your own values.
 
 Then, run the helper with
 ```
@@ -86,12 +79,12 @@ If everything goes fine, you will have your new source package ready at _PACKAGE
 
 ## 6. Build and test the binary package
 
-The last step generated a source package file, so we need to build the binary one:
+The last step generated a source package file, so we need to build the binary one. Please make sure that you set or replace `CODENAME` and `ARCH` variables:
 ```
-sudo BUILDDIST=belenos BUILDARCH=amd64 pbuilder build PACKAGES/hello/*.dsc
+sbuild -v -A --dist $CODENAME --arch $ARCH PACKAGES/hello/*.dsc
 ```
 
-The binary packages will be avaliable at _/var/cache/pbuilder/jenkins-repos/$BUILDDIST/_
+The binary packages will be avaliable in the directory from which you ran the previous command.
 
 
 ## 7. Push your code and make a pull request
@@ -107,6 +100,4 @@ This pushes everything in that branch up. Then you can go back to your forked pa
 That lets us know that there's something new from you that needs to be pulled in. We'll review it and get back to you about it if we have any questions. Otherwise, we'll integrate it and let you know when it's in!
 
 
-Hope this guide helps you get started in contributing to the trisquel project! If you still have questions, don't hesitate to join us on IRC - we're in #trisquel-dev on freenode -, or send a mail to the development mailing list trisquel-devel at listas.trisquel.info.
-
-   
+Hope this guide helps you get started in contributing to the trisquel project! If you still have questions, don't hesitate to join us on IRC - we're in #trisquel-dev on libera.chat -, or send a mail to the development mailing list trisquel-devel at listas.trisquel.info.
diff --git a/README.md b/README.md
index a1f237c53505812bfd98d096b38467692b3fd282..72fb8b3fa7097ad8d70ca0eef91732057beca53d 100644
--- a/README.md
+++ b/README.md
@@ -11,9 +11,9 @@ derivative of your own, we suggest you to use Builder instead of this helpers.
 
 Once a new package is added, it takes priority over the original one from Ubuntu,
 so they never enter into the repo from upstream and need to be
-compiled with this helpers and pushed into reprepro. 
+compiled with this helpers and pushed into reprepro.
 
-To add a package to the list, follow the [CONTRIBUTING](https://devel.trisquel.info/trisquel/package-helpers/blob/belenos/CONTRIBUTING.md) guidelines.
+To add a package to the list, follow the [CONTRIBUTING](https://gitlab.trisquel.org/trisquel/package-helpers/blob/nabia/CONTRIBUTING.md) guidelines.
 
 ## Steps
 
@@ -26,11 +26,20 @@ Those are the steps done by the helpers:
 5. Apply the changes described in the helper
 6. Re-package it, adding "triquel$VERSION" version string
 
+## Variables in helper scripts
+
+* `VERSION` (required): The trisquel version for the helper.
+* `EXTERNAL`: When building packages not coming from the upstream Ubuntu, the external `deb-src` in the same format as in `apt.sources.list`.
+* `REPOKEY`: An additional GPG key to import for the helper. Mostly only used in conjunction with `EXTERNAL`.
+* `BACKPORT(S)`: Must be set to `true` if the package is a backport.
+* `PARALLEL`: If `false`, avoids `dpkg-src` to run multi-threaded with as many CPUs as available.
+* `QUILT`: If `skip`, avoids patches to be automatically applied. Only set this variables if you know what you are doing.
+
 ## Recommendations
 
 * You don't need to use sudo in order to run those scripts, but some extra packages are needed:
 
-     `sudo apt-get install dpkg-dev sed git rpl devscripts quilt patch cdbs`
+     `sudo apt-get install cdbs devscripts dpkg-dev git gnupg patch quilt rpl sed`
 
 * Take care to use the right sourcePackageName, many source packages produce
 several binary packages. `apt-cache showsrc binary-package` can help you.
@@ -41,7 +50,7 @@ it at the `DATA/sourcePackageName` directory
 would actually be shown to the user. Avoid replacing copyright statements!
 * Try to write your replacements in a way they might work in future versions
 of the upstream package. Well written regexps and sed will help with that.
-* You can test your changes by doing them inside the _PACKAGES/sourcePackageName/source/_ directory, 
+* You can test your changes by doing them inside the _PACKAGES/sourcePackageName/source/_ directory,
 and running `dpkg-source -b .`, before being added to the helper script
 * You can check the status of failed build at https://jenkins.trisquel.org/job/build-watchdog/lastBuild/consoleText
 
@@ -63,4 +72,3 @@ To generate the images, we run the following scripts:
 
 Then we push the results into the Trisquel repository and run the script
 `make-debian-installer` to build the final images.
-