Re: Re[2]: The case for changing the documentation syntax

[Hugues Alary]

And for comparison's sake, here's Asciidoc renders on github:
https://github.com/asciidoctor/asciidoctor/blob/master/README.adoc

Other features of the asciidoc/asciidoctor ecosystem are:
- Asciidoc is also standardized
- https://antora.org/ allows you to build 1 documentation website, from
multiple documentation repositories.
- asciidoctor is extendable, either by writing an extension in Javascript (
https://asciidoctor-docs.netlify.com/asciidoctor.js/extend/extensions/register/)
or in Ruby (https://asciidoctor.org/docs/user-manual/#example-extensions)
and it supports custom backends

Though I have no skin in the game. ReStructuredText is great, I'm merely
presenting other options.

On Tue, Jul 2, 2019 at 9:05 AM Nick Ramirez  wrote:

> I found this page on Github. It uses reStructuredText and demonstrates how
> Github would render various elements out of the box. Of course, it can be
> made more visually appealing with other tools, but it's a free benefit that
> it renders on Github.
>
> https://gist.github.com/ionelmc/e876b73e2001acd2140f
>
>
> -- Original Message --
> From: "Lukas Tribus" 
> To: "Nick Ramirez" 
> Cc: "haproxy@formilux.org" ; "Cyril" <
> cyril.bo...@free.fr>
> Sent: 7/1/2019 6:49:50 PM
> Subject: Re: The case for changing the documentation syntax
>
> Hello Nick,
>
>
> On Mon, 1 Jul 2019 at 17:02, Nick Ramirez  wrote:
>
>
> Hello all,
>
> I'd like to propose something radical, but that will greatly help us in
> terms of documentation. (And documentation is very important when it comes
> to people choosing whether to use a piece of software, as I am sure you
> agree!)
>
> First, the problem: Our documentation at
> https://github.com/haproxy/haproxy/blob/master/doc/configuration.txt is
> written using a sort of home-grown syntax that uses various conventions for
> indicating sections, keywords, etc.
>
> However, parsing this home-grown documentation is difficult. For example,
> I contribute to the HAProxy Syntax Support for Atom project (
> https://github.com/abulimov/atom-language-haproxy). This is a python
> program that must parse the HAProxy configuration.txt file and find the
> keywords by first finding specific section titles, then looking for lines
> that don't have spaces in front of them. That's how we find the keywords in
> each section. It must be updated when new versions of HAProxy are released
> because new sections are added and the section numbers may change, and some
> sections are not reliably using the home-grown syntax. In short, parsing
> configuration.txt is difficult, error-prone and requires regular
> maintenance because its syntax is:
>
> * Not a standard
> * Not used consistently throughout the document
> * Not easily parsed by existing tools (home-grown tools must be created
> and maintained)
>
> You may wonder, why do we need to parse configuration.txt? The reasons are:
>
> * A text file without any styling is difficult to read, so we want to add
> styling (e.g. convert it to HTML with CSS or offer a PDF download)
> * We want search functionality of the document and an auto-generated table
> of contents
> * We want to write haproxy.cfg files and have them displayed in
> syntax-highlighted color when using Github Gist or any modern text editor
> (Atom, VS Code, Sublime Text, etc.). For that, we must currently parse
> configuration.txt to learn the keywords (as in the atom-language-haproxy
> project mentioned). For example, we use Github Gist, with the
> atom-language-haproxy project, to display HAProxy configuration snippets in
> color on the haproxy.com/blog. It would be easier to maintain this if we
> could parse configuration.text more easily.
>
>
>
> Actually since 7 years we do 2 of the 3 things you mention here;
> documentation.txt and others are parsed automatically (in python) and
> generate a verify nice HTML site, searchable and indexed with table of
> contents, etc:
>
> https://www.mail-archive.com/haproxy@formilux.org/msg07040.html
> https://github.com/cbonte/haproxy-dconv
> https://cbonte.github.io/haproxy-dconv/
>
>
> We use this extensively and are able to point people to specific
> sections or keywords of the documentation. When the documentation is
> inconsistent and breaks the tool, we (or more specifically Cyril)
> fixes it. I don't see any 2.0 specific changes in haproxy-dconv, and
> I'm not sure if a structured text would fix all the issues you have
> with the atom project.
>
> I'm not saying we should maintain configuration.txt as it currently
> is, but to me the status-quo does not feel as dire as you suggested.
>
>
> haproxy-dconv also mentions:
>
>
> The purpose of this project is to ultimately convert the HAProxy
> documentation into a more generic format (example : ReStructuredText) that
> would allow for an easier spreading of various output files (.pdf, .html,
> .epub, etc).
>
>
> So it seems like there is common ground. I'm CCing Cyril who has
> invested a lot of time for this already.
>
>
> I think I agree that we would 

Re: Re[2]: The case for changing the documentation syntax

[Hugues Alary]

Adding my 2 cents here: I write documentation a lot and would like to
mention the Asciidoc format, and more specifically asciidoctor (
https://asciidoctor.org/). Asciidoc is a _very_ powerful syntax yet
extremely simple to use.

Here's a link to their cheat sheet to give you a quick idea of the syntax:
https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/
And a more in depth manual:
https://asciidoctor.org/docs/user-manual/#introduction-to-asciidoctor

On Mon, Jul 1, 2019 at 1:51 PM Nick Ramirez  wrote:

> Yes, either reStructuredText or Markdown would be okay. They both have a
> very intuitive syntax, so newcomers would pick it up and become
> productive with it quickly. It is quite easy to learn either one.
>
>
>
> -- Original Message --
> From: "Aleksandar Lazic" 
> To: "Nick Ramirez" ; "haproxy@formilux.org"
> 
> Sent: 7/1/2019 12:05:15 PM
> Subject: Re: The case for changing the documentation syntax
>
> >Hi Nick.
> >
> >Am 01.07.2019 um 17:01 schrieb Nick Ramirez:
> >>  Hello all,
> >>
> >>  I'd like to propose something radical, but that will greatly help us
> in terms of
> >>  documentation. (And documentation is very important when it comes to
> people
> >>  choosing whether to use a piece of software, as I am sure you agree!)
> >
> >Full Ack. This discussion comes up from time to time and I agree with you
> that a
> >more mainstream format would be nice.
> >
> >>  First, the problem: Our documentation
> >>  at
> https://github.com/haproxy/haproxy/blob/master/doc/configuration.txt is
> >>  written using a sort of home-grown syntax that uses various
> conventions for
> >>  indicating sections, keywords, etc.
> >>
> >>  However, parsing this home-grown documentation is difficult. For
> example, I
> >>  contribute to the HAProxy Syntax Support for Atom project
> >>  (https://github.com/abulimov/atom-language-haproxy). This is a python
> program
> >>  that must parse the HAProxy configuration.txt file and find the
> keywords by
> >>  first finding specific section titles, then looking for lines that
> don't have
> >>  spaces in front of them. That's how we find the keywords in each
> section. It
> >>  must be updated when new versions of HAProxy are released because new
> sections
> >>  are added and the section numbers may change, and some sections are
> not reliably
> >>  using the home-grown syntax. In short, parsing configuration.txt is
> difficult,
> >>  error-prone and requires regular maintenance because its syntax is:
> >>
> >>  * Not a standard
> >>  * Not used consistently throughout the document
> >>  * Not easily parsed by existing tools (home-grown tools must be
> created and
> >>  maintained)
> >>
> >>  You may wonder, why do we need to parse configuration.txt? The reasons
> are:
> >>
> >>  * A text file without any styling is difficult to read, so we want to
> add
> >>  styling (e.g. convert it to HTML with CSS or offer a PDF download)
> >>  * We want search functionality of the document and an auto-generated
> table of
> >>  contents
> >>  * We want to write haproxy.cfg files and have them displayed in
> >>  syntax-highlighted color when using Github Gist or any modern text
> editor (Atom,
> >>  VS Code, Sublime Text, etc.). For that, we must currently parse
> >>  configuration.txt to learn the keywords (as in the
> atom-language-haproxy project
> >>  mentioned). For example, we use Github Gist, with the
> atom-language-haproxy
> >>  project, to display HAProxy configuration snippets in color on the
> >>  haproxy.com/blog. It would be easier to maintain this if we could
> parse
> >>  configuration.text more easily.
> >>
> >>  The solution I am proposing:
> >>
> >>  Rather than using a home-grown, difficult to parse,
> not-consistently-used
> >>  grammar. We should use a standard. We should use
> >>  reStructuredText: http://docutils.sourceforge.net/rst.html
> >>
> >>  The reStructuredText syntax gives us the following benefits:
> >>
> >>  * It is well documented
> >>  * Tools exist to parse this and convert it to other formats (such as
> HTML)
> >>  * Tools exist that will "error check" the document to ensure that the
> correct
> >>  syntax is used throughout configuration.txt (which would become
> configuration.rst)
> >>  * Tools such as Jekyll can easily parse reStructuredText and build
> >>  sophisticated, beautiful webpages that feature search functionality,
> >>  table-of-contents, images, graphs, links, etc. We could really start
> to make the
> >>  documentation shine!
> >>  * We won't have to worry about updating special tools because
> reStructuredText
> >>  syntax will allow us to reliably parse it forever
> >>  * reStructuredText is still easily human-readable using a terminal,
> plain-text
> >>  editor, etc.
> >>
> >>  I and others are fully willing to make the conversion to
> reStructuredText, too.
> >>  What do you all think?
> >
> >I would prefer Markdown with pandoc as I don't like the rst format, but
> I'm fine
> >with what the community and contributes 

Re: Re[2]: Makefile:813: recipe for target 'haproxy' failed

[Milenko Markovic]

Hi Aleks

I have solved the problem, OpenSSL was not recognized

TARGET=linux24 USE_OPENSSL=1.1.0g SSL_INC=$STATICLIBSSL/include
SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl

All the best

Milenko

On 7 January 2018 at 20:25, Aleksandar Lazic  wrote:

> Zadravo Milenko.
>
> Please keep the list in the communication, thank you very much.
>
> -- Originalnachricht --
> Von: "Milenko Markovic" 
> An: "Aleksandar Lazic" 
> Gesendet: 07.01.2018 09:02:56
> Betreff: Re: Makefile:813: recipe for target 'haproxy' failed
>
> locate libpthread.so
>
> /lib/x86_64-linux-gnu/libpthread.so.0
> /lib32/libpthread.so.0
> /usr/lib/x86_64-linux-gnu/libpthread.so
>
> On 7 January 2018 at 08:46, Milenko Markovic 
> wrote:
>
>> Zdravo Aleks
>>
>> OS-Ubuntu 16.04
>> ldd --version
>> ldd (Ubuntu GLIBC 2.23-0ubuntu9) 2.23
>> gcc --version
>> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
>> OpenSSL-libssl Version: 1.1.0g
>>
>
> I assume that  you should add -lpthread to ADDLIB
>
> You should have seen such a lib at compile output of openssl, maybe you
> will see it also in the output of
>
> /tmp/staticlibssl/bin/openssl version -a
>
> Greetings
> Aleks
>
> Pozdrav,
>> M.
>>
>
>> On 7 January 2018 at 08:27, Aleksandar Lazic  wrote:
>>
>>> Hi.
>>>
>>> -- Originalnachricht --
>>> Von: "Milenko Markovic" 
>>> An: haproxy@formilux.org
>>> Gesendet: 07.01.2018 07:53:44
>>> Betreff: Makefile:813: recipe for target 'haproxy' failed
>>>
>>> Dear Sir or Madam

 When I run
 make TARGET=linux24 USE_OPENSSL=1 SSL_INC=$STATICLIBSSL/include
 SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl
 this appears on screen
 Makefile:813: recipe for target 'haproxy' failed

 I have attached the whole output as txt file. It would be nice if
 someone could help me.

>>> Looks like that you have build the 'staticlibssl' with thread support
>>> but the gcc miss the '-lpthread' or similar library.
>>>
>>>
>>> ```
>>> gcc -g -o haproxy src/haproxy.o src/base64.o src/protocol.o
>>> src/uri_auth.o src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o
>>> src/channel.o src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o
>>> src/pipe.o src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o
>>> src/frontend.o src/proxy.o src/peers.o src/arg.o src/stick_table.o
>>> src/proto_uxst.o src/connection.o src/proto_http.o src/raw_sock.o
>>> src/backend.o src/tcp_rules.o src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o
>>> src/lb_map.o src/lb_fas.o src/stream_interface.o src/stats.o
>>> src/proto_tcp.o src/applet.o src/session.o src/stream.o src/hdr_idx.o
>>> src/ev_select.o src/signal.o src/acl.o src/sample.o src/memory.o
>>> src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o src/payload.o
>>> src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o src/dns.o
>>> src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o src/flt_spoe.o
>>> src/cli.o src/ev_poll.o src/ssl_sock.o src/shctx.o ebtree/ebtree.o
>>> ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o
>>> ebtree/ebimtree.o ebtree/ebistree.o -lcrypt -ldl -L/tmp/staticlibssl/lib
>>> -lssl -lcrypto -ldl -ldl
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_lock_new':
>>> threads_pthread.c:(.text+0x25): undefined reference to
>>> `pthread_rwlock_init'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_read_lock':
>>> threads_pthread.c:(.text+0x65): undefined reference to
>>> `pthread_rwlock_rdlock'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_write_lock':
>>> threads_pthread.c:(.text+0x85): undefined reference to
>>> `pthread_rwlock_wrlock'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_unlock':
>>> threads_pthread.c:(.text+0xa5): undefined reference to
>>> `pthread_rwlock_unlock'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_lock_free':
>>> threads_pthread.c:(.text+0xca): undefined reference to
>>> `pthread_rwlock_destroy'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_run_once':
>>> threads_pthread.c:(.text+0xf5): undefined reference to `pthread_once'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_init_local':
>>> threads_pthread.c:(.text+0x115): undefined reference to
>>> `pthread_key_create'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_set_local':
>>> threads_pthread.c:(.text+0x147): undefined reference to
>>> `pthread_setspecific'
>>> /tmp/staticlibssl/lib/libcrypto.a(threads_pthread.o): In function
>>> `CRYPTO_THREAD_cleanup_local':
>>> threads_pthread.c:(.text+0x167): undefined reference to
>>> `pthread_key_delete'
>>> 

Re: Re[2]: CI/CD HAProxy

[Илья Шипицин]

2017-12-15 13:07 GMT+05:00 Aleksandar Lazic :

> Hi
>
> -- Originalnachricht --
> Von: "Илья Шипицин" 
> An: "Aleksandar Lazic" 
> Cc: "Olivier Doucet" ; "HAProxy" <
> haproxy@formilux.org>
> Gesendet: 14.12.2017 14:57:29
> Betreff: Re: CI/CD HAProxy
>
>
>>
>> 2017-09-16 20:01 GMT+05:00 Aleksandar Lazic :
>>
>>> Hi Olivie.
>>>
>>> Olivier Doucet wrote on 15.09.2017:
>>>
>>> > Hi,
>>> >
>>> > I wanted to open a new thread, as "cppcheck finding" was hijacked with
>>> this CICD / testing ;)
>>>
>>> +1
>>>
>>> > I think the best is the enemy of the good : why not start with a few
>>> > easy tests ? For example just a mix of tiny / big config files to test
>>> the parser.
>>> >
>>> > I understand the difficult part of the test is to setup complicated
>>> > infrastructures with many softwares to test edge cases, but that can
>>> be done later.
>>> >
>>> > Willy, there is no need to setup and maintain a buildfarm (no one has
>>> > time for this) : as this is an open project, we can use platform like
>>> > Travis-CI : all tests are described in a yaml file incorporated in the
>>> > project. It works out of the box for any project hosted at github. We
>>> can use a mirror for this.
>>>
>>> I like the idea.
>>>
>>> Does anyone know who own https://github.com/haproxy/haproxy <
>>> https://github.com/haproxy/haproxy> ?
>>>
>>> I can start with some easy checks, the question is should we have a git
>>> hook when a commit is done on http://git.haproxy.org ?
>>>
>>> > What is great about these is that you can easily plug syntax check
>>> softwares ;)
>>>
>>> +1 ;-)
>>>
>>> > Olivier
>>>
>>> --
>>> Best Regards
>>> Aleks
>>>
>>>
>>>
>>
>> Hello,
>>
>> I made weird thing
>>
>>
>> https://gitlab.com/chipitsine/haproxy/blob/master/.gitlab-ci.yml
>>
>> repo itself is merged hourly with upstream repo (by using external syncer)
>>
>> https://gitlab.com/chipitsine/haproxy/-/jobs
>>
>
> I can't read it, is it a public repo?
>

I set it to "internal", that means any authenticated user can access it
probably, I can make repo itself public, but pipelines are not available
publicly


>
> Best regards
> aleks
>
>

Re: Re[2]:

[Malcolm Turnbull]

On 19 March 2011 10:58, Antony ddj...@mail.ru wrote:
 Hi all,

 Actually I asked this question because I saw a lot of times systems that had 
 more than 10Gb of free physical memory and they anyway used swap 
 partition(about 1-5 Mb). I saw that happened on FreeBSD and on Linux, so I 
 thought it's possible to see that again when I'll run HAProxy.

Antony,

The argument has come up on the kernel mailing list a few times,
people tend to get religious about it.
Personally I never have a swap partition on a server. (and its always
worked well for me).
Yes, If something goes hideously wrong then the OOM killer will be
invoked (but swap will only slow down the system even more and then
die, at least OOM has a small chance to take out the offending
process..)


-- 
Regards,

Malcolm Turnbull.

Loadbalancer.org Ltd.
Phone: +44 (0)870 443 8779
http://www.loadbalancer.org/

Re: Re[2]: FreeBSD Ports: bumping haproxy from v1.2.18 - v1.4.x

[joris dedieu]

 Also, changing -devel right now at the same will cause all sorts of
 support issues as people deal with the migration - not everyone reads
 the UPDATING file before issuing portupgrade -a.

Even a solution should be  to mark the haproxy-devel has Moved (see
/usr/ports/MOVED)
I see in portupgrade's man page that there is an --ignore-moved
switch. So we can suppose
that portupgrade reads MOVED file.

So maybe :
moving haproxy-devel to haproxy13
creating haproxy14 and an haproxy15-devel (when time will come)
should be a solution.

For now, I think the best idea is to open a pr and see
what FreeBSD ports teem think about it.


Cheers,

Joris