internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: zestedesavoir/zds-site

Issue:
Faute de frappe licence "CB-BY" => "CC-BY"
**Description du bug**

Lors du choix de la licence d'un contenu, parmi les licences Creative Commons, la comboBox nous propose la licence "CB-BY" au lieu de "CC-BY"

**Comment reproduire ?**

La liste des étapes qui permet de reproduire le bug :

1. Se connecter avec un utilisateur
2. Accéder au menu "Mes tutoriels" sur le profil
3. Ajouter un "Nouveau tutoriel"
4. Compléter les champs pour avoir un contenu valide et créer le tutoriel
5. Accéder à la page du tutoriel
6. Cliquer sur "Choisissez la licence de votre publication !"
7. Dérouler la liste
8. Choisir "CB-BY" et Valider
9. Le contenu est licencié sous "CB-BY"

**Comportement attendu**

Le nom de la licence est CC-BY

**Capture d'écran**

![licence_cb-by](https://user-images.githubusercontent.com/10254817/86519151-57e08780-be38-11ea-831c-738e4e53d6bc.png)

**Informations techniques**

Présent sur la branche "dev", absent de l'instance en production



Discussion:
A priori un problème dans les _fixtures_ de développement. Probablement assez simple à corriger, et peu critique pour le moment vu que la prod n'est pas impactée (les licences étant stockées dans une table de la base de données).

Par contre ce sera plus gênant quand on implémentera le sélecteur de licence “guidé”, qui s'appuiera probablement sur ces noms de licences.

D'ailleurs, les licences `CC BY-IO` et `CC BY-ND-SA` n'existent pas non plus (la première car il n'y a pas de clause “IO”, la seconde car elle n'aurait même pas de sens). Et il en manque. Bref, il serait bien de remplacer les _fixtures_ des licences par de vraies données.

Resolving patch:
diff --git a/zds/utils/management/commands/load_fixtures.py b/zds/utils/management/commands/load_fixtures.py
--- a/zds/utils/management/commands/load_fixtures.py
+++ b/zds/utils/management/commands/load_fixtures.py
@@ -288,16 +288,16 @@ def __generate_topic_and_post(cli, fake, nb_avg_posts_in_topic, nb_topics, nb_us
 
 def load_categories_content(cli, size, fake, *_, **__):
     """
-    Load categories and subcategories for tutorial and article
+    Load categories, subcategories and licenses for tutorials and articles
     """
 
-    lics = ['CB-BY', 'CC-BY-ND', 'CC-BY-ND-SA', 'CC-BY-SA', 'CC', 'CC-BY-IO', 'Tout-Droits']
+    # Load a few licenses, while avoiding creating duplicates of what may have been loaded before
+    lics = ['Tous droits réservés', 'CC BY']
     for lic in lics:
-        ex = Licence.objects.filter(code=lic).all()
-        if len(ex) == 0:
+        if Licence.objects.filter(code=lic).count() == 0:
             licence = Licence(code=lic, title=lic, description='')
             licence.save()
-            cli.stdout.write('Note: ajout de la licence {}'.format(lic))
+            cli.stdout.write('Note : ajout de la licence `{}`'.format(lic))
     categories = []
     sub_categories = []
     nb_categories = size * 5


Test patch:
Repository: zestedesavoir/zds-site

Issue:
La liste des contenus d'un auteur renvoie une erreur 404
Depuis le profil d'un auteur, lorsque l'on clique sur le bouton "Voir tout" à côté de "Dernières publications" (qui, dans mon cas, envoie vers l'URL https://zestedesavoir.com/contenus/voir/rezemika/?filter=public), on obtient une erreur 404. En revanche l'URL https://zestedesavoir.com/articles/voir/rezemika/?filter=public ou https://zestedesavoir.com/tutoriels/voir/rezemika/?filter=public fonctionne correctement.


Discussion:

Resolving patch:
diff --git a/zds/tutorialv2/views/contents.py b/zds/tutorialv2/views/contents.py
--- a/zds/tutorialv2/views/contents.py
+++ b/zds/tutorialv2/views/contents.py
@@ -2198,11 +2198,12 @@ def dispatch(self, request, *args, **kwargs):
 
     def get_queryset(self):
         profile = self.user.profile
-        if self.type not in list(TYPE_CHOICES_DICT.keys()):
-            raise Http404('Ce type de contenu est inconnu dans le système.')
-        _type = self.type
         if self.type == 'ALL':
             _type = None
+        elif self.type in list(TYPE_CHOICES_DICT.keys()):
+            _type = self.type
+        else:
+            raise Http404('Ce type de contenu est inconnu dans le système.')
 
         # Filter.
         if 'filter' in self.request.GET:


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Espaces insécables dans le titre de mise en Une
**Description du bug**

Espace non insécable dans l'aperçu de mis en Une. Ce problème n'a pas pu être par #5292 car l'aperçu est généré par du JavaScript.

**Comment reproduire ?**

La liste des étapes qui permet de reproduire le bug :

1. Se connecter en tant qu'administrateur ;
2. Accéder à la page d'un contenu ;
3. Mettre ce contenu en Une ;
4. Mettre le titre suivant : « `Comment alerter les secours ?` ».

**Comportement attendu**

L'espace doit automatiquement être remplacé par un espace insécable, avant ou après les signes concernés.


Discussion:

Resolving patch:
diff --git a/zds/utils/templatetags/french_typography.py b/zds/utils/templatetags/french_typography.py
--- a/zds/utils/templatetags/french_typography.py
+++ b/zds/utils/templatetags/french_typography.py
@@ -13,6 +13,9 @@ def french_typography(str):
     before or after some symbols, according to French typography.
 
     This filter is naive and should not be used on Markdown content.
+
+
+    Any change here should also be made in assets/js/featured-resource-preview.js
     """
     return mark_safe(
         # Narrow non-breaking space: &#8239;


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Mettre à jour les fixtures pour séparer le compte admin et le compte bot
**Description du besoin**

Actuellement, on a les deux configurations suivantes (approximativement) :

* sur la version de dev, le compte admin est admin, mais a en plus le rôle de bot ;
* sur la prod (et la bêta j'imagine), on a un bot dédié et le compte admin vit sa vie.

Je pense que ce serait mieux d'avoir une version de dev plus proche de la prod, avec un compte bot dédié. Ça peut éviter certaines surprises lors du développement et surtout lors du déploiement, si on a pas réussi à tester correctement avec la configuration de dév.

**Description de la solution**

Pour avoir la configuration de la prod en dev, il faut mettre à jour les fixtures pour avoir un compte bot et admin configuré comme il faut (bon groupe notamment).


Discussion:

Resolving patch:
diff --git a/zds/settings/abstract_base/zds.py b/zds/settings/abstract_base/zds.py
--- a/zds/settings/abstract_base/zds.py
+++ b/zds/settings/abstract_base/zds.py
@@ -126,7 +126,7 @@
         'cnil': '1771020',
     },
     'member': {
-        'bot_account': zds_config.get('member_bot_username', 'admin'),
+        'bot_account': zds_config.get('member_bot_username', 'bot'),
         'anonymous_account': zds_config.get('member_anonymous_username', 'anonymous'),
         'external_account': zds_config.get('member_external_username', 'external'),
         'bot_group': 'bot',


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Valider que le lien canonique fourni pour une publication est bien un lien
**Description du bug**

Actuellement, le formulaire qui permet de saisir un lien canonique ne vérifie pas que le texte fournit est effectivement un lien valide. 

**Comment reproduire ?**

Aller sur un contenu dont vous êtes l'auteur, et changer le lien canonique.

**Comportement attendu**

Le formulaire devrait vérifier la validité du lien, pour éviter de saisir n'importe quoi (éventuellement par accident).


Discussion:

Resolving patch:
diff --git a/zds/tutorialv2/forms.py b/zds/tutorialv2/forms.py
--- a/zds/tutorialv2/forms.py
+++ b/zds/tutorialv2/forms.py
@@ -270,7 +270,7 @@ class ContentForm(ContainerForm):
         widget=forms.CheckboxSelectMultiple()
     )
 
-    source = forms.CharField(
+    source = forms.URLField(
         label=_("""Si votre contenu est publié en dehors de Zeste de Savoir (blog, site personnel, etc.),
                        indiquez le lien de la publication originale : """),
         max_length=PublishableContent._meta.get_field('source').max_length,
diff --git a/zds/tutorialv2/migrations/0031_source_is_url.py b/zds/tutorialv2/migrations/0031_source_is_url.py
new file mode 100644
--- /dev/null
+++ b/zds/tutorialv2/migrations/0031_source_is_url.py
@@ -0,0 +1,18 @@
+# Generated by Django 2.2.16 on 2020-10-03 17:10
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('tutorialv2', '0030_contentsuggestion'),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name='publishablecontent',
+            name='source',
+            field=models.URLField(blank=True, null=True, verbose_name='Source'),
+        ),
+    ]
diff --git a/zds/tutorialv2/models/database.py b/zds/tutorialv2/models/database.py
--- a/zds/tutorialv2/models/database.py
+++ b/zds/tutorialv2/models/database.py
@@ -62,7 +62,7 @@ class Meta:
     title = models.CharField('Titre', max_length=80)
     slug = models.CharField('Slug', max_length=80)
     description = models.CharField('Description', max_length=200)
-    source = models.CharField('Source', max_length=200, blank=True, null=True)
+    source = models.URLField('Source', max_length=200, blank=True, null=True)
     authors = models.ManyToManyField(User, verbose_name='Auteurs', db_index=True)
     old_pk = models.IntegerField(db_index=True, default=0)
     subcategory = models.ManyToManyField(SubCategory,


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Liens vers les derniers sujets lus et non-lus identiques
Bonjour,

Le titre et le fond des sujets dans **les derniers sujets** sont identiques qu'ils soient lus et non-lus contrairement au forum où ils sont différents. Nous n'avons aucune différence visuel des sujets lus ou non lus sur cette page : https://zestedesavoir.com/forums/derniers-sujets/

Alors que sur le forum c'est présent : 

![image](https://user-images.githubusercontent.com/18501150/80315584-ce3d8980-87f8-11ea-9b10-5b88456d5d86.png)



Discussion:
https://github.com/zestedesavoir/zds-site/blob/1ec7094118f7c3f0149e1063f0572260373e7f36/templates/forum/includes/topic_row.part.html#L10 devrait s'appliquer

Resolving patch:
diff --git a/zds/forum/urls.py b/zds/forum/urls.py
--- a/zds/forum/urls.py
+++ b/zds/forum/urls.py
@@ -3,7 +3,7 @@
 from zds.forum import feeds
 from zds.forum.views import CategoriesForumsListView, ForumCategoryForumsDetailView, ForumTopicsListView, \
     TopicPostsListView, TopicNew, TopicEdit, FindTopic, FindTopicByTag, PostNew, PostEdit, PostSignal, \
-    PostPotentialSpam, PostUseful, PostUnread, FindPost, solve_alert, ManageGitHubIssue, LastTopicsViewTests, \
+    PostPotentialSpam, PostUseful, PostUnread, FindPost, solve_alert, ManageGitHubIssue, LastTopicsListView, \
     FindFollowedTopic
 
 urlpatterns = [
@@ -57,7 +57,7 @@
 
     # Last subjects.
     re_path(r'^derniers-sujets/$',
-            LastTopicsViewTests.as_view(), name='last-subjects'),
+            LastTopicsListView.as_view(), name='last-subjects'),
 
     # Categories and forums list.
     re_path(r'^$', CategoriesForumsListView.as_view(), name='cats-forums-list'),
diff --git a/zds/forum/views.py b/zds/forum/views.py
--- a/zds/forum/views.py
+++ b/zds/forum/views.py
@@ -57,7 +57,7 @@ def get_context_data(self, **kwargs):
         return context
 
 
-class LastTopicsViewTests(ListView):
+class LastTopicsListView(ListView):
 
     context_object_name = 'topics'
     template_name = 'forum/last_topics.html'
@@ -75,6 +75,15 @@ def get_queryset(self):
             .order_by(query_order)[:settings.ZDS_APP['forum']['topics_per_page']]
         return topics
 
+    def get_context_data(self, **kwargs):
+        context = super(LastTopicsListView, self).get_context_data(**kwargs)
+
+        context.update({
+            'topic_read': TopicRead.objects.list_read_topic_pk(self.request.user, context['topics'])
+        })
+
+        return context
+
 
 class ForumTopicsListView(FilterMixin, ForumEditMixin, ZdSPagingListView, UpdateView, SingleObjectMixin):
 


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Erreur 500 lors d'un changement de pseudo trop long
[Reporté par Green sur le forum](https://zestedesavoir.com/forums/sujet/13906/comment-sutilise-la-beta-de-zds/?page=1#p220056) : 

> Salut,
> 
> Après un petit tour dans la bêta pour essayer de comprendre comment s'effectue un [changement de pseudo](https://zestedesavoir.com/membres/parametres/user/), j'ai découvert une erreur interne au serveur :
> 
> [![d](https://zestedesavoir.com/media/galleries/8601/8d9e16ea-32e8-49f0-9e8d-2cfa85120c85.png.120x120_q95_crop.png)](https://zestedesavoir.com/media/galleries/8601/8d9e16ea-32e8-49f0-9e8d-2cfa85120c85.png)
> 
> Pour générer cette erreur, il suffit de changer avec un pseudo très très long.  
> Par ailleurs, un pseudo comme **GreenGreenGreenGreenGreenGreenGreenGreenGreenGreen** est accepté et casse visuellement le CSS du site sur les messages forums.

D'après le Sentry l'erreur est : 

> DataError: (1406, "Data too long for column 'note' at row 1")

Lorsqu'on modifie le pseudo, une note de modération est créée sur le profil "ancien_pseudo s'est renommé nouveau_pseudo" et dans le cas présent le pseudo était trop grand donc la création de la note a échouée.


Discussion:
Comment est-ce qu'on règle ce problème ? Parce que, au final, deux problèmes sont rapportés ici:
- un pseudo trop long casse le CSS;
- changer son pseudo en un pseudo trop long provoque une erreur 500.

La façon la plus simple de régler les deux problèmes est de réduire la longueur maximale d'un pseudo (actuellement 150 caractères, défini dans le modèle `User` de Django).
Je n'ai pas réussi à reproduire la 500 en local, même si le pseudo semble tronqué. Sur la bêta j'ai réussi à reproduire.

Je n'ai pas de soucis avec une réduction de la longueur maximale des pseudos, mais je pense qu'il faudrait plutôt tronquer le pseudo à l'affichage que le limiter en back.





Resolving patch:
diff --git a/zds/member/migrations/0020_auto_20201018_0841.py b/zds/member/migrations/0020_auto_20201018_0841.py
new file mode 100644
--- /dev/null
+++ b/zds/member/migrations/0020_auto_20201018_0841.py
@@ -0,0 +1,16 @@
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('member', '0019_profile_username_skeleton'),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name='karmanote',
+            name='note',
+            field=models.TextField(verbose_name='Commentaire'),
+        ),
+    ]
diff --git a/zds/member/models.py b/zds/member/models.py
--- a/zds/member/models.py
+++ b/zds/member/models.py
@@ -665,7 +665,7 @@ class Meta:
     user = models.ForeignKey(User, related_name='karmanote_user', db_index=True, on_delete=models.CASCADE)
     moderator = models.ForeignKey(User, related_name='karmanote_staff', db_index=True, on_delete=models.SET_NULL,
                                   null=True)
-    note = models.CharField('Commentaire', max_length=150)
+    note = models.TextField('Commentaire')
     karma = models.IntegerField('Valeur')
     pubdate = models.DateTimeField('Date d\'ajout', auto_now_add=True)
 


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Mauvais titre de notification pour le signalement de billet
**Description du bug**

Lorsqu'un membre signale un billet, le titre de la notification est `(<bound method PublishedContent.title of <PublishedContent: Version publique de "La Belgique a un nouveau gouvernement, ça se fête !">>,)` au lieu d'être le nom du contenu.

**Comment reproduire ?**

La liste des étapes qui permet de reproduire le bug :

1. Aller sur le site
2. Connectez vous avec le compte admin
3. Aller sur un billet
4. Cliquez sur « Signaler le contenu »
5. Voir que le titre de la nouvelle notification de signalement est incorrect

**Comportement attendu**

Le titre de la nouvelle notification de signalement est le titre du contenu.


Discussion:

Resolving patch:
diff --git a/zds/utils/header_notifications.py b/zds/utils/header_notifications.py
--- a/zds/utils/header_notifications.py
+++ b/zds/utils/header_notifications.py
@@ -20,7 +20,7 @@ def _get_alert_info(alert):
         return post.topic.title, post.get_absolute_url()
     elif alert.scope == "CONTENT":
         published = PublishableContent.objects.select_related("public_version").get(pk=alert.content.pk)
-        title = (published.public_version.title if published.public_version else published.title,)
+        title = published.public_version.title if published.public_version else published.title
         url = published.get_absolute_url_online() if published.public_version else ""
         return title, url
     elif alert.scope == "PROFILE":


Test patch:
Repository: zestedesavoir/zds-site

Issue:
https://zestedesavoir.com/forums/flux/sujets/rss/ retourne une erreur 500
**Description du bug**

les rss des sujets ont l'air morts

https://zestedesavoir.com/forums/flux/sujets/rss/


Discussion:
C'est un bug connu causé par le passage de l'heure d'été à l'heure d'hiver. On ne garde pas le fuseau horaire des dates en base de données, donc ça crée une ambiguïté qui cause une erreur interne. Normalement dans quelques jours ça devrait s'arrêter tout seul (les sujets et messages publiés le jour du changement d'heure ne seront plus dans les flux RSS). La solution sur le long terme est de prendre en compte le fuseau horaire dans le code : mettre `USE_TZ = True` dans les paramètres et modifier tous les : 

```py
import datetime

now = datetime.datetime.now()
```

en

```py
from django.utils import timezone

now = timezone.now()
```

[Voir la documentation de Django concernant les fuseaux horaires](https://docs.djangoproject.com/fr/3.1/topics/i18n/timezones/)

Resolving patch:
diff --git a/zds/forum/feeds.py b/zds/forum/feeds.py
--- a/zds/forum/feeds.py
+++ b/zds/forum/feeds.py
@@ -2,13 +2,21 @@
 
 from django.utils.feedgenerator import Atom1Feed
 from django.conf import settings
+from django.utils.timezone import make_aware
+from pytz import AmbiguousTimeError, NonExistentTimeError
 
 from .models import Post, Topic
 
 
 class ItemMixin:
     def item_pubdate(self, item):
-        return item.pubdate
+        try:
+            return make_aware(item.pubdate)
+        except AmbiguousTimeError:
+            try:
+                return make_aware(item.pubdate, is_dst=True)
+            except NonExistentTimeError:
+                return make_aware(item.pubdate, is_dst=False)
 
     def item_author_name(self, item):
         return item.author.username
diff --git a/zds/tutorialv2/feeds.py b/zds/tutorialv2/feeds.py
--- a/zds/tutorialv2/feeds.py
+++ b/zds/tutorialv2/feeds.py
@@ -1,8 +1,10 @@
 from django.conf import settings
 from django.contrib.syndication.views import Feed
 from django.shortcuts import get_object_or_404
+from django.utils.timezone import make_aware
 from django.utils.feedgenerator import Atom1Feed
 from django.utils.translation import gettext_lazy as _
+from pytz import AmbiguousTimeError, NonExistentTimeError
 
 from zds.utils.models import Category, SubCategory, Tag
 from zds.utils.uuslug_wrapper import slugify
@@ -54,7 +56,13 @@ def item_title(self, item):
         return item.content.title
 
     def item_pubdate(self, item):
-        return item.publication_date
+        try:
+            return make_aware(item.publication_date)
+        except AmbiguousTimeError:
+            try:
+                return make_aware(item.publication_date, is_dst=True)
+            except NonExistentTimeError:
+                return make_aware(item.publication_date, is_dst=False)
 
     def item_description(self, item):
         return item.content.description


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Corrections / précisions à apporter sur la procédure d'installation du projet
Salut,

En février dernier je m'étais lancé dans l'installation du projet zds-site dans un environnement docker/debian pour travailler sur une PR.
J'avais été amené à faire quelques modifications à la procédure d'installation pour la mener à bien, donc je voudrais vous lister les différents points qui m'avaient posé problème, et discuter des corrections qui pourraient leur être apportées.

* La procédure présupposait l'installation des paquets `build-essential`, `sudo` et `libssl-dev` sous Debian. Je conviens qu'ils sont assez répandus et donc généralement installés, mais je pense que cela pourrait être précisé.
* Plus délicat, les changements récents sur `cryptography` font que Rust devient une dépendance à l'installation du projet, et devrait donc lui aussi être installé avant le début de la procédure (installation via `rustup` puis configuration du `PATH` par exemple).
* L'environnement virtuel créé lors de la procédure ne contenait pas le paquet `wheel`, ce qui la faisait échouer lors des installations de paquets pip. Ça pourrait être corrigé avec un `pip install wheel` avant de passer à la suite.
* Comme le backend tournait dans un docker, j'avais dû modifier la configuration pour écouter sur d'autres adresses, notamment ajouter `'*'` aux `ALLOWED_HOSTS` et préciser le domaine+port (`0.0.0.0:8000`) à la commande `runserver`.

Voilà, c'est tout pour moi, merci pour vos retours !


Discussion:

Resolving patch:
diff --git a/zds/settings/abstract_base/django.py b/zds/settings/abstract_base/django.py
--- a/zds/settings/abstract_base/django.py
+++ b/zds/settings/abstract_base/django.py
@@ -7,8 +7,11 @@
 from .config import config
 from .base_dir import BASE_DIR
 
-
-INTERNAL_IPS = ("127.0.0.1",)  # debug toolbar
+# especially for debug toolbar:
+INTERNAL_IPS = (
+    "127.0.0.1",
+    "172.17.0.1",  # to enable debug toolbar when executed in a Docker container
+)
 
 DATABASES = {
     "default": {
diff --git a/zds/settings/dev.py b/zds/settings/dev.py
--- a/zds/settings/dev.py
+++ b/zds/settings/dev.py
@@ -4,8 +4,7 @@
 
 DEBUG = True
 
-# NOTE: Can be removed once Django 3 is used
-ALLOWED_HOSTS = [".localhost", "127.0.0.1", "[::1]"]
+ALLOWED_HOSTS = ["*"]  # allow everything in case we are in a Docker container
 
 INSTALLED_APPS += (
     "debug_toolbar",


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Doublon pour les logs en couleur dans l'env de dev
Sur mon environnement de dev, les logs en couleur apparaissent en double : dans leur version couleur et puis dans leur version standard.

![image](https://user-images.githubusercontent.com/6664636/132962287-3983d73d-dae7-4f95-b7c1-ed86c63c51ea.png)

OS : Ubuntu Budgie 20.04


Discussion:

Resolving patch:
diff --git a/zds/settings/dev.py b/zds/settings/dev.py
--- a/zds/settings/dev.py
+++ b/zds/settings/dev.py
@@ -55,10 +55,12 @@
             "formatter": "django.server",
         },
     },
+    "root": {
+        "handlers": ["console"],
+    },
     "loggers": {
         "django": {
             "level": "INFO",
-            "handlers": ["console"],
         },
         "django.server": {
             "level": "INFO",
@@ -67,7 +69,6 @@
         },
         "zds": {
             "level": "INFO",
-            "handlers": ["console"],
         },
     },
 }


Test patch:
Repository: zestedesavoir/zds-site

Issue:
Retirer les dernier restes de Travis
**Description du bug**

J'ai l'impression qu'il reste quelques miettes de Travis :

* https://github.com/zestedesavoir/zds-site/blob/dev/zds/settings/travis_fixture.py
* https://github.com/zestedesavoir/zds-site/blob/fe854d9b006e5ca500a911c48e3b25b11154d926/scripts/define_function.sh#L13-L66

**Comportement attendu**

A priori, on ne se sert plus de Travis, donc tout ça devrait disparaître.



Discussion:

Resolving patch:
diff --git a/zds/settings/travis_fixture.py b/zds/settings/travis_fixture.py
deleted file mode 100644
--- a/zds/settings/travis_fixture.py
+++ /dev/null
@@ -1,6 +0,0 @@
-from .ci_test import *
-
-LOGGING["loggers"]["zds.utils.templatetags.emarkdown"] = {
-    "level": "INFO",
-    "handlers": ["console"],
-}


Test patch: