[PATCH] help coverity to detect BUG_ON as a real stop
Hello,,
I added DEBUG_STRICT=1 to coverity build definition.
hopefully, it will resolve 1 coverity issue.
Cheers,
Ilya Shipitcin
From ab5ab86b0398eb063f3d6ee392207b0238e9e083 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Fri, 9 Oct 2020 03:05:11 +0500
Subject: [PATCH] CI: travis-ci: help Coverity to detect BUG_ON() as a real
stop
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index a8aaccba5..e73d40c33 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -55,7 +55,7 @@ matrix:
- os: linux
if: type == cron
compiler: clang
-env: TARGET=linux-glibc COVERITY_SCAN_PROJECT_NAME="Haproxy" COVERITY_SCAN_BRANCH_PATTERN="*" COVERITY_SCAN_NOTIFICATION_EMAIL="chipits...@gmail.com" COVERITY_SCAN_BUILD_COMMAND="make CC=clang DEFINE=-DDEBUG_USE_ABORT TARGET=$TARGET $FLAGS 51DEGREES_SRC=$FIFTYONEDEGREES_SRC"
+env: TARGET=linux-glibc COVERITY_SCAN_PROJECT_NAME="Haproxy" COVERITY_SCAN_BRANCH_PATTERN="*" COVERITY_SCAN_NOTIFICATION_EMAIL="chipits...@gmail.com" COVERITY_SCAN_BUILD_COMMAND="make CC=clang DEFINE=-DDEBUG_USE_ABORT TARGET=$TARGET $FLAGS 51DEGREES_SRC=$FIFTYONEDEGREES_SRC DEBUG_STRICT=1"
script:
- |
if [ ! -z ${COVERITY_SCAN_TOKEN+x} ]; then
--
2.26.2
[PATCH] BUILD: makefile: Update feature flags for NetBSD
This updates the feature flags for NetBSD. NetBSD 8 adds support for accept4(). Enable getaddrinfo(). diff --git a/INSTALL b/INSTALL index 0263cf34c..2ae98bf6b 100644 --- a/INSTALL +++ b/INSTALL @@ -377,7 +377,7 @@ and assign it to the TARGET variable : - solaris for Solaris 10 and above - freebsd for FreeBSD 10 and above - dragonfly for DragonFlyBSD 4.3 and above - - netbsd for NetBSD + - netbsd for NetBSD 8 and above - osx for Mac OS/X - openbsd for OpenBSD 6.3 and above - aix51 for AIX 5.1 diff --git a/Makefile b/Makefile index 4aabe34dc..1c64593d0 100644 --- a/Makefile +++ b/Makefile @@ -393,10 +393,11 @@ ifeq ($(TARGET),openbsd) USE_GETADDRINFO) endif -# NetBSD +# NetBSD 8 and above ifeq ($(TARGET),netbsd) set_target_defaults = $(call default_opts, \ -USE_POLL USE_TPROXY USE_KQUEUE) +USE_POLL USE_TPROXY USE_THREAD USE_KQUEUE USE_ACCEPT4 USE_CLOSEFROM \ +USE_GETADDRINFO) endif # AIX 5.1 only
Re: [PATCH] BUILD: Add a DragonFlyBSD target
On Thu, Oct 08, 2020 at 01:15:06AM -0400, Brad Smith wrote: > Add a target for DragonFlyBSD 4.3 and above. Applied, thank you Brad! Willy
[PATCH] DOC: Add missing stats fields in the management doc
Added latest fields: idle_conn_cur, safe_conn_cur, used_conn_cur, need_conn_est --- doc/management.txt | 4 1 file changed, 4 insertions(+) diff --git a/doc/management.txt b/doc/management.txt index eef05b0fc..9fd7e6c03 100644 --- a/doc/management.txt +++ b/doc/management.txt @@ -1127,6 +1127,10 @@ Here is the list of static fields using the proxy statistics domain: 92. rtime_max [..BS]: the maximum observed response time in ms (0 for TCP) 93. ttime_max [..BS]: the maximum observed total session time in ms 94. eint [LFBS]: cumulative number of internal errors + 95. idle_conn_cur [...S]: current number of unsafe idle connections + 96. safe_conn_cur [...S]: current number of safe idle connections + 97. used_conn_cur [...S]: current number of connections in use + 98. need_conn_est [...S]: estimated needed number of connections For all other statistics domains, the presence or the order of the fields are not guaranteed. In this case, the header line should always be used to parse -- 2.28.0
Re: Alternatives to PayPal
Thanks Willy, it makes perfect sense. I'll sponsor other projects! :) Cheers, ~Nico On 08 Oct, Willy Tarreau wrote: > Hi, > > On Wed, Oct 07, 2020 at 11:20:25AM +0200, Sebastian Fohler wrote: > > What about a Patron account. > > > > https://www.patreon.com/europe > > > > Cause I already asked multiple times for some other means of contribution as > > well. > > That would help a great deal, makeing it easier. > > I'm supporting multiple Opensource projects already this way. > > Would that be an option? > > Well, to make things clear, first let me remind that the paypal account > is my personal account, which I have added a link to from the main page > upon request by several people willing to donate many years ago. This > has been helpful in the early days, allowing me buy some hardware to > experiment during week-ends (such as the 10G lab), and to significantly > improve the code's portability and efficiency on small systems. It used > to serve to contribute to the hosting costs as well. > > Since then the project has considerably evolved, being backed by a company > offering a much larger full-time development team. And users are well > aware of this because nowadays donations are extremely rare (in the range > of tens of dollars a year). But at the same time nowadays I do not need > them at all anymore, so I'm perfectly fine with replacing the link with > anything else. I've only been keeping it because I know that if I remove > it, the question will come back again a few months later. > > The only thing is that I am *not* going to deal with yet another task > that adds more burden, so if someone is willing to set up any account > via $whatever company, they will have to handle it and pass me the > replacement link. At least the paypal link doesn't cause me any extra > work beyond replying "thank you" to donators once in a while. Just be > aware that since donations are rare, I'm not at all convinced it will > be worth doing anything particular. And at some point a solution will > have to be found to spend the eventual money that would land there, > so someone will have to handle this, and again it's certainly not me. > > My personal suggestion would be that those who want to give a few > dollars better keep their money that they certainly need more than > most developers or contributors do, because due to the project's > nature, contributors generaly work in IT at levels at which, based on > the high quality of their contributions, they're not expected to be > starving at all (or if they do they definitely need to switch jobs as > their skills are quite sought)! If anyone is ever willing to spend a > large amount, like thousands of dollars, better hire someone to develop > some useful desired features, it will be an excellent contribution to > the project! Another great option is to contact your favorite distro's > package maintainer and propose your donation there, because distro > maintainers have been doing this thankless job for many years now and > deserve some recognition as well. For anything else, offering time to > look into bugs, testing -dev releases, improving the doc, contributing > to the wiki etc is extremely valuable and helps all contributors at > once. > > As you see, there are still plenty of options which do not require > managing any new account anywhere. > > Thanks for your support :-) > Willy > -- ~Nico
