openfortivpn version 1.13.0 #586

DimitriPapadopoulos · 2020-03-22T07:35:42Z

No description provided.

adrienverge · 2020-03-22T08:48:31Z

Thanks Dimitri!

adrienverge · 2020-03-22T08:58:16Z

I tried to create updates for Fedora and CentOS, but version 1.13.0 does not compile: https://kojipkgs.fedoraproject.org//work/tasks/9499/42689499/build.log

src/main.c: In function 'main':
src/main.c:76:24: error: expected ')' before 'RESOLVCONF_USAGE'
   76 | "                    " RESOLVCONF_USAGE "[--ca-file=<file>]\n" \
      |                        ^~~~~~~~~~~~~~~~
src/main.c:477:27: note: in expansion of macro 'usage'
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                           ^~~~~
src/main.c:477:15: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |              ~^
      |               |
      |               char *
src/main.c:477:17: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                ~^
      |                 |
      |                 char *
src/main.c:477:19: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                  ~^
      |                   |
      |                   char *
src/main.c:477:21: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                    ~^
      |                     |
      |                     char *
src/main.c:477:23: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                      ~^
      |                       |
      |                       char *
src/main.c:76:24: error: expected ')' before 'RESOLVCONF_USAGE'
   76 | "                    " RESOLVCONF_USAGE "[--ca-file=<file>]\n" \
      |                        ^~~~~~~~~~~~~~~~
src/main.c:603:24: note: in expansion of macro 'usage'
  603 |  fprintf(stderr, "%s", usage);
      |                        ^~~~~
make: *** [Makefile:628: src/openfortivpn-main.o] Error 1

DimitriPapadopoulos · 2020-03-22T10:12:56Z

Ah strange. I'll try on my Fedora 31 virtual machine and let you know.

DimitriPapadopoulos · 2020-03-22T10:21:28Z

It works for me on Fedora 31:

$ autoreconf -fi
$ 
$ ./autogen.sh
+ type autoconf
+ type automake
+ type aclocal
+ aclocal
+ autoconf
+ automake --add-missing
+ echo 'now you can run ./configure && make to build openfortivpn'
$ 
$ ./configure --prefix=/opt/openfortivpn
[...]
checking for resolvconf... /usr/sbin/resolvconf
configure: RESOLVCONF_PATH... /usr/sbin/resolvconf
configure: HAVE_RESOLVCONF... 1
checking for /usr/sbin/resolvconf... yes
configure: USE_RESOLVCONF... 0
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing timestamp commands
$ 
$ make
  CC       src/openfortivpn-config.o
  CC       src/openfortivpn-hdlc.o
  CC       src/openfortivpn-http.o
  CC       src/openfortivpn-io.o
  CC       src/openfortivpn-ipv4.o
  CC       src/openfortivpn-log.o
  CC       src/openfortivpn-tunnel.o
  CC       src/openfortivpn-main.o
  CC       src/openfortivpn-xml.o
  CC       src/openfortivpn-userinput.o
  CC       src/openfortivpn-openssl_hostname_validation.o
  CCLD     openfortivpn
$

I suspect you need to fully reinitialize Autoconf (autoreconf -fi) after Martin's changes.

DimitriPapadopoulos · 2020-03-22T11:05:09Z

Ah I see the errors for el7, fc31 and fc32:
https://koji.fedoraproject.org/koji/packageinfo?packageID=20983

DimitriPapadopoulos · 2020-03-22T11:16:52Z

The build machine is missing package systemd which provides resolvconf/resolvctl (see root.log). Strange, this package is installed by default on vanilla Fedora 31 installations - but perhaps Workstation only.

The result (see build.log]:

[...]
+ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
[...]
checking for resolvconf... DISABLED
configure: RESOLVCONF_PATH... DISABLED
configure: HAVE_RESOLVCONF... 0
checking for DISABLED... no
configure: USE_RESOLVCONF... 0
[...]

That's indeed a combination we haven't tested, at least recently. And it's good that you've caught it.

DimitriPapadopoulos · 2020-03-22T11:18:11Z

I think I can fix it. Do we move tag 1.13.0 or do we create tag 1.13.1?

DimitriPapadopoulos · 2020-03-22T11:29:41Z

I can simulate that on my Fedora machine without uninstalling systemd using:

sudo mv /usr/sbin/resolvconf /usr/sbin/resolvconf.bak

The result is identical:

$ ./configure --prefix=/opt/openfortivpn
[...]
checking for resolvconf... DISABLED
configure: RESOLVCONF_PATH... DISABLED
configure: HAVE_RESOLVCONF... 0
checking for DISABLED... no
configure: USE_RESOLVCONF... 0
[...]
$ 
$ make
[...]
  CC       src/openfortivpn-main.o
src/main.c: In function 'main':
src/main.c:76:24: error: expected ')' before 'RESOLVCONF_USAGE'
   76 | "                    " RESOLVCONF_USAGE "[--ca-file=<file>]\n" \
      |                        ^~~~~~~~~~~~~~~~
src/main.c:477:27: note: in expansion of macro 'usage'
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                           ^~~~~
src/main.c:477:15: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |              ~^
      |               |
      |               char *
src/main.c:477:17: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                ~^
      |                 |
      |                 char *
src/main.c:477:19: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                  ~^
      |                   |
      |                   char *  CC       src/openfortivpn-main.o

src/main.c:477:21: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                    ~^
      |                     |
      |                     char *
src/main.c:477:23: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  477 |    printf("%s%s%s%s%s%s", usage, summary, help_options,
      |                      ~^
      |                       |
      |                       char *
src/main.c:76:24: error: expected ')' before 'RESOLVCONF_USAGE'
   76 | "                    " RESOLVCONF_USAGE "[--ca-file=<file>]\n" \
      |                        ^~~~~~~~~~~~~~~~
src/main.c:603:24: note: in expansion of macro 'usage'
  603 |  fprintf(stderr, "%s", usage);
      |                        ^~~~~
make: *** [Makefile:624: src/openfortivpn-main.o] Error 1
$

Note that a simple ./configure --disable-resolvconf has not the same effect:

$ sudo mv /usr/sbin/resolvconf.bak /usr/sbin/resolvconf
$ 
$ ./configure --prefix=/opt/openfortivpn --disable-resolvconf
[...]
checking for resolvconf... /usr/sbin/resolvconf
configure: RESOLVCONF_PATH... /usr/sbin/resolvconf
configure: HAVE_RESOLVCONF... 1
configure: USE_RESOLVCONF... 0
[...]
$

@mrbaseman I don't think we want that, do we?

DimitriPapadopoulos · 2020-03-22T12:06:31Z

Fixed by pull request #587 and will work on Fedora / CentOS / EPEL, with resolvconf support entirely disabled.

These questions remain:

Do we want resolvconf support entirely disabled at build-time (HAVE_RESOLVCONF set to 0) or simply disabled by default at run-time (HAVE_RESOLVCONF set to 1 and USE_RESOLVCONF set to 0)?
If we want to keep resolvconf support at build-time but disable it by default at run-time, the spec files need to be modified to either install systemd as a build-time dependency but not as a run-time dependency, or alternatively add this Autoconf option to the build file:
--with-resolvconf=/usr/sbin/resolvconf
I'm not entirely comfortable with these multiple options:
--with-resolvconf=/path/to/resolvconf
--with-resolvconf=DISABLED
--disable-resolvconf
At the very least I think --disable-resolvconf should entirely disable resolvconf support and be equivalent to --with-resolvconf=DISABLED which should be dropped.

adrienverge · 2020-03-22T12:08:49Z

@DimitriPapadopoulos thanks for investigating: it was indeed systemd requirement that was missing.

I've added it in the spec file, it builds on Koji now.

adrienverge · 2020-03-22T12:12:01Z

@DimitriPapadopoulos, sorry, our messages crossed.

I think #587 makes sense. So I propose not to push "v1.13.0 + systemd fix" packages (already partly created on Koji for Fedora and CentOS), but instead wait for v1.13.1. What do you think?

EDIT: Strangely, its still fails for CentOS 7. Maybe systemd does not provide resolvconf? Anyway, v1.13.1 should fix it.

src/main.c: In function 'main':
src/main.c:76:24: error: expected ')' before 'RESOLVCONF_USAGE'
 "                    " RESOLVCONF_USAGE "[--ca-file=<file>]\n" \
                        ^
src/main.c:477:27: note: in expansion of macro 'usage'
    printf("%s%s%s%s%s%s", usage, summary, help_options,
                           ^
src/main.c:478:11: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
           PPPD_HELP, RESOLVCONF_HELP, help_config);
           ^
src/main.c:478:11: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
src/main.c:478:11: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
src/main.c:478:11: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
src/main.c:478:11: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
src/main.c:76:24: error: expected ')' before 'RESOLVCONF_USAGE'
 "                    " RESOLVCONF_USAGE "[--ca-file=<file>]\n" \
                        ^
src/main.c:603:24: note: in expansion of macro 'usage'
  fprintf(stderr, "%s", usage);
                        ^
make: *** [src/openfortivpn-main.o] Error 1

DimitriPapadopoulos · 2020-03-22T12:49:49Z

I agree, let's wait for 1.13.1. It can be released pretty soon, I would just like some input from Martin on my suggestion to merge (or not) --with-resolvconf=DISABLED and --disable-resolvconf.

Are you able to add systemd as build-time but not run-time dependency?

DimitriPapadopoulos · 2020-03-22T13:19:39Z

Indeed CentOS 7 does not provide /usr/bin/resolvectl, let alone /usr/sbin/resolvconf:

systemd-219-67.el7

CentOS 8, Fedora 30 and 31 do:

adrienverge · 2020-03-23T05:55:29Z

Are you able to add systemd as build-time but not run-time dependency?

Yes I can. I added systemd as runtime requirement too, because I thought it was needed since at compile time we assume HAVE_RESOLVCONF. But maybe I'm wrong; do you think I should remove it?

Indeed CentOS 7 does not provide /usr/bin/resolvectl, let alone /usr/sbin/resolvconf:

Right; and no other package provides it (sudo yum provides '*/resolvconf').
I'm planning to revert BuildRequires: systemd (both for CentOS and Fedora) and simply package v1.13.1, which contains https://github.com/adrienverge/openfortivpn/pull/587/files. Does that sound good?

DimitriPapadopoulos · 2020-03-23T07:27:06Z

But maybe I'm wrong; do you think I should remove it?

Absolutely, please remove systemd from run-time dependencies: openfortivpn calls resolvconf if it is available and otherwise falls back to updating /etc/resolv.conf directly as was the case before. Therefore systemd is completely optional. Actually moving /usr/sbin/resolvconf out of the way works around the 1.12.0 issue we're fixing with 1.13.

I'm planning to revert BuildRequires: systemd (both for CentOS and Fedora) and simply package v1.13.1, which contains https://github.com/adrienverge/openfortivpn/pull/587/files. Does that sound good?

Yes, you could even remove systemd from build-time dependencies. We would still have the fallback mechanism which updates /etc/resolv.conf directly and has been working for years. Besides resolvconf doesn't work (as expected at least) on CentOS/Fedora so we disable it anyway. We just disable it in different ways:

With systemd at build-time, we define HAVE_RESOLVCONF = 1 but USE_RESOLVCONF = 0 because we detect resolvconf doesn't work. Support for resolvconf is built-in, disabled by default and can be re-enabled at run-time with --use-resolvconf=1.
With systemd at build-time, we define HAVE_RESOLVCONF = 0 and USE_RESOLVCONF = 0. Support for resolvconf is not built-in and cannot be re-enabled at run-time with --use-resolvconf=1.

Actually I'm all in favour of disabling resolvconf support totally on CentOS/Fedora until we have answers to issue 1815605 on the Red Hat bug tracker and clarify how DNS parameters are supposed to be updated.

mrbaseman · 2020-03-23T10:38:47Z

the two configure options

--with-resolvconf=DISABLED and --disable-resolvconf
allow us to distinguish several scenarios:

disable resolvconf support completely (to avoid checks for the existence of a file that perhaps will never exist on some platforms)
compile in resolvconf support but disable it by default so that it can be enabled via config file or command line option when missing packages are installed and properly configured
enable resolvconf support completely and have it on by default

There are several options to simplify this and keep only one of the configure options:

make the decision at configure time and drop the case in which the user can have resolvonf support compiled in but disabled by default
always compile resolvconf support in and fall back to the most likely location if the executable is not found at configure time, maybe disable it by default if no working configuration is found
drop the switch that enables / disables the default for the runtime option and tie that decision to the magic that runs the tests at configure time, e.g. if a working resolvconf installation is detected, enable it by default, and do the same if a path is supplied by --with-resolvoconf, even if no executable is available is installed on the build-system.

Personally, I like the current implementation because for its flexibility, but I must admit that it's not really transparent. I'm fine, too, with each of the above changes. We just should be careful not to break things that we have just implemented for 1.13 and which are actively used anywhere.

Just a side note: I've just checked the case HAVE_RESOLVCONF = 0 and USE_RESOLVCONF = 1:
resolvconf support is disabled then, so USE_RESOLVCONF has no effect in this case.

DimitriPapadopoulos · 2020-03-23T11:00:03Z

@mrbaseman OK let's leave it as it is now. While I understand the purpose of these Autoconf options, I had this impression that there are too many of them and that we should perhaps discard this use case:

compile in resolvconf support but disable it by default so that it can be enabled via config file or command line option when missing packages are installed and properly configured

But as I said I'm fine with keeping these options, it's a good idea after all. It's just that the semantics are not clear at first sight:

--with-resolvconf=DISABLED
--disable-resolvconf

adrienverge · 2020-03-23T13:50:21Z

@DimitriPapadopoulos thanks for your explanations, it makes sense. I've removed systemd both from BuildRequires and Requires.

Packages for Fedora 31, Fedora 32 and CentOS 8 are built and on their way to publishing. For some reason, building for CentOS 7 fails currently (but it does not seem related to openfortivpn).

mrbaseman · 2020-03-23T14:20:49Z

I have improved the help strings of the configure options in #593

adrienverge · 2020-03-24T07:11:28Z

For some reason, building for CentOS 7 fails currently (but it does not seem related to openfortivpn).

This morning, build passed. I pushed the update to CentOS 7, it should arrive to stable in 14 days.

cognifloyd · 2020-04-02T03:05:24Z

@adrienverge I'm very sad that the CentOS 7/8 builds of openfortivpn don't seem to be using the systemd libs. Without that Type=notify systemd units aren't possible. How hard would it be to add those libs to the build so that sd_notfiy works? (notify support added in #370)

DimitriPapadopoulos · 2020-04-02T04:54:19Z

@cognifloyd Hi Jacob, this is indeed a side effect of removing systemd from the specifications because systemd ships with a broken resolvconf executable on Fedora. Unfortunately systemd also serves another purpose: notifications.

@adrienverge There are two ways of disabling resolvconf support:

removing systemd altogether at build-time, at the expense of supporting systemd notifications too,
adding --with-resolvconf=DISABLED --disable-resolvconf to the spec file for as long as we don't support resolvectl in addition to resolvconf (see Improve DNS handling? #600).

Without changing the oopenfortivpn sources, it might be possible to updates the spec file by inserting back BuildRequires and Requires and adding --with-resolvconf=DISABLED --disable-resolvconf to the Autoconf options.

adrienverge · 2020-04-02T09:58:57Z

Without changing the oopenfortivpn sources, it might be possible to updates the spec file by inserting back BuildRequires and Requires and adding --with-resolvconf=DISABLED --disable-resolvconf to the Autoconf options.

Thanks @DimitriPapadopoulos 👍
Restoring requirements and adding --with-resolvconf=DISABLED --disable-resolvconf is doable, but would it have other implications? I mean could it break behavior for some Fedora/CentOS users with resolvconf?

@cognifloyd do you want to propose a diff for the spec file?

DimitriPapadopoulos · 2020-04-02T10:06:29Z

There should be no implications because --with-resolvconf=DISABLED --disable-resolvconf disables support for resolvconf (broken on CentOS/Fedora) at build-time. The CentOS/Fedora behaviour would remain unchanged: openfortivpn falls back on modifying /etc/resolv.cong directly, the method that had been used for ever by openfortivpn and FortiClient.

DimitriPapadopoulos · 2020-04-02T11:25:14Z

@cognifloyd The spec file is maintained here:
https://src.fedoraproject.org/rpms/openfortivpn

cognifloyd · 2020-04-06T19:19:19Z

I'm sorry, I am unable to install fedpkg to be able to work with the repos on src.fedoraproject.org as my primary development machine is gentoo. I've run out of time to figure out how to get a setup for editing rpms. If I get time another day, I can try again. Is there any chance you will have time to update the rpm?
Thanks!

adrienverge · 2020-04-07T06:02:49Z

@cognifloyd can you try this build: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19aca4f76e and report if it works for you?

cognifloyd · 2020-04-07T21:57:56Z

Woohoo. That worked on both el7 and el8.
I can't actually test anything with changing resolvconf because the fortigate I'm connecting to is not configured to send any dns details, so there's nothing to change.

adrienverge · 2020-04-08T05:35:02Z

Cool! Thanks for +1 karma on Bodhi 👍

cognifloyd · 2020-04-24T07:48:11Z

This is rather odd to be using a closed PR for communication. Sorry.
@adrienverge could you push the EL7 rpm to stable? I don't understand why bodhi didn't do it automatically after 14 days.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-19aca4f76e

mrbaseman · 2020-04-24T09:05:43Z

This is rather odd to be using a closed PR for communication. Sorry.

this is because the communication has started on a pull request which has been merged.

I admit we should have moved it to a new issue. We have done so for some aspects, but not for the general discussion about packaging. We should keep this in mind for future releases and first open a github issue. In the github issue about tagging a new release we can

start the discussion what we want to merge before finalizing the release
link the PR that increments the version number and updates the CHANGELOG
discuss all the questions about packaging
discuss possible problems and bugs to fix that arise during that process on particular platforms

For the paggageing of 1.13.0 it's probably too late, but:
Anyone who would answer in this thread, please consider opening a new issue if further problems arise around the 1.13.0 release.

adrienverge · 2020-04-24T15:55:08Z

I agree with @mrbaseman.

@cognifloyd I pushed the update to stable on Bodhi. Next time, only one ping on Bodhi should be enough ;)

openfortivpn version 1.13.0

3377cc1

DimitriPapadopoulos force-pushed the release branch from 79d0fde to 3377cc1 Compare March 22, 2020 07:38

adrienverge merged commit 3fc2df1 into adrienverge:master Mar 22, 2020

DimitriPapadopoulos deleted the release branch March 22, 2020 10:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

openfortivpn version 1.13.0 #586

openfortivpn version 1.13.0 #586

DimitriPapadopoulos commented Mar 22, 2020

adrienverge commented Mar 22, 2020

adrienverge commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020 •

edited

Loading

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020 •

edited

Loading

adrienverge commented Mar 22, 2020

adrienverge commented Mar 22, 2020 •

edited

Loading

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

adrienverge commented Mar 23, 2020 •

edited

Loading

DimitriPapadopoulos commented Mar 23, 2020 •

edited

Loading

mrbaseman commented Mar 23, 2020 •

edited

Loading

DimitriPapadopoulos commented Mar 23, 2020

adrienverge commented Mar 23, 2020

mrbaseman commented Mar 23, 2020

adrienverge commented Mar 24, 2020

cognifloyd commented Apr 2, 2020

DimitriPapadopoulos commented Apr 2, 2020 •

edited

Loading

adrienverge commented Apr 2, 2020

DimitriPapadopoulos commented Apr 2, 2020

DimitriPapadopoulos commented Apr 2, 2020

cognifloyd commented Apr 6, 2020 •

edited

Loading

adrienverge commented Apr 7, 2020

cognifloyd commented Apr 7, 2020

adrienverge commented Apr 8, 2020

cognifloyd commented Apr 24, 2020

mrbaseman commented Apr 24, 2020 •

edited

Loading

adrienverge commented Apr 24, 2020

openfortivpn version 1.13.0 #586

openfortivpn version 1.13.0 #586

Conversation

DimitriPapadopoulos commented Mar 22, 2020

adrienverge commented Mar 22, 2020

adrienverge commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020 • edited Loading

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020 • edited Loading

adrienverge commented Mar 22, 2020

adrienverge commented Mar 22, 2020 • edited Loading

DimitriPapadopoulos commented Mar 22, 2020

DimitriPapadopoulos commented Mar 22, 2020

adrienverge commented Mar 23, 2020 • edited Loading

DimitriPapadopoulos commented Mar 23, 2020 • edited Loading

mrbaseman commented Mar 23, 2020 • edited Loading

DimitriPapadopoulos commented Mar 23, 2020

adrienverge commented Mar 23, 2020

mrbaseman commented Mar 23, 2020

adrienverge commented Mar 24, 2020

cognifloyd commented Apr 2, 2020

DimitriPapadopoulos commented Apr 2, 2020 • edited Loading

adrienverge commented Apr 2, 2020

DimitriPapadopoulos commented Apr 2, 2020

DimitriPapadopoulos commented Apr 2, 2020

cognifloyd commented Apr 6, 2020 • edited Loading

adrienverge commented Apr 7, 2020

cognifloyd commented Apr 7, 2020

adrienverge commented Apr 8, 2020

cognifloyd commented Apr 24, 2020

mrbaseman commented Apr 24, 2020 • edited Loading

adrienverge commented Apr 24, 2020

DimitriPapadopoulos commented Mar 22, 2020 •

edited

Loading

DimitriPapadopoulos commented Mar 22, 2020 •

edited

Loading

adrienverge commented Mar 22, 2020 •

edited

Loading

adrienverge commented Mar 23, 2020 •

edited

Loading

DimitriPapadopoulos commented Mar 23, 2020 •

edited

Loading

mrbaseman commented Mar 23, 2020 •

edited

Loading

DimitriPapadopoulos commented Apr 2, 2020 •

edited

Loading

cognifloyd commented Apr 6, 2020 •

edited

Loading

mrbaseman commented Apr 24, 2020 •

edited

Loading