[squid-dev] Idea: what if SBuf was a Packable?

[Francesco Chemolli]

Hi all,
  I spent some time wondering whether we could reduce
code duplication by making SBuf implement the Packable interface,
and replacing SBufStream with PackableStream.

The interface changes seem rather minimal, SBuf already implements
append(const char*, int) and vappendf; the main difference there is
that SBuf returns *this.
These methods are of course virtual, which is a price to pay, but besides
the vtbl size, maybe there is a way to not pay their cost when not used

What do you think?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] RFC: ACL clashes with Windows system entity

[Francesco Chemolli]

Hi all,
  I'm looking at improving windows portability, and we have a name clash
with a Windows system header (
https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-acl)

So.. how to deal with it?
I can see two options: either we lift ACL into the Acl namespace, or we
need to rename it. ACL is referenced in 106 files, so the change is going
to be big, so I ask if there are any opinions on how to go about this

Thanks,

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] mirrors with missing files

[Francesco Chemolli]

Hi all,
I agree, it would be awesome to rely on a more more than delivery network
for our website.
At this time it is complicated. Oh website is large as a result of posting
mailing list, archives and a lot of release files, patches, change sets.
Before we can migrate to anything different, we need to deprecate, cleanup
and simplify a lot.
Any help would be greatly appreciated

@mobile


On Tue, 31 Oct 2023 at 19:32, Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2023-10-31 06:08, Adam Majer wrote:
> > I've looked at the mirrors posted,
> >
> >http://www.squid-cache.org/Download/mirrors.html
> >
> > and these seem all obsolete.
>
> Thank you for doing this analysis! I have been begging the Project to
> drop all mirrors for a long time now. I failed to convince others that
> the associated embarrassment and waste of time are just not worth the
> benefits. Maybe your observations will be the last straw...
>
>
> > I'm not sure, but maybe a more reliable way would be to migrate to
> > github.com for the releases.
>
> FWIW, I am quite sure, and has been making that suggestion for several
> years now. GitHub is far from perfect, but using its release posting
> features (correctly) will dramatically decrease our release overheads
> and delays. This migration is not trivial, and I have failed to convince
> others that it is worth their time to start migrating.
>
> Alex.
>
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-dev
>
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] RFC: make FOLLOW_X_FORWARDED_FOR unconditional

[Francesco Chemolli]

Hi all,
   what if we removed the configure option for FOLLOW_X_FORWARDED_FOR, and
made it unconditionally part of Squid?

It is on by default, and it is controlled by runtime configuration,
removing the compile-time option would ensure we have better testing
coverage.

What do you think?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] RFC: Transitioning ipcache and fqdncache to ClpMap

[Francesco Chemolli]

Hi all,
   I'd like to start working on transitioning ipcache and fqdncache to
ClpMap .
There is only one snag, that I would like to build consensus on before
starting coding: the current configuration directives specify a cache size
in number of entries, where ClpMap specifies a max size.

I can see two ways forward:
1. Add a second max-size parameter to ClpMap, ensuring that it starts
expunging entries when the maximum capacity in either memory use or number
of entries is reached
2. guesstimate how many bytes of memory an ipcache/fqdncache uses, and
convert

Regardless, I believe that from the user-facing perspective, a solid way
forward is to give to the ipcache_size and fqdncache_size directives an
option to specify a max size in entries or, by adding a memory-size suffix,
in used memory, and possibly deprecate the max-size-in-entries option in
Squid 7 and retire it in squid 8.

Thoughts?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] CI: trunk is stable again

[Francesco Chemolli]

Hi all,
   trunk build tests can now be relied upon again for correctness checks.
We can set them up again as required for merging PRs

-- 
Francesco Chemolli
Squid Software Foundation
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Opensuse tumblweed woes

[Francesco Chemolli]

Hi all,
  I'm disabling opensuse tumbleweed from all our test build jobs; in their
current setup all builds are failing with an error in the linker for
undefined references to just about everything (see
https://build.squid-cache.org/job/trunk-amd64-matrix/COMPILER=gcc,CPU=amd64,OS=opensuse-tumbleweed,force_on_docker_arm64=docker-build-host-lowpri/438/console)
.
I've tried figuring out what's wrong but failed miserably.

If anyone has managed to get a full build on OpenSUSE tumbleweed recently -
or will manage to in the future - please get in touch with me so that I can
adopt their solution. Thanks!

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Latest Clang build errors

[Francesco Chemolli]

>
>
> BTW, since GCC v13 has other bugs and has not been officially "released"
> yet, I suggest removing that compiler from the set of required tests
> until it matures enough for us to support it efficiently.
>

That's what Fedora Rawhide ships as default compiler.
We can only do that by stopping to target rawhide for our tests; we can do
that of course but I'd like to get more feedback before doing so.

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Latest Clang build errors

[Francesco Chemolli]

Hi all,
  that is not just with clang:
https://build.squid-cache.org/job/trunk-amd64-matrix/COMPILER=gcc,CPU=amd64,OS=fedora-rawhide,force_on_docker_arm64=docker-build-host-lowpri/434/console
shows the error on gcc 13.

I recall a conversation where Alex showed it to be a compiler issue, but I
can't find it now.

On Tue, Mar 28, 2023 at 2:27 PM Amos Jeffries  wrote:

> Alex, since the whole IPC and SHM system is your design are you able to
> work on fixing the FlexibleArray build errors we are now getting with
> clang v15.
>
> IIRC FlexibleArray was a placeholder for std::dynarray, which is now
> officially dead. So if we can do an implementation which uses more
> standard behaviour it would be better.
>
> Cheers
> Amos
>
>
> [1] Log excerpt from Jenkins:
>
> 01:00:06 In file included from ../../../../src/ipc/StoreMap.h:12,
> 01:00:06  from ../../../../src/fs/rock/RockRebuild.h:17,
> 01:00:06  from ../../../../src/fs/rock/RockRebuild.cc:15:
> 01:00:06 In member function 'Item&
> Ipc::Mem::FlexibleArray::operator[](int) [with Item = long
> unsigned int]',
> 01:00:06 inlined from 'Ipc::StoreMapItems::Item&
> Ipc::StoreMapItems::at(int) [with C = long unsigned int]' at
> ../../../../src/ipc/StoreMap.h:136:21,
> 01:00:06 inlined from 'Rock::LoadingEntry::LoadingEntry(sfileno,
> Rock::LoadingParts&)' at ../../../../src/fs/rock/RockRebuild.cc:199:27:
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h:34:52: error: array
> subscript -1 is below array bounds of 'long unsigned int [1]'
> [-Werror=array-bounds=]
> 01:00:0634 | Item  [](const int idx) { return items[idx];
> }
> 01:00:06   | ~^
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h: In constructor
> 'Rock::LoadingEntry::LoadingEntry(sfileno, Rock::LoadingParts&)':
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h:43:10: note: while
> referencing 'Ipc::Mem::FlexibleArray::items'
> 01:00:0643 | Item items[1]; // ensures proper alignment of array
> elements
> 01:00:06   |  ^
> 01:00:06 In member function 'Item&
> Ipc::Mem::FlexibleArray::operator[](int) [with Item = unsigned int]',
> 01:00:06 inlined from 'Ipc::StoreMapItems::Item&
> Ipc::StoreMapItems::at(int) [with C = unsigned int]' at
> ../../../../src/ipc/StoreMap.h:136:21,
> 01:00:06 inlined from 'Rock::LoadingEntry::LoadingEntry(sfileno,
> Rock::LoadingParts&)' at ../../../../src/fs/rock/RockRebuild.cc:200:33:
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h:34:52: error: array
> subscript -1 is below array bounds of 'unsigned int [1]'
> [-Werror=array-bounds=]
> 01:00:0634 | Item  [](const int idx) { return items[idx];
> }
> 01:00:06   | ~^
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h: In constructor
> 'Rock::LoadingEntry::LoadingEntry(sfileno, Rock::LoadingParts&)':
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h:43:10: note: while
> referencing 'Ipc::Mem::FlexibleArray::items'
> 01:00:0643 | Item items[1]; // ensures proper alignment of array
> elements
> 01:00:06   |  ^
> 01:00:06 In member function 'Item&
> Ipc::Mem::FlexibleArray::operator[](int) [with Item = int]',
> 01:00:06 inlined from 'Ipc::StoreMapItems::Item&
> Ipc::StoreMapItems::at(int) [with C = int]' at
> ../../../../src/ipc/StoreMap.h:136:21,
> 01:00:06 inlined from 'Rock::LoadingSlot::LoadingSlot(Rock::SlotId,
> Rock::LoadingParts&)' at ../../../../src/fs/rock/RockRebuild.cc:208:27:
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h:34:52: error: array
> subscript -1 is below array bounds of 'int [1]' [-Werror=array-bounds=]
> 01:00:0634 | Item  [](const int idx) { return items[idx];
> }
> 01:00:06   | ~^
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h: In constructor
> 'Rock::LoadingSlot::LoadingSlot(Rock::SlotId, Rock::LoadingParts&)':
> 01:00:06 ../../../../src/ipc/mem/FlexibleArray.h:43:10: note: while
> referencing 'Ipc::Mem::FlexibleArray::items'
> 01:00:0643 | Item items[1]; // ensures proper alignment of array
> elements
> 01:00:06   |  ^
> 01:00:06 cc1plus: all warnings being treated as errors
> 01:00:06 make[4]: *** [Makefile:986: rock/RockRebuild.lo] Error 1
> 01:00:06 make[4]: Leaving directory
>
> '/srv/jenkins/workspace/5-pr-test/COMPILER/gcc/OS/fedora-rawhide/label/docker-build-host/btlayer-02-maximus/squid-7.0.0-VCS/_build/sub/src/fs'
>
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC: policy change for header #includes

[Francesco Chemolli]

I like this idea; I would also complement it with the directive to use
header  instead of  whenever possible - this could also be
automatically enforced

On Tue, Mar 7, 2023 at 5:38 AM Amos Jeffries  wrote:

>
> Current Policy
> <
> https://wiki.squid-cache.org/DeveloperResources/SquidCodingGuidelines#file-include-guidelines
> >:
> "
>   4. system C headers (with a .h suffix):
>  * mandatory HAVE_FOO_H wrapper
> "
>
>
> I propose using the C++17 "__has_include()" instead of HAVE_FOO_H
> whenever we can. Which is:
>   * all .cc and .cci files
>   * any .h files in the src/ and tools/ areas
>
>
> Pros:
>   * less configure.ac logic, smaller build logs
>   * removes need to do a full bootstrap + re-configure when a
> third-party library or system header is added/remove/changed
>   * conversion can be semi-scripted
>
> Cons AFAIK are all about how it cannot be a blanket requirement like
> HAVE_FOO_H is:
>   * sometimes headers need to be forbidden include by ./configure logic
> checks
>   * C language does not support the __has_include
>
>
> Cheers
> Amos
>
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC: Switch to C++17

[Francesco Chemolli]

I support the switch

On Sun, 4 Dec 2022 at 16:18, Alex Rousskov 
wrote:

> Hello,
>
>  I propose that we switch master/v6 from C++11 to C++17: Modern
> environments support C++17 well. We are wasting significant amounts of
> time on emulating such basic C++17 features as std::optional. We are
> writing worse code than we can because we lack access to such basic
> C++14 and C++17 features as
>
> * function return type deduction (auto)
> * generic lambdas (auto arguments)
> * relaxed constexpr restrictions
> * std::make_unique
> * std::integer_sequence
> * std::quoted
> * Nested namespace definitions
> * [[fallthrough]], [[maybe_unused]], and [[nodiscard]]
> * fold expressions
> * auto [a, b] = getTwoReturnValues();
> * inline variables
> * std::any
> * std::variant
> * std::byte
>
> If we do not switch now, then we would have to wait about a year for the
> next such opportunity because we should not introduce such a big
> difference between master and the upcoming unstable v6 branch.
>
>
> C++17 is supported by popular modern compilers and stable distros. Squid
> master branch should target those IMO. Even old environments can install
> the necessary modern compilers (e.g., RHEL5 users can get them via Red
> Hat Developer Toolset).
>
> * GCC v5 supports most C++17 features.
> * GCC v8 supports all relevant C++17 features.
> * Clang v5 supports nearly all C++17 features.
> * Clang v8 supports all relevant C++17 features.
>
> * Ubuntu 20.04 LTS ships with GCC v9 and clang v10.
>
> * https://gcc.gnu.org/projects/cxx-status.html#cxx17
> *
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017
> * https://clang.llvm.org/cxx_status.html#cxx17
> * https://en.cppreference.com/w/cpp/compiler_support/17
>
>
> Switching to just C++14 would be better than nothing, but it will not
> give us several C++17 features that we already waste serious time on
> emulating/avoiding (e.g., std::optional). We should not switch to C++20
> yet because modern stable compilers still have some C++20 support holes.
>
>
> I can volunteer the corresponding PR.
>
>
> Any objections to switching master/v6 to C++17?
>
>
> Thank you,
>
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>
-- 
@mobile
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC: Semaphore CI to GitHub Actions migration

[Francesco Chemolli]

Hi Alex,
   this all sounds sensible to me and in general a good idea

On Wed, Oct 19, 2022 at 3:25 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> Hello,
>
>  I plan to gradually turn Semaphore CI testing off and make GitHub
> Actions required. We should not babysit the same tests in two setups.
> Here is the current status of CI tests with regard to Semaphore and
> GitHub Actions together with the corresponding planned actions:
>
> 1. Functionality tests: Essentially the same set of tests. Semaphore CI
> has one extra/old test but it is disabled for master/v6 code. The
> proxy-collapsed-forwarding test often fails on Semaphore, requiring a
> manual restart of all tests. The busy-restart test usually fails on
> GitHub Actions, but those failures are currently ignored.
>
> Plan: I will leave the busy-restart test running on Semaphore CI until
> we find a way to make it stable in GitHub Actions environment. I will
> turn off the other Semaphore CI functionality tests and make the GitHub
> Actions ones required.
>
>
> 2. Source maintenance tests: The same set of tests. GitHub Actions have
> the right Astyle version, so the formatting test actually works on
> GitHub (but its results are currently ignored on both platforms).
>
> Plan: I will turn off Semaphore CI source maintenance tests and make the
> GitHub Actions ones required instead. Formatting test results will still
> be ignored (that is a separate decision/change/action out of this thread
> scope; let's not discuss it here).
>
>
> 3. Build tests: Semaphore CI uses Ubuntu 14.04. GitHub Actions uses
> Ubuntu 22.04. Semaphore CI has fewer build dependencies installed.
> GitHub Actions do not provide Ubuntu 14.04 runners[1].
>
> Plan: I will keep Semaphore CI build tests and make the GitHub Actions
> tests required. When Semaphore CI build tests start failing (e.g.,
> because dependency repositories stop working "as is"), or when we stop
> supporting that old environment, I will disable those tests.
>
>
> If you have any objections or better ideas about gradually moving away
> from Semaphore CI, please discuss.
>
>
> Thank you,
>
> Alex.
>
> [1]  GitHub provides Ubuntu 18.04 runners, but they are deprecated, will
> purposefully _fail_ according to GitHub schedule, and will be removed in
> December. We should not use them. Details at
>
> https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Proposal: switch to always-build for some currently optional features

[Francesco Chemolli]

>
>
> I agree that modules that can always be built, should be. Such modules
> should have no guarding #ifdefs. I think this is the set of modules that
> your proposal is targeting, but please correct me if I am wrong. FWIW,
> this design stems from an even more general/fundamental rule of thumb:
> Do not add unnecessary #ifdefs.
>

I agree. We could also work on better isolation, by restricting
#ifdef-guarded areas
to specific delegate classes, and then using c++ features (e.g. if
constexpr, eventually) to
disable the callsites.


> However, there is a precondition: Any always-built optional feature with
> a potentially significant performance impact or a controversial side
> effect should be disabled by default (via squid.conf). Satisfying this
> precondition will require code changes.
>

Yes, I agree.

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Proposal: switch to always-build for some currently optional features

[Francesco Chemolli]

Hi all,
   there is a bunch of features that are currently gated at compile time:
among others, I see:
- adaptation (icap, ecap)
- authentication
- ident
- delay pools
- cache digests
- htcp
- cache digests
- wccp
- unlinkd

I'd like to propose that we switch to always-build them.
We would gain:
- code clarity
- ease of development
- test coverage
- feature uniformity across builds

We would lose:
- slightly longer build time
- larger binaries

The latter should not be an issue anymore, even the most embedded of
embedded systems Squid is likely to be used on has plenty of storage and
core, and the former should not be too big a deal

Opinions?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] IPv6 Proxy (RTC leak)

[Francesco Chemolli]

Hi Leandro,
  have you followed the instructions in
https://wiki.squid-cache.org/SquidFaq/ConfiguringSquid#Can_Squid_anonymize_HTTP_requests.3F
?


On Sun, Sep 11, 2022 at 10:33 PM Leandro de França 
wrote:

> Hello, my name is Leandro de França!
> I am using Squid to configure an IPv4 (incoming) Proxy server > IPv6
> (outgoing).
> I'm facing a problem with an RTC leak, where a speed test is identifying
> the IPv4 of the local machine.
>
> Is there any solution to this problem?
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] squid website certificate error

[Francesco Chemolli]

The squid website is not supposed to be over https, because it’s served by
multiple mirrors not necessarily under the project’s control.
We have some ideas on how to change this but need the developer time to do
it.
Help is welcome :)

On Mon, 29 Aug 2022 at 15:25, Marcus Kool 
wrote:

> Has anybody already complained that the certificates for squid-cache.org
> and www.squid-cache.org are messed up?
>
> Marcus
>
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>
-- 
@mobile
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC submodule repositories

[Francesco Chemolli]

>
>
> ( So every change to Squid has to be justified as an optimization now.
> Right... )
>

My experience with submodules is not great; I often ended up with detached
sub-branches that were a pain to deal with. Given that, I am trying to
understand if it's worth it, that's all. As opposed to, say, looking for a
way to installing the bits that are essential to building helpers in some
sort of squid-dev package, so we can just spin off completely those helpers
we don't want to maintain


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC submodule repositories

[Francesco Chemolli]

Hi,
  I second Alex' view point, I don't have a clear understanding about what
is the benefit that you're trying to obtain.

On Sun, Jul 31, 2022 at 4:09 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 7/31/22 00:29, Amos Jeffries wrote:
> > When PR #937 merges we will have the ability to shuffle old helpers into
> > a separate repository that users can import as a submodule to build with
> > their Squid as-needed.
>
> In my experience, git submodules are a powerful feature that is rather
> difficult to use correctly. Some of submodule aspects do not feel
> "natural" to many humans. I am pretty sure that proper introduction of
> submodules will require a lot of our time and nerve cells. What will we
> optimize by introducing such a significant complication as git submodules?
>
>
> > What (if any) updates do we need to make to Anubis and other
> > infrastructure so support git submodules ?
>
> That answer probably depends, in part, on what support guarantees we are
> going to issue for those submodules and on what our submodule update
> policy will be. Integrating two or more git repositories together is a
> complicated issue...
>
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Errors while building 5.6 on Ubuntu 22.04

[Francesco Chemolli]

OpenSSL 3.0 support has landed in trunk yesterday. Hopefully there will be
a point release with it any day now

On Mon, Jul 18, 2022 at 9:52 AM  wrote:

> Hey Everybody,
>
>
>
> I have just started my build tests on Ubuntu 22.04  and I got some
> errors, something with OpenSSL 3.0.
>
> I have seen that there has been a patch for 5.5 in Debian at:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005650
>
>
>
>
>
> but I have not see such a fix from the squid project.
>
> Is there any usable patch I can try to apply to build and fix it?
>
>
>
> The build errors:
>
> ### START
>
> ibtool: compile:  g++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\"/etc/squid/
> squid.conf\" -DDEFAULT_SQUID_DATA_DIR=\"/usr/share/squid\"
> -DDEFAULT_SQUID_CONFIG_DIR=\"/etc/squid\" -I/home/builder/squid-5.6
> -I/home/builder/squid-5.6/include -I/home/builder/squid-5.6/lib
> -I/home/builder/squid-5.6/src -I../../include -isystem /usr/include/mit-krb5
> -I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -
> Wshadow -Woverloaded-virtual -Werror -pipe -D_REENTRANT -I/usr/include/libxml2
> -m64 -I/usr/include/p11-kit-1 -g -O2 -MT old_api.lo -MD -MP -MF .deps/
> old_api.Tpo -c /home/builder/squid-5.6/src/mem/old_api.cc  -fPIC -DPIC -o
> .libs/old_api.o
>
> In file included from /home/builder/squid-5.6/src/security/Session.h:14,
>
>  from /home/builder/squid-5.6/src/security/forward.h:15,
>
>  from /home/builder/squid-5.6/src/SquidConfig.h:26,
>
>  from /home/builder/squid-5.6/src/mem/old_api.cc:24:
>
> /home/builder/squid-5.6/src/security/forward.h: In function 'void
> Security::DH_free_cpp(DH*)':
>
> /home/builder/squid-5.6/src/security/LockingPointer.h:34:21: error: 'void
> DH_free(DH*)' is deprecated: Since OpenSSL 3.0 [-Werror
> =deprecated-declarations]
>
>34 | function(a); \
>
> /home/builder/squid-5.6/src/security/forward.h:96:1: note: in expansion
> of macro 'CtoCpp1'
>
>96 | CtoCpp1(DH_free, DH *);
>
>   | ^~~
>
> In file included from /home/builder/squid-5.6/compat/openssl.h:35,
>
>  from /home/builder/squid-5.6/src/security/Context.h:15,
>
>  from /home/builder/squid-5.6/src/security/forward.h:14,
>
>  from /home/builder/squid-5.6/src/SquidConfig.h:26,
>
>  from /home/builder/squid-5.6/src/mem/old_api.cc:24:
>
> /usr/include/openssl/dh.h:200:28: note: declared here
>
>   200 | OSSL_DEPRECATEDIN_3_0 void DH_free(DH *dh);
>
>   |^~~
>
> In file included from /home/builder/squid-5.6/src/SquidConfig.h:26,
>
>  from /home/builder/squid-5.6/src/mem/old_api.cc:24:
>
> /home/builder/squid-5.6/src/security/forward.h: At global scope:
>
> /home/builder/squid-5.6/src/security/forward.h:97:70: error: 'int
> DH_up_ref(DH*)' is deprecated: Since OpenSSL 3.0 [-Werror
> =deprecated-declarations]
>
>97 | typedef Security::LockingPointer *, DH_up_ref> > DhePointer;
>
>   |
> ^
>
> In file included from /home/builder/squid-5.6/compat/openssl.h:35,
>
>  from /home/builder/squid-5.6/src/security/Context.h:15,
>
>  from /home/builder/squid-5.6/src/security/forward.h:14,
>
>  from /home/builder/squid-5.6/src/SquidConfig.h:26,
>
>  from /home/builder/squid-5.6/src/mem/old_api.cc:24:
>
> /usr/include/openssl/dh.h:201:27: note: declared here
>
>   201 | OSSL_DEPRECATEDIN_3_0 int DH_up_ref(DH *dh);
>
>   |   ^
>
> In file included from /home/builder/squid-5.6/src/SquidConfig.h:26,
>
>  from /home/builder/squid-5.6/src/mem/old_api.cc:24:
>
> /home/builder/squid-5.6/src/security/forward.h:97:79: error: 'int
> DH_up_ref(DH*)' is deprecated: Since OpenSSL 3.0 [-Werror
> =deprecated-declarations]
>
>97 | typedef Security::LockingPointer *, DH_up_ref> > DhePointer;
>
>   |
> ^
>
> In file included from /home/builder/squid-5.6/compat/openssl.h:35,
>
>  from /home/builder/squid-5.6/src/security/Context.h:15,
>
>  from /home/builder/squid-5.6/src/security/forward.h:14,
>
>  from /home/builder/squid-5.6/src/SquidConfig.h:26,
>
>  from /home/builder/squid-5.6/src/mem/old_api.cc:24:
>
> /usr/include/openssl/dh.h:201:27: note: declared here
>
>   201 | OSSL_DEPRECATEDIN_3_0 int DH_up_ref(DH *dh);
>
>   |   ^
>
> In file included from /home/builder/squid-5.6/src/ssl/support.h:21,
>
>  from /home/builder/squid-5.6/src/SquidConfig.h:29,
>
>  from /home/builder/squid-5.6/src/mem/old_api.cc:24:
>
> /home/builder/squid-5.6/src/ssl/gadgets.h:61:51: error: 'void RSA_free(RSA*)'
> is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
>
>61 | typedef std::unique_ptr>
> RSA_Pointer;
>
>   |   ^~~~
>
> In file included from 

Re: [squid-dev] bugzilla issue

[Francesco Chemolli]

Hi Adam,
  thanks for letting me know.
It's now fixed.

On Fri, Jul 15, 2022 at 9:46 AM Adam Majer  wrote:

> When going to bugs.squid-cache.org, I get a message that MySQL DB is not
> accessible. And since there is no notification address on that page,
> forwarding here.
>
> - Adam
>
>
>
> Software error:
>
> Can't connect to the database.
> Error: Can't connect to MySQL server on 'db:3306' (111)
>Is your database installed and up and running?
>Do you have the correct username and password selected in localconfig?
>
> For help, please send mail to the webmaster ([no address given]), giving
> this error message and the time and date of the error.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Squid + docker multi-distro test builds script

[Francesco Chemolli]

Hi all,
   in order to facilitate multiplatform (at least on Linux) development
velocity, let me share a script I use for this purpose. It is based on the
same tech we run our CI farm on.

the script is at
https://github.com/kinkie/support-tools/blob/master/squid-build/do-build

It's reasonably well documented via the standard --help mechanism. It's
meant ot be run a Linux system with docker.

The main convenience argument is "--in "

$ do-build --in debian-stable --all

will - as you may guess - run a bootstrap/configure/build/test cycle in the
current working directory in a debian-stable runtime environment.

I hope this helps others increase their velocity on multi
multi-distribution development. Please keep in mind I make no promises on
this script - I occasionally tinker with it and it may break.
Feedback is welcome

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC: Class section/member _order_

[Francesco Chemolli]

Hi,
  I generally agree on the proposal. Any difference in opinion I have  is
trivial and not worth discussing

Regarding the ML filter, thanks for letting me know. I’ll have to figure
out what keyword triggered the anti spam filter

Francesco

On Thu, 23 Jun 2022 at 15:37, Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> Hello,
>
>  Amos and I disagreed[1] regarding the existing guidelines for
> section/member order in C++ class declarations. To resolve that
> disagreement, this email proposes the order for future use.
>
> -
>
> 1. Class "sections" order (by member access specifiers): public,
> protected, private. Each section, if present, declared once. Omit
> sections that would be empty. Rationale: List most commonly reused, most
> important things fist. In this context, those are public class
> interfaces. The private section is the least important implementation
> detail as far as the notion of a C++ class is concerned.
>
>
> 2. Within each section, the recommended member order is defined below.
> Rationale: Group similar things together to facilitate searching and
> highlight differences. List things most likely to be reused (by other
> class members) and most important/influential things higher.
>
> * friendship declarations
> * type and aliases declarations; nested classes/structs/unions
> * static member functions
> * constructors and assignment operators
> * destructors (just one until C++20)
> * other/regular non-static member functions except overrides
> * overrides (see item 3 below)
> * static data members
> * non-static data members
>
>
> 3. Overrides are a special case where we do not expect member
> descriptions but do expect a reference to the corresponding API as
> sketched below. Overrides are grouped by the (direct or indirect) parent
> that _introduced_ the corresponding API method(s) (i.e. the parent class
> that declared the virtual method but could _not_ use an override keyword
> in that declaration). Rationale: Provide API context and facilitate
> searching for member descriptions without chasing overrides through
> parents.
>
>  /* Baz API */
>  overrides for Baz-introduced methods (excluding destructors)
>
>  /* Bar API */
>  overrides for Bar-introduced methods (excluding destructors)
>
>
> 4. Caveats
>
> The above rules are not meant to force authors to include any access
> specifiers or members that the code does not actually need (except the
> "private" specifier should be mentioned explicitly in class declarations
> that have only private members -- do not rely on the class default
> access specifier being "private").
>
> Squid has some legacy code that forces CBDATA-related declarations to be
> hoisted to the very top of the class, into the "unnamed" section. This
> is an exception to the above rules. Eventually, we will stop doing that,
> but we should continue doing that for consistency sake until the
> offending CBDATA macros are gone.
>
> Like any style rules, these rules are not comprehensive. If your use
> case is not explicitly covered, then look around for similar Squid code
> and try to be consistent and/or reasonable.
>
> -
>
> Most of the above rules are arbitrary but common in the industry[2,3].
>
> [1] https://github.com/squid-cache/squid/pull/1067#discussion_r889864925
> [2] https://stackoverflow.com/q/308581
> [3] https://google.github.io/styleguide/cppguide.html#Declaration_Order
>
>
> HTH,
>
> Alex.
> P.S. This is my Nth attempt to get through the mailing list filter. You
> may have received a pretty much the same message as an attachment to the
> previous mailing list post. Sorry about the noise!
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>
-- 
@mobile
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] PR backlog

[Francesco Chemolli]

On Wed, Jun 8, 2022 at 2:39 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 6/7/22 17:53, Francesco Chemolli wrote:
> > This is exactly what I meant and what I see happening.
> > I'd like us to concentrate on clearing as much as possible the PR
> > backlog to capitalise on the work many have put in there, prioritising
> > that over new feature work for a few days.
>
> I am not sure, but I sense that you are not satisfied with the list of
> the PRs that I said I am working on. If that is the case, you may want
> to clarify what you think I should be doing instead. FWIW, I thought
> that working on the listed PRs will reduce the number of PRs and, hence,
> reduce "backlog of open PRs" which, I thought, was what your 15-day
> sprint suggestion was about...
>

No, I am very happy about the sprint we are doing.
My point is that that one PR has IMO a high level of urgency and I wanted
to highlight that.
This said, as we are a volunteer organisation, we do what we feel like and
there is nothing wrong with that


>
>  > Could we prioritise reviewing and merging PR#694?
>
> As you know, that is one of the PRs on top of my list. I do not think I
> can "prioritize" it any more than I already am. I even offered to
> implement some of the required changes! Again, if you think I should be
> doing something else instead, please discuss!
>

Sorry, I had failed to match that with the list. My bad, no need to change
anything

Thank you and Amos for responding to the call for action!

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] PR backlog

[Francesco Chemolli]

Could we prioritise reviewing and merging PR#694
<https://github.com/squid-cache/squid/pull/694>?
That's blocking us from starting to test on Fedora 36, Fedora Rawhide,
current Gentoo, current Opensuse tumbleweed, Debian unstable and Ubuntu
Jammy


On Tue, Jun 7, 2022 at 10:53 PM Francesco Chemolli 
wrote:

> This is exactly what I meant and what I see happening.
> I'd like us to concentrate on clearing as much as possible the PR backlog
> to capitalise on the work many have put in there, prioritising that over
> new feature work for a few days.
> The conversation has already picked up, that's great!
>
> On Mon, Jun 6, 2022 at 6:20 PM Alex Rousskov <
> rouss...@measurement-factory.com> wrote:
>
>> On 6/6/22 03:34, Francesco Chemolli wrote:
>>
>> > we have quite a big backlog of open PRs
>> > (https://github.com/squid-cache/squid/pulls?page=1=is%3Apr+is%3Aopen).
>> How
>> > about doing a 15-days sprint and clearing it or at least trimming it
>> > significantly?
>>
>> I am happy to participate in any way you find useful! Please let me know
>> how I can help.
>>
>> FWIW, I know of a handful of PRs that need my attention (e.g., #1067,
>> #980, #694, #755, #736). I am already working on some of them (and will
>> resume working on others ASAP).
>>
>> Alex.
>> ___
>> squid-dev mailing list
>> squid-dev@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-dev
>>
>
>
> --
> Francesco
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] PR backlog

[Francesco Chemolli]

This is exactly what I meant and what I see happening.
I'd like us to concentrate on clearing as much as possible the PR backlog
to capitalise on the work many have put in there, prioritising that over
new feature work for a few days.
The conversation has already picked up, that's great!

On Mon, Jun 6, 2022 at 6:20 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 6/6/22 03:34, Francesco Chemolli wrote:
>
> > we have quite a big backlog of open PRs
> > (https://github.com/squid-cache/squid/pulls?page=1=is%3Apr+is%3Aopen).
> How
> > about doing a 15-days sprint and clearing it or at least trimming it
> > significantly?
>
> I am happy to participate in any way you find useful! Please let me know
> how I can help.
>
> FWIW, I know of a handful of PRs that need my attention (e.g., #1067,
> #980, #694, #755, #736). I am already working on some of them (and will
> resume working on others ASAP).
>
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] PR backlog

[Francesco Chemolli]

Hi all,
   we have quite a big backlog of open PRs (
https://github.com/squid-cache/squid/pulls?page=1=is%3Apr+is%3Aopen). How
about doing a 15-days sprint and clearing it or at least trimming it
significantly?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Can't build on Ubuntu Jammy

[Francesco Chemolli]

Hi all,
  I did a trial build run on Jammy (
https://build.squid-cache.org/job/anybranch-anyarch-matrix/COMPILER=gcc,OS=ubuntu-jammy,label=amd64-linux/5/console);
it fails with

../../../../src/security/forward.h: In function 'void
Security::DH_free_cpp(DH*)':
../../../../src/security/LockingPointer.h:34:21: error: 'void
DH_free(DH*)' is deprecated: Since OpenSSL 3.0
[-Werror=deprecated-declarations]
   34 | function(a); \



-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] What os/cpu platforms do we want to target as a project?

[Francesco Chemolli]

On Sun, Dec 26, 2021 at 10:58 PM Alex Rousskov
 wrote:
>
> On 12/26/21 10:30 AM, Francesco Chemolli wrote:
> > On Sun, Dec 5, 2021 at 10:05 PM Alex Rousskov wrote:
> >> On 12/5/21 4:44 AM, Francesco Chemolli wrote:
> >>> I would recommend that we support as main targets:
> >>> - Linux on x64, arm64, arm32 and, if we can, MIPS
> >>> - FreeBSD, OpenBSD on x64
> >>
> >>> As best-effort:
> >>> - Windows on x64, with the aim of eventually promoting to primary target
> >>> - Darwin on x64 and maybe eventually arm64
> >>> - NetBSD on x64
> >>
> >> What does "support as main targets" and "support as best-effort" mean?
>
> > "main targets" to me means that any regression in build or unit tests
> > on these platforms is PR-blocking. We aim to deliver a working build
> > out of the box on these environments, with no need of maintainer
> > patches.
>
> I am OK with that definition if you remove "in build or unit tests". Any
> known Squid regression affecting the "main" environment should block the
> PR introducing that regression IMO. I see no need to limit this to
> "build and unit tests" regressions. Are you OK with that definition
> simplification?

Yes

> I do not think MIPS, FreeBSD, and OpenBSD should be on the "main" list:
> There are just too few users and contributors on those platforms right
> now to grant them primary status AFAICT. I may be missing some important
> signals, of course, but I would downgrade them to best-effort.

I'm okay with downgrading MIPS - it is present in the embedded space
but testing poses some challenges.
I'm a bit more reluctant with downgrading FreeBSD and (once stable)
OpenBSD. They ship Squid as part of their ports, and while the
developer community may not be very large, I'd expect the user
community to be a bit more prevalent. This would also prevent the risk
of the project becoming a Linux monoculture.

> I am not sure about arm32, for similar reasons, but perhaps there is a
> strong demand for "embedded" Squid that I do not know about (and that
> does not materialize in a stream of PRs because Squid already works well
> in those environments??)? How can we tell?

We can't, we have to guess. My angle on that is that having arm32 will
help us not become a 64-bit monoculture, which could bring in
regressions in low-level data structures. At this stage in the
embedded world, as far as I'm aware, there are x86-32, arm32, MIPS and
RISC-V. Of these arm32 is the most prevalent and therefore my
preferred choice. It also helps that we have a test environment for it
already, courtesy of a couple of raspberry pi 3.

> > Once achieved this status on any of these platforms,
> > regressions on it are release blockers.
>
> I do not know what you mean by "release" exactly, but we should not add
> rules that block schedule-based branching points and major releases[1].
> As for other/minor releases, I am not against this rule if the
> maintainer is happy about it.

Amos, what do you think?

>
> [1] https://wiki.squid-cache.org/ReleaseSchedule
>
>
>
> > "support as best effort" means that we keep these environment as build
> > options, and test builds on them. Regressions on build or unit tests
> > on these environments are not PR-blocking but we strongly encourage
> > the PR owner to fix these platforms with followup PRs. We aim to
> > deliver an out-of-the-box build on these platforms but failure to do
> > so or regressions are not a release blocker
>
> OK. If we drop the vague parts, "best effort" simply means that CI
> covers these platforms (but they are not "main" environments and, hence,
> the corresponding CI failures alone are not sufficient to block PRs).

Sounds good

> AFAICT, the primary costs of keeping a platform on a best-effort list
> are CI testing time and CI maintenance overheads. I suggest capping that
> best-effort list to keep the total CI test time for one PR commit under,
> say, 4 hours and granting CI maintenance team a veto on adding (but not
> removing) platforms. IIRC, we have discussed PR commit testing time a
> few months ago; if we agreed on another number of hours there, let's
> take that as a cap.

The best-effort model supports testing best-effort platforms
asynchronously, no need to cap there. Regressions would be noted and
hopefully dealt with in followup PRs. We are already using this
practice.

> >>> If anyone in the community wants to support/maintain extra OSes or
> >>> architectures, they're very welcome to do so
> >>
> >> By "welcome", do you mean something like "we w

Re: [squid-dev] What os/cpu platforms do we want to target as a project?

[Francesco Chemolli]

On Sun, Dec 5, 2021 at 10:05 PM Alex Rousskov
 wrote:
>
> On 12/5/21 4:44 AM, Francesco Chemolli wrote:
>
> > I would recommend that we support as main targets:
> > - Linux on x64, arm64, arm32 and, if we can, MIPS
> > - FreeBSD, OpenBSD on x64
>
> > As best-effort:
> > - Windows on x64, with the aim of eventually promoting to primary target
> > - Darwin on x64 and maybe eventually arm64
> > - NetBSD on x64
>
> What does "support as main targets" and "support as best-effort" mean?
>
> Without defining/detailing these two terms, it is impossible to properly
> evaluate this proposal IMO...

That's a very fair point.
"main targets" to me means that any regression in build or unit tests
on these platforms is PR-blocking. We aim to deliver a working build
out of the box on these environments, with no need of maintainer
patches. Once achieved this status on any of these platforms,
regressions on it are release blockers.
"support as best effort" means that we keep these environment as build
options, and test builds on them. Regressions on build or unit tests
on these environments are not PR-blocking but we strongly encourage
the PR owner to fix these platforms with followup PRs. We aim to
deliver an out-of-the-box build on these platforms but failure to do
so or regressions are not a release blocker


> > If anyone in the community wants to support/maintain extra OSes or
> > architectures, they're very welcome to do so
>
> By "welcome", do you mean something like "we will accept high-quality
> PRs adding such extra support to Squid"? Or "we will consider sharing
> references to your work, but please do not ask us to merge your
> OS-specific changes into the official Squid code"? Something else? This
> bit is critical for understanding the real effect of this proposal IMO.

Fair point. I'd go for the former. If someone has an environment they
want to support and do so without adding complexity to the code base,
it's a good policy to enable that. The question is "how much
complexity is it healthy to impose on other platforms to support
niche/obsolete ones?"
While setting an objective bar is hard to impossible, this is my
attempt to set one for the most active group of developers

> If we manage to and agree on what platforms to "support" and on removing
> code dedicated to unsupported platforms, great! If we fail, I would like
> to propose an alternative scheme for the removal of platform-specific
> (or any other) code from the official master branch:
>
> A PR dedicated to code removal can be merged if it satisfies the
> following criteria:
>
> 1. Two positive votes from core developers.
> 2. No negative votes.
> 3. Voting lasted for 30+ calendar days.
> 4. The removal PR is announced in a PR-dedicated squid-users post.
>This announcement resets the 30+ day timer.

How about instead something along the lines of:
1. announce on squid-users about intent to remove support for a platform
2. wait for objections for 15 days
3. PR following standard merge procedure

> The author and reviewers do not have to justify the removal and the
> votes if the PR author elects to use this special code removal
> procedure. We simply trust they have good reasons to remove, support
> removal, or block it.

My proposal doesn't change the merge process at all, it mostly gives
any active users in the candidate for removal a chance to speak up. I
think 15 days are a good window to not stall development too long, but
it can be extended if others feel we should


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] What os/cpu platforms do we want to target as a project?

[Francesco Chemolli]

Hi all,
  continuing the conversation from
https://github.com/squid-cache/squid/pull/942#issuecomment-986055422
to a bigger forum

The discussion started out of a number of PRs meant to remove explicit
support for obsolete platforms such as OSF/1, NeXT or old versions of
Solaris.

I that thread I move forward a list of platforms that in my opinion we
should as a project target, and while of course we should not
explicitly prevent other platforms from being built on, we should also
not disperse our time supporting complexity for the sake of other
os/cpu combos .

The rationale is that we should focus our attention as a project where
the majority of our userbase is, where users mean "people who build
and run squid".

We have no way of knowing who is installing squid, we don't have
telemetry, so we will need to do a bit of guesswork, based on the
assumption that people who deploy squid are rational; as a consequence
of that, we can assume that they will go for the solution that gives
them most bang for buck ("buck" being money and time).

What are the main use cases for squid users? (again, guesswork, please
feel free to add more)
1. forward proxy in enterprise or ISP
2. reverse proxy in datacenter
3. forward proxy in small or embedded environments

What are the Os/CPU combos that we can expect to find in these environments?
x64 is likely to be found in all of them, and the OSes most likely to
be used are all sorts of Linux, FreeBSD, OpenBSD, Windows.
For the third use case (and possibly more and more of the second in
upcoming years), we can consider arm64, arm32 and possibly MIPS with
Linux. There might be a niche of NetBSD users here, hard to tell.

By now it makes no economic sense to run Squid on large Unix boxen.
Maybe some corporate can convince some captive account to run a
reverse proxy on AIX/POWER, but I don't see anyone willing to pay tens
of thousands of dollars in maintenance contracts on expensive UNIX
iron to run a service that can run as well if not better on Linux/x64

Given these reasonings, I would recommend that we support as main targets:
- Linux on x64, arm64, arm32 and, if we can, MIPS
- FreeBSD, OpenBSD on x64
As best-effort:
- Windows on x64, with the aim of eventually promoting to primary target
- Darwin on x64 and maybe eventually arm64
- NetBSD on x64

If anyone in the community wants to support/maintain extra OSes or
architectures, they're very welcome to do so; I expect that the target
audience is of enthusiasts who have the technical skills to do so,
largely independently.

What do we get as a project out of this?
- Mainly code simplification. Fewer portability subcases makes for
easier to understand and modify code
- More clarity about our target use cases
- better coverage in our testing for our explicit target use cases


Let's discuss

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Incoming breaking changes to OpenSSL API

[Francesco Chemolli]

I just checked a built on Fedora rawhide; it builds fine!

BTW: if you want to test it, there is a tool in my support-tools repo
(https://github.com/kinkie/support-tools)

squid-build/do-build --in  --build --force --no-ccache
--log=build.log --layer=02

will do the heavy lifting, or at least it does for me.
It requires
- a working docker setup on the build machine
- I've only ever tested with uid 1001 (kinkie) and 1000. (jenkins);
not sure about other users, in fact I encourage you to test it and LMK
if it breaks

On Mon, Sep 20, 2021 at 8:42 AM Amos Jeffries  wrote:
>
> On 20/09/21 7:16 pm, Francesco Chemolli wrote:
> > Hi all,
> >Fedora Rawhide has upgraded openssl to version 3, and the results
> > can be seen at
> > https://build.squid-cache.org/job/anybranch-arm64-matrix/COMPILER=gcc,OS=fedora-rawhide,label=arm64/10/console
> >
> > For example:
> >
> > In file included from ../../../../src/security/Session.h:15,
> >   from ../../../../src/security/forward.h:15,
> >   from ../../../../src/SquidConfig.h:26,
> >   from ../../../../src/mem/old_api.cc:24:
> > ../../../../src/security/forward.h: In function ‘void
> > Security::DH_free_cpp(DH*)’:
> > ../../../../src/security/LockingPointer.h:34:21: error: ‘void
> > DH_free(DH*)’ is deprecated: Since OpenSSL 3.0
> > [-Werror=deprecated-declarations]
> > 34 | function(a); \
> >
> >
>
> <https://github.com/squid-cache/squid/pull/694>
>
> Amos
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev



-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Incoming breaking changes to OpenSSL API

[Francesco Chemolli]

Hi all,
  Fedora Rawhide has upgraded openssl to version 3, and the results
can be seen at
https://build.squid-cache.org/job/anybranch-arm64-matrix/COMPILER=gcc,OS=fedora-rawhide,label=arm64/10/console

For example:

In file included from ../../../../src/security/Session.h:15,
 from ../../../../src/security/forward.h:15,
 from ../../../../src/SquidConfig.h:26,
 from ../../../../src/mem/old_api.cc:24:
../../../../src/security/forward.h: In function ‘void
Security::DH_free_cpp(DH*)’:
../../../../src/security/LockingPointer.h:34:21: error: ‘void
DH_free(DH*)’ is deprecated: Since OpenSSL 3.0
[-Werror=deprecated-declarations]
   34 | function(a); \


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang

[Francesco Chemolli]

On Mon, Aug 16, 2021 at 12:29 PM Stuart Henderson 
wrote:

> On 2021-08-15, Alex Rousskov  wrote:
> > On 8/15/21 2:51 PM, Francesco Chemolli wrote:
> >> Hi all,
> >>   I'm looking into OpenBSD compatibility for trunk, and there's a
> >> strange behaviour at build time on  OpenBSD (6.9) / clang (10.0.1)
> >>
> >> When building src/log/access.log.cc, build fails with these errors:
> >>
> >> -- begin quote ---
> >> static_assert((is_same >> allocator_type::value_type>::value),
> >> ^
> >> ~~~
> >
> > Are some compiler messages missing in the above quote? It feels like the
> > above line is not directly related to the lines below, but perhaps I am
> > misinterpreting the messy output.
> >
> >> I'm puzzled: I wouldn't expect this to be an OS-specific failure.
> >
> > We cannot be sure it is OS-specific, but STL implementation is full of
> > hacks and optimizations that may be OS- or environment-specific. It is
> > also possible that there is a conflict between GCC and clang
> > installation; we have seen those before and they manifest in weird ways.
> >
> > It is strange that the error below mentions "unordered_map" when it
> > should say "std::unordered_map" or similar.
> >
> > Are you building with clang standard library or GCC standard library (I
> > believe -stdlib controls that, but it is not my area of expertise)? If
> > you are building with GCC stdlib, perhaps try building with
> > clang-provided stdlib?
>
> Hi, OpenBSD port maintainer here (I admit to not knowing much C++ though!).
> On OpenBSD, on all archs where the base system compiler is clang,
> it's configured to use the clang standard library (libc++) by default,
>

Hi Stuart,
Pleased to meet you


> >> /usr/include/c++/v1/initializer_list:99:1: note: candidate template
>
> and these are the correct headers for libc++. (Post-6.9 gcc is no longer
> installed in the base OS on any of the "base is clang" archs, it is
> present in ports but used only very rarely).
>
> I just gave it a spin, after adding a missed inclusion of sys/socket.h
> for SOL_SOCKET in Tcp.cc I hit the same problem with access.log.cc,
> there is a clue on the immediately previous line, which I think is
> pointing at something to do with const vs non-const SBuf, is that enough
> of a clue?
>

sys/socket inclusion is in PR#885, queued for landing any time soon.

I had patched the previous line to

for (auto i : TheGlobalContextStorage.storage) {

letting the compiler do the heavy lifting of type detection; but then the
other issues remained.
I will try some more variations.

egcc (gcc 8.4.0) builds that file just fine, so it might really be
libstdc++ related.

It fails when trying to use libcppunit, I suppose due to the fact that the
system-supplied libcppunit is built with clang++


>
>
> [...]
> Making all in log
> Making all in DB
> Making all in file
> depbase=`echo access_log.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;
> /usr/bin/libtool  --tag=CXX--mode=compile c++ -DHAVE_CONFIG_H
> -DDEFAULT_CONFIG_FILE=\"/etc/squid/squid.conf\"
> -DDEFAULT_SQUID_DATA_DIR=\"/usr/local/share/squid\"
> -DDEFAULT_SQUID_CONFIG_DIR=\"/etc/squid\"
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/include
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/lib
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src
> -I../../include -I/usr/local/include-I/usr/local/include
> -I/usr/local/include/libxml2 -I/usr/local/include  -Werror -Wextra
> -Wno-unused-private-field -Wpointer-arith -Wwrite-strings -Wcomments
> -Wshadow -Wmissing-declarations  -D_REENTRANT -I/usr/local/include/libxml2
> -I/usr/local/include -I/usr/local/include -I/usr/local/include
> -I/usr/local/include/p11-k
>  it-1  -O2 -pipe -MT access_log.lo -MD -MP -MF $depbase.Tpo -c -o
> access_log.lo
> /usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src/log/access_log.cc
> && mv -f $depbase.Tpo $depbase.Plo
> c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE="/etc/squid/squid.conf"
> -DDEFAULT_SQUID_DATA_DIR="/usr/local/share/squid"
> -DDEFAULT_SQUID_CONFIG_DIR="/etc/squid"
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/include
>

[squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang

[Francesco Chemolli]

Hi all,
  I'm looking into OpenBSD compatibility for trunk, and there's a
strange behaviour at build time on  OpenBSD (6.9) / clang (10.0.1)

When building src/log/access.log.cc, build fails with these errors:

-- begin quote ---
static_assert((is_same::value),
^
~~~
access_log.cc:66:26: note: in instantiation of template class
'std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >'
requested here
static HeaderValueCounts TheViaCounts;
 ^
access_log.cc:460:25: error: type 'HeaderValueCounts' (aka
'unordered_map, equal_to,
PoolingAllocator > >') does not provide
a subscript operator
++TheForwardedCounts[key];
  ~~^~~~
access_log.cc:467:24: error: invalid range expression of type 'const
std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >'; no
viable 'begin' function available
for (const auto  : counts)
   ^ ~~
/usr/include/c++/v1/initializer_list:99:1: note: candidate template
ignored: could not match 'initializer_list' against 'unordered_map'
begin(initializer_list<_Ep> __il) _NOEXCEPT
^
/usr/include/c++/v1/iterator:1753:1: note: candidate template ignored:
could not match '_Tp [_Np]' against 'const
std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >'
begin(_Tp (&__array)[_Np])
^
/usr/include/c++/v1/iterator:1771:1: note: candidate template ignored:
substitution failure [with _Cp = const std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >]: no
member named 'begin' in 'std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >'
begin(_Cp& __c) -> decltype(__c.begin())
^   ~
/usr/include/c++/v1/iterator:1779:1: note: candidate template ignored:
substitution failure [with _Cp = std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >]: no
member named 'begin' in 'std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >'
begin(const _Cp& __c) -> decltype(__c.begin())
^ ~
access_log.cc:489:24: error: no member named 'clear' in
'std::__1::unordered_map, std::__1::equal_to,
PoolingAllocator > >'
TheForwardedCounts.clear();
~~ ^
-- end quote ---

But then, removing the reference to PoolingAllocator in the definition
of HeaderValueCounts, everything works.
"""
using HeaderValueCounts = std::unordered_map, std::equal_to >;
"""

I'm puzzled: I wouldn't expect this to be an OS-specific failure. Any clue?



-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Compilling squid

[Francesco Chemolli]

>> ./configure --enable-ssl-crtd --with-openssl ...
> 
> I suggest that you fix basic build errors before trying to add more
> dependencies for interception. I do not know exactly what libraries you
> need for interception support on Ubuntu, and the answer may depend on
> what kind of interception you want to use. Others on this mailing list
> may help with that.
> 

https://github.com/kinkie/dockerfiles  
has the definition of the containers
used to run the Squid build farm, including installation instructions for
all relevant or semi-relevant Linux flavors. It may contain extra dependencies
for the specific set of features needed, but if Squid fails to build with that 
set of
dependencies installed, I would be very curious to know about it

Francesco___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Strategy about build farm nodes

[Francesco Chemolli]

On Mon, May 17, 2021 at 8:32 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 5/17/21 2:17 AM, Francesco Chemolli wrote:
>
> > Our Linux environments are docker containers on amd64, armv7l and arm64.
> > On a roughly monthly cadence, I pull from our dockerfiles repo
> > (https://github.com/kinkie/dockerfiles) and
> > $ make all push
>
> Does that "make push" command automatically switch Jenkins CI to using
> the new/pushed containers? Or is that a separate manual step?
>

Right now that's automatic.
I'm pondering the best way to have a staging step; Docker supports
versioning of images but we're using that feature to implement multiarch.
In order to rely on that I'll need to change the naming conventions we rely
on.


> >>> What I would place on each individual dev is the case where a PR breaks
> >>> something in the trunk-matrix,trunk-arm32-matrix, trunk-arm64-matrix,
> >>> trunk-openbsd-matrix, trunk-freebsd-matrix builds
>
> >> I think you are saying that
> >> some CI tests called trunk-matrix, trunk-arm32-matrix,
> >> trunk-arm64-matrix, trunk-openbsd-matrix, trunk-freebsd-matrix should be
> >> classified as _required_.
>
> > That is how I read the statement too.
>
> ... but it sounds like that is _not_ what you (Francesco) is actually
> proposing because you are essentialy saying "that ideal would be
> impractical" in the paragraph below. Assuming that you are not attacking
> your own proposal, that means Amos and I do not know what your proposal
> is -- we both guessed incorrectly...
>

The overarching objectives are:
- focus on where most users probably are
- allow iterating quickly giving some signal on tracked branches
- allow landing quickly with more signal
- be slow but exhaustive on every other platform we can cover. Do not block
landing new code on less common or harder to test on platforms, but still
rely on devs to own their changes there, too.

> In a word of infinite resources and very efficient testing, sure.
> > But in a space where a single os/compiler combo takes 2hrs on Linux and
> > 4hrs on Freebsd or openbsd, and a full 5-pr-test takes 6 hours end to
> > end, we need to optimize or making any of these requirements blocking
> > would make these times get 4+ times larger (a full trunk-matrix takes
> > just about a day on amd64, 2 days on arm64), and the complaint would
> > then be that development or release is slowed down by the amount of
> > testing done.
>
> FWIW, I think that full round of PR tests (i.e. one initial set plus one
> staging set) should not exceed ~24 hours, _including_ any wait/queuing
> time. This kind of delay should still allow for reasonable progress with
> PRs AFAICT. This includes any release PRs, of course. If we exceed these
> limits (or whatever limits we can agree on), then we should add testing
> resources and/or drop tests.


Is everyone okay with such a slow turnaround?


> > My proposal aims to test/land the PR on the systems where we can be
> > efficient and that are relevant, and fix any remaining after-the-fact
> > issues with followup, PRs, that remain a soft requirement for the dev
> > introducing the change.
>
> Here, I think you are proposing to make some tests optional. Which ones?
>

Not the tests, but the platforms. Things like gentoo, fedora rawhide,
freebsd, openbsd.
Testing is slower there, so results will lag and we need to batch, running
a full test suite every week or so


> > For instance: we currently have a lot of different build-time
> > configurations meant to save core memory in runtime environments. Is it
> > maybe time to revisit this decision and move these checks to run time?
>
> Sure, quality proposals for removing #ifdefs should be welcomed, one
> (group of) #ifdefs at a time. We can warn squid-users in advance in case
> somebody wants to provide evidence of harm.
>

I'm glad this is having buy-in. Are there any other opinions (for or
against)?


> > Unfortunately, one of the problems we have is that we're running blind.
> > We don't know what configurations our users deploy; we can only assume
> > and that makes this conversation much more susceptible to opinions and
> > harder to build consensus on
>
> Yes, we are blind, but I doubt we should care much about actual
> configuration in this specific context. If we can remove an #ifdef
> without serious negative consequences, we should remove it. We can avoid
> long discussions by allowing anybody with concrete evidence of problems
> to block any particular removal. I bet that conservative approach would
> still allow for the removal of many #ifdefs.
>

Sounds good to me

FWIW, I do not think reducing the numbe

Re: [squid-dev] Strategy about build farm nodes

[Francesco Chemolli]

>
>
> Adding new nodes with next distro release versions is a manual process
> not related to keeping existing nodes up to date (which is automated?).
>

Mostly.
Our Linux environments are docker containers on amd64, armv7l and arm64.
On a roughly monthly cadence, I pull from our dockerfiles repo (
https://github.com/kinkie/dockerfiles) and
$ make all push
The resulting docker images are free for everybody to use and test things
on on any docker system
(https://hub.docker.com/r/squidcache/buildfarm). Just
$ docker run -ti --rm -u jenkins squidcache/buildfarm:$(uname -m)- /bin/bash -l
(note: the above command will not preserve any artifacts once the shell
exits)

Adding new Linux distros means copying and tweaking a Dockerfile, testing
things, and updating our Jenkins jobs. I do it roughly every 6 months

FreeBSD, OpenBSD and (hopefully soon) Windows are hand-managed and much
slower changing VMs


> >> What I would place on each individual dev is the case where a PR breaks
> >> something in the trunk-matrix,trunk-arm32-matrix, trunk-arm64-matrix,
> >> trunk-openbsd-matrix, trunk-freebsd-matrix builds, even if the 5-pr-test
> >> and 5-pr-auto builds fail to detect the breakage because it happens on a
> >> unstable or old platform. >
> > This feels a bit out of topic for me, but I think you are saying that
> > some CI tests called trunk-matrix, trunk-arm32-matrix,
> > trunk-arm64-matrix, trunk-openbsd-matrix, trunk-freebsd-matrix should be
> > classified as _required_.
>
> That is how I read the statement too.
>

In a word of infinite resources and very efficient testing, sure.
But in a space where a single os/compiler combo takes 2hrs on Linux and
4hrs on Freebsd or openbsd, and a full 5-pr-test takes 6 hours end to end,
we need to optimize or making any of these requirements blocking would make
these times get 4+ times larger (a full trunk-matrix takes just about a day
on amd64, 2 days on arm64), and the complaint would then be that
development or release is slowed down by the amount of testing done.

My proposal aims to test/land the PR on the systems where we can be
efficient and that are relevant, and fix any remaining after-the-fact
issues with followup, PRs, that remain a soft requirement for the dev
introducing the change. The dev can test any work they're doing with the
anybranch-* jobs, if they don't have access to that OS

Can we do better? Sure.
For the sake of cost-mindedness a lot of the build farm nodes run in my
home - a couple of raspberry PIs, an Intel NUC, I'm in the process of
purchasing a second (and second-hand) NUC that comes with a Windows
license. The set up is meant to be thrifty, I'm mindful of burning
Foundation resources for little gain and I'm running a balancing act
between always-on VMs, on-demand VMs and my own gadgets.

The real game changer would be rethinking how we do things to reduce the
amount of testing needed.

For instance: we currently have a lot of different build-time
configurations meant to save core memory in runtime environments. Is it
maybe time to revisit this decision and move these checks to run time?
Unfortunately, one of the problems we have is that we're running blind. We
don't know what configurations our users deploy; we can only assume and
that makes this conversation much more susceptible to opinions and harder
to build consensus on

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Strategy about build farm nodes

[Francesco Chemolli]

On Wed, Apr 28, 2021 at 11:34 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 4/28/21 5:12 PM, Amos Jeffries wrote:
> > I'm not sure why this is so controversial still. We have already been
> > over these and have a policy from last time:
>
> Apparently, the recollections of what was agreed upon, if anything,
> during that "last time" differ. If you can provide a pointer to that
> "last time" agreement, please do so.
>

Merge workflows are agreed, and not in discussion. Recent discussions have
highlighted some issues with what's around them, and I'm trying to clarify
that as well

> * dev PR submissions use the volatile 5-pr-test, after test approval by
> > anyone in QA. Check against unstable OS nodes, as many as possible.
> > Kinkie adds/removes from that set as upgrades fix or break at CI end of
> > things.
>
> I do not know how to interpret the last sentence correctly, but, IMO, we
> should not add or change nodes if doing so breaks master tests. AFAICT
> from PR 806 discussion[1], Francesco thinks that it is not a big deal to
> do so. The current discussion is meant to resolve that disagreement.
>

Let me highlight the underlying principles for my proposal: IMO our
objectives are, in descending order of importance (all points should be
intended "as possible given our resources"):
1. ensure we ship healthy code to a maximum number of users
2. have minimal friction in the development workflow

These objectives have a set of consequences:
- we want our QA environment to match what users will use. For this reason,
it is not sensible that we just stop upgrading our QA nodes, or we would
target something that doesn't match our users' experience
- it makes little sense to target unstable distributions (fedora rawhide,
possibly centos stream, gentoo, opensuse tumbleweed, debian unstable) as
first-class citizens of the testing workflow, especially on stages that are
executed often (pr-test)

This means that:
- I periodically weed out distributions that are no longer supported (e.g.
Fedora 31, Ubuntu Xenial) and add current distribution (e.g. Ubuntu
Hirsute, Fedora 34).
I take it on me that when I do that, I need to ensure new compiler features
do not block previously undetected behaviours - I am currently failing
this, see https://build.squid-cache.org/job/trunk-matrix/121/ . I will need
to develop a process with a proper staging phase.
- I believe we should define four tiers of runtime environments, and
reflect these in our test setup:
 1. current and stable (e.g. ubuntu-latest-lts). These are not expected to
change much over a span of years, and to offer non-breaking updates over
their lifetime
 2. current (e.g. fedora 34)
 3. bleeding edge: they may introduce breaking changes which it makes sense
to follow because they might highlight real issues and because they will
eventually trickle down to current and then lts
 4. everything else - this includes freebsd and openbsd (mostly due to the
different virtualization tech they use)

I believe we should focus on the first two tiers for our merge workflow,
but then expect devs to fix any breakages in the third and fourth tiers if
caused by their PR, while I will care for any breakages caused by
dist-upgrades


> [1] https://github.com/squid-cache/squid/pull/806#issuecomment-827937563
>
>
> > * anubis auto branch tested by curated set of LTS stable nodes only.
>
> FWIW, the above list and the original list by Francesco appears to focus
> on distro stability, popularity, and other factors that are largely
> irrelevant to the disagreement at hand. The disagreement is whether it
> is OK to break master (and, hence, all PR) tests by changing CI. It does
> not matter whether that CI change comes from an upgrade of an "LTS
> stable node", "unstable node", or some other source IMO. Breaking
> changes should not be allowed (in the CI environments under our
> control). If they slip through despite careful monitoring for change
> effects, the breaking CI changes should be reverted.
>

I think it depends.
Breakages due to changes in nodes (e.g. introducing a new distro version)
would be on me and would not stop the merge workflow.
What I would place on each individual dev is the case where a PR breaks
something in the trunk-matrix,trunk-arm32-matrix, trunk-arm64-matrix,
trunk-openbsd-matrix, trunk-freebsd-matrix builds, even if the 5-pr-test
and 5-pr-auto builds fail to detect the breakage because it happens on a
unstable or old platform.

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Strategy about build farm nodes

[Francesco Chemolli]

Hi all,
  I'm moving here the discussion from PR #806 about what strategy to have
for CI tests, looking for an agreement.

We have 3 classes of tests ni our CI farm (https://build.squid-cache.org/)
- PR staging tests, triggered by commit hooks on GitHub (possibly with
human approval)
   the job is 5-pr-auto (misnamed, it tests trunk with the PR applied).
   To be successful, it needs to successfully compile and unit-test all
combinations of clang and gcc on the latest stable version of the most
popular linux distros, at this time centos-8, debian-testing,
fedora-33, opensuse-leap, ubuntu-focal
- PR build tests run , after a PR is approved, also triggered by GitHub
  the job is 5-pr-test
  To be successful, it needs to compile and unit-test all combinations of
clang and gcc on LTS and most recent versions of most popular linux
distros, at this time: centos-7,
debian-stable, debian-unstable, fedora-32, fedora-34, ubuntu-bionic,
ubuntu-hirsute
- full-scale build tests (jobs: trunk-matrix, trunk-arm32-matrix,
trunk-arm64-matrix, trunk-freebsd13-clang-matrix, trunk-openbsd-matrix)
  these test everything we can test, including bleeding edge distros such
as getntoo, rawhide, tumbleweed, and the latest compilers. Failing these
will not block a PR from mergeing, but there is an expectation that build
regressions will be fixed

The change in policy since last week is that the PR-blocking builds used to
depend on unstabledistros (fedora-rawhide and opensuse-tumbleweed), I've
removed that today as part of the discussion on PR #806
This policy would allow keeping stable distros uptodate and matching
expected user experience, while not introducing instability that would come
in from the unstable distros
One distro that's notably missing is centos-stream, this is due to
technical issues with getting a good docker image for it, when available
I'll add it

Would this work as a general policy? If there is agreement, I'll support
it moving forward

Thanks

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC: making TrieNode less memory-hungry

[Francesco Chemolli]

>
> Do ESI users want to trade speed for memory savings? What memory savings
> and speed reduction do you anticipate for a typical use case or two?
>
> In light of the fact that it's only used by ESI, I think it's not
worthwhile investing in it.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] cppunit -> googletest / gmock?

[Francesco Chemolli]

On Sat, May 30, 2020 at 7:38 PM Amos Jeffries  wrote:

> On 31/05/20 5:27 am, Francesco Chemolli wrote:
> > Hi all,
> >starting from a PR in a conversation with Alex about our current
> > approach to unit testing being painful, I've checked what alternatives
> > would we have and how practical would they be.
> >
> > An easy first option would be googletest/googlemock.
> >
> > On a lazy afternoon, I've tried seeing how useful/painful it would be to
> > try it, by porting one test over - it's quite trivial and doesn't
> > require mocking, so I'll try a more complicated one next - to start a
> > conversation about the topic.
> >
> > You can find the test branch at
> https://github.com/kinkie/squid/tree/gtest .
> > I've only touched two files, a newly-created src/tests/testMemGtest and
> > src/Makefile.am .
> >
> > The output from the test run is at
> https://paste.ubuntu.com/p/3sgTDN7rNm/
> >
> > What do you think?
> >
> > My initial thoughts:
> > - it is somewhat simpler and more powerful than cppunit
> > - setting the test environment up is easy but at this time it can only
> > be done from source. Adding it to the build farm images is
> straightforward
>
> That is a problem. The unit tests are run by pretty much everyone
> building Squid.
>

We should be able to bundle gtest if needed; we only distribute in source
form and it wouldn't be part of distfiles so it shouldn't be a problem
downstream either, I believe


> It is not a complete blocker, but having a process more complex than
> simple dependency install does pose a relatively major hurdle that any
> framework has to get over to be of much utility.
>
>
>
> > - the license is BSD 3-clause new
> > (https://github.com/google/googletest/blob/master/LICENSE)
> > - googlemock promises to be vastly superior to our current approach
>
> Where are you seeing evidence of this?
>

Also including answer on Alex' question:
- https://stackoverflow.com/questions/7922289/googletest-vs-cppun
it-the-facts
<https://stackoverflow.com/questions/7922289/googletest-vs-cppunit-the-facts>
- trivial but it builds up: not generally necessary to have .h and .cc for
simple cases
- comparison table:
https://socialcompare.com/en/comparison/c-unit-testing-framework
- gmock/gtest is used in broadly-used projects (e.g. chromium) - I'm not
sure


So far I'm basing on documentation, found at
https://github.com/google/googletest/blob/master/googlemock/docs/cook_book.md
 .
I see:
- a more structured approach to mocking, and more infrastructure to do it
- ON_CALL and EXPECT_CALL patterns to define actions and expectations on
class methods (method called once / called multiple times). This can also
allow to change the behaviour of a mocked object on different tests without
having to remock it all
- matchers on called methods
- moched methods can different return values depending on arguments, and
check for complex sequences of calls to methods (call a() with some
arguments, then either b() or c(), if it's c() must be followe by d()
- for object, the concept of "uninteresting calls" that get ignored, and
can be defaulted



> The main issue we have with cppunit itself is that when a test fails it
> is not clear from the output which assertion occurred, nor why. One is
> left having to try and trigger the unit failure again manually and gdb
> from there.
>
> This can be worked around by following best-practice in unit test
> implementation. But people contributing to Squid have not been doing so
> consistently, and it is just a workaround.
>
> I do see somewhat more verbose output in the logs, and slightly less
> code to implement (no .h class). Which is a nice gain, but not what I
> would call "vastly superior".
>

Right. A lot of value comes from the combination with gmock.


>
>
> > - porting memTest took me about one hour, mostly caused by us including
> > cppunit headers from squid.h (WUT? A PR is coming up to unentangle that)
> >
>
> Converting tests from one framework to another is not a problem. We just
> have nobody doing the legwork. Case in point being the old tests not
> even using cppunit.
>

>
> The main problem(s) we have with testing of Squid is dev participation:
>
>  a) people are not writing tests to cover new code, and
>  b) people are not writing/updating tests to cover bug fixes, and
>  c) tests written are generally not following best practice design.
>
> IIRC Alex an I have different ideas about the ideal focus of testing;
>  * I prefer the micro-test approach to demonstrate a high quality proof
> of code reliability.
>  * Alex has stated a preference for high level black-box testing of
> behaviour vs design 

[squid-dev] cppunit -> googletest / gmock?

[Francesco Chemolli]

Hi all,
   starting from a PR in a conversation with Alex about our current
approach to unit testing being painful, I've checked what alternatives
would we have and how practical would they be.

An easy first option would be googletest/googlemock.

On a lazy afternoon, I've tried seeing how useful/painful it would be to
try it, by porting one test over - it's quite trivial and doesn't require
mocking, so I'll try a more complicated one next - to start a conversation
about the topic.

You can find the test branch at https://github.com/kinkie/squid/tree/gtest .
I've only touched two files, a newly-created src/tests/testMemGtest and
src/Makefile.am .

The output from the test run is at https://paste.ubuntu.com/p/3sgTDN7rNm/

What do you think?

My initial thoughts:
- it is somewhat simpler and more powerful than cppunit
- setting the test environment up is easy but at this time it can only be
done from source. Adding it to the build farm images is straightforward
- the license is BSD 3-clause new (
https://github.com/google/googletest/blob/master/LICENSE)
- googlemock promises to be vastly superior to our current approach
- porting memTest took me about one hour, mostly caused by us including
cppunit headers from squid.h (WUT? A PR is coming up to unentangle that)

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] squid master build with alternate openssl fails

[Francesco Chemolli]

On Fri, May 8, 2020 at 3:58 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 5/8/20 10:12 AM, Christos Tsantilas wrote:
>
> > Squid master 699ade2d fails to build with an alternate OpenSsl, when the
> > "--with-openssl=/path/to/openssl" is used.
>
> Francesco, builds with custom OpenSSL paths are not that uncommon,
> especially among SslBump admins. Would you be able to test that kind of
> configuration in one of the Jenkins tests? It can be even combined with
> other custom-path tests. Or is this too custom/special to warrant an
> automated test in your opinion?


The most complicated part is to prep and keep uptodate a test environment
with openssl in a nonstandard location; I rebuild our docker images once a
month to ensure they're fresh with what's in the wild.
To decide how much effort to invest, how prevalent is this situation? On
Linux I'd expect this to be pretty much a corner case by now, is it not?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] RFC: clang-format

[Francesco Chemolli]

Hi all,
  I have made an attempt at running clang-format on the squid sources,
after applying a configuration which follows as closely as possible
the project's coding guidelines.

You can find the output of the exercise at
https://github.com/kinkie/squid/tree/clang-format ; the configuration
is at https://github.com/kinkie/squid/blob/clang-format/.clang-format
.

Most of the changes are shifting comments and realigning macro blocks.
What do you think? Is it worthwhile to make this or same variant of
this an official guideline?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] removing cache_diff?

[Francesco Chemolli]

doing that today.

On Tue, Apr 7, 2020 at 2:47 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 4/6/20 5:00 PM, Francesco Chemolli wrote:
>
> > has anybody used the cache_diff program in the last 10 years?
>
> Not me. If you are going to remove it, I recommend asking on squid-users
> as well and giving folks a week to respond.
>
> Thank you,
>
> Alex.
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] removing cache_diff?

[Francesco Chemolli]

Hi all,
  has anybody used the cache_diff program in the last 10 years?
I've used squid for 20 years now, and I never even noticed it.
It's not even installed as part of the build process...

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] RFC: use clang-format?

[Francesco Chemolli]

Hi all,
   astyle is a bit of PITA, maybe we can replace it with clang-format?
It seems to me it has more power and flexibility, and its config could be
stored in the source tree itself.
What do you think?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC: cacheMatchAcl

[Francesco Chemolli]

It was quite fast really as my PR doesn’t address the fundamental design
issues nor much of the coding style. A quick win could be to move from a
list to an unordered_map, it’s a quite trivial cache in the end. There’s a
lot of machinery in there for such a simple data structure :/

On Sat, 4 Apr 2020 at 08:15, Amos Jeffries  wrote:

> On 4/04/20 7:49 pm, Francesco Chemolli wrote:
> > I am not sure about what you recommend to do here.
> > This cache is IMO over complicated and it breaks layering.
> > I’m mostly done in a PR replacing the dlink with a std::list but without
> > changing the overall design. It does kill a few tens of lines of code
> > and is clearer to read tho.
> >
>
> Well, if you have already done the work it migth as well finish up. I
> was thinking you had just done the investigation and not started
> refactoring yet.
>
> Amos
>
-- 
@mobile
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] RFC: cacheMatchAcl

[Francesco Chemolli]

I am not sure about what you recommend to do here.
This cache is IMO over complicated and it breaks layering.
I’m mostly done in a PR replacing the dlink with a std::list but without
changing the overall design. It does kill a few tens of lines of code and
is clearer to read tho.

On Sat, 4 Apr 2020 at 07:41, Amos Jeffries  wrote:

> On 4/04/20 3:34 am, Alex Rousskov wrote:
> > On 4/3/20 7:25 AM, Francesco Chemolli wrote:
> >
> >>   I'm looking at places where to improve things a bit, and I stumbled
> >> across cacheMatchAcl . It tries hard to be generic, but it is only ever
> >> used in ACLProxyAuth::matchProxyAuth . Would it make sense to just have
> >> a specialised cache for proxyauth?
> >
> > I wonder whether proxy_auth is special in this context:
> >
> > 1. Is proxy_auth cache radically different from other ACL caches such as
> > external ACL cache? Or did we just not bother unifying the code
> > supporting these two caches?
> >
>
> Pretty much yes, we have not done the legwork. Almost every component in
> Squid which deals with externally provided state has some form of ad-hoc
> cache. If we are lucky the use a hash or dlink. One at least uses splay
> (ouch).
>
>
> One of my background projects in the effort to empty the PR queue this
> year is to implement a proper CLP Map - specifically for PR 30 instead
> of the LruMap disagreement blocking it. That would be a good container
> to use for all these small state data caches all over Squid - keyed
> access with a dual TTL and LFU (fading) removal mechanism.
>
> If this ACL cache is not causing issues already we can wait until that
> gets submitted for review.
>
>
> > 2. Do some other ACLs cache nothing just because we did not have enough
> > time to add the corresponding caching support? Or do proxy_auth and
> > external ACL poses some unique properties that no other ACL already has
> > or likely to have in the foreseeable future?
>
> The only thing special is that cache they use is exclusively accessed by
> them.
>
> IDENT, ASN, DNS based ACLs also use caches. But those are a bit detached
> from the ACL code itself (eg fqdncache) since other code sometimes
> accesses the cache directly for other uses.
>
>
> Amos
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>
-- 
@mobile
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] RFC: cacheMatchAcl

[Francesco Chemolli]

Hi all,
  I'm looking at places where to improve things a bit, and I stumbled
across cacheMatchAcl . It tries hard to be generic, but it is only ever
used in ACLProxyAuth::matchProxyAuth . Would it make sense to just have a
specialised cache for proxyauth?

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] squid.conf future

[Francesco Chemolli]

I like the idea of markdown, if possible.
It is simple and gets the job done.
Would processing it be more cumbersome than the alternatives?

On Wed, Feb 26, 2020 at 8:43 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 2/25/20 1:31 AM, Amos Jeffries wrote:
>
> > Any suggestions of formats I should look at then?
>
> I believe cf.data.pre should use two primary formats, each optimized
> specifically for the content it is applied to. The secondary details of
> each format will evolve, but here is where I would start today:
>
> 1. YAML-like metadata to supply formal details about each directive. We
> already use this today, and I expect no significant changes in the
> immediate future (even though many improvements are possible in this
> area!).
>
> 2. Markdown for informal documentation inside DOC_START...DOC_END,
> DEFAULT_DOC, and similar text blocks. Preprocessing includes validation
> of internal references (for sure), generation of internal anchors
> (probably), and removal of minimal common indentation (not sure; need to
> experiment/discuss). Other preprocessing actions may be desirable as
> well, of course. An agreement on the lower-level details and a
> non-trivial conversion effort would be required. We can discuss whether
> to do it incrementally or once-and-for-all.
>
>
> HTH,
>
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] handling spaces in path to sources

[Francesco Chemolli]

Following up.

TL;DR: it's pointless. Spaces in paths are not safe and do not work. Even
if we were to make our own scripts safe - which the feature tree above does
- configure will barf if there are spaces in the source tree path, and
libtool will fail assembling a safe compile command if there are spaces in
the build path.

The feature branch is at
https://github.com/kinkie/squid/tree/securify-test-builds

This was tested on MacOS Catalina with
- autoconf 2.69
- libtool 2.4.6
- gmake 3.81
- clang 11


On Tue, Feb 18, 2020 at 8:40 AM Francesco Chemolli 
wrote:

> Hi all,
>   as a followup to discussion on PR 555, I was looking into safely
> handling source code paths with spaces.
>
> Turns out worrying is pointless: after doing the needed changes, doing a
> test build with
> builddir = "/Users/kinkie/src/test build with space"
> srcdir = "/Users/kinkie/src/squid dir with space"
> on MacOS catalina with homebrew
>
> resulted in configure failing with error:
> checking whether build environment is sane... configure: error: unsafe
> srcdir value: '/Users/kinkie/src/squid dir with space/test-suite/..'
>
> If there is no regression with my changes, I'll submit the PR anyway, but
> its benefits will be limited.
>
> --
> Francesco
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] handling spaces in path to sources

[Francesco Chemolli]

Hi all,
  as a followup to discussion on PR 555, I was looking into safely handling
source code paths with spaces.

Turns out worrying is pointless: after doing the needed changes, doing a
test build with
builddir = "/Users/kinkie/src/test build with space"
srcdir = "/Users/kinkie/src/squid dir with space"
on MacOS catalina with homebrew

resulted in configure failing with error:
checking whether build environment is sane... configure: error: unsafe
srcdir value: '/Users/kinkie/src/squid dir with space/test-suite/..'

If there is no regression with my changes, I'll submit the PR anyway, but
its benefits will be limited.

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] [SPAM] Squid irc log bot

[Francesco Chemolli]

Hi all,
  is anyone using the free node irc log bot anymore? If not, I’m considering 
retiring it.

Thanks,
  Kinkie
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] ARMv7 build nodes

[Francesco Chemolli]

Hi all,
  https://build.squid-cache.org/job/5-matrix-arm/ is our first
ARMv7(32bit) build node - docker/linux/raspberry pi 3.
  Next up, hopefully, FreeBSD on aarch64 (banana pi).

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] PVS Studio

[Francesco Chemolli]

> On Jan 14, 2019, at 19:11, Alex Rousskov  
> wrote:
> 
> On 1/14/19 3:20 PM, Francesco Chemolli wrote:
>> Hi all,
>>  the team behind PVS studio (static code analysis tool) has decided
>> to support FOSS projects for free (beer).
>>  
>> https://hownot2code.com/2019/01/14/free-pvs-studio-for-those-who-develops-open-source-projects/
>>  Unless there are any concerns, I'll look into integrating our build
>> pipelines with that service in addition to Coverity.
> 
> Coverity has not been integrated into our automated testing of pull
> requests. I assume you want to look into similar-to-Coverity integration
> for PVS studio, and I would welcome that kind of integration if your
> initial tests are positive.

Coverity cannot be fully integrated in the pull request workflow: in order not 
to squander resources on their cloud offering, they ask (do not enforce, 
though) not to do more than a scan per week. In other words, what we do now is 
the best we can do with their free tool.
I’ve rechecked PVS studio; their ask for FOSS projects is that a comment be 
added to every single file acknowledging their support, and I do not think 
that’s a fair ask of them, so I’m stopping the effort.
I’ve looked into other similar static check tools such as Facebook’s Infer, 
it’s a pain in the neck to build. clang static analyzer 
(https://clang-analyzer.llvm.org/) may be our best option if we want per-commit 
static code analysis.

Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] PVS Studio

[Francesco Chemolli]

Hi all,
  the team behind PVS studio (static code analysis tool) has decided
to support FOSS projects for free (beer).
  
https://hownot2code.com/2019/01/14/free-pvs-studio-for-those-who-develops-open-source-projects/
  Unless there are any concerns, I'll look into integrating our build
pipelines with that service in addition to Coverity.

-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Anubis documentation

[Francesco Chemolli]

Lovely! I was not aware of the documentation you mention. I did a brief
search but I was too brief I guess.
All praise the Flying Spaghetti Monster and his holy finite state machines !

On Tue, 25 Sep 2018 at 17:46, Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 09/25/2018 09:46 AM, Francesco Chemolli wrote:
>
> >   recent discussions on github led me to understand that information
> > on Anubis' interfaces is in peoples' heads and not on a bit of paper.
> > Would it be possible to write a brief wiki page with some info about
> > what is the FSM driving it and what are the tags it uses to store
> > state?
>
> I can assure you that Anubis is not driven by the Flying Spaghetti
> Monster. The two deities are not even related!
>
> Anubis logic and tags are pretty well documented at
> https://github.com/measurement-factory/anubis#readme
>
> Squid Project configuration for Anubis is documented at
> https://wiki.squid-cache.org/MergeProcedure#Automation
>
> Fixes/updates/additions are welcomed, of course. If you have questions
> not answered by the above documents, please do not hesitate to ask.
>
> We are still working on one big change/improvement -- support for
> concurrent processing of multiple PRs. That change will affect some of
> the existing documentation and should end the current "trial run" or
> "careful testing" stage. After that, I do not anticipate significant
> changes to Anubis algorithms unless somebody else contributes them.
>
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>
-- 
@mobile
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Anubis documentation

[Francesco Chemolli]

Hi all,
  recent discussions on github led me to understand that information
on Anubis' interfaces is in peoples' heads and not on a bit of paper.
Would it be possible to write a brief wiki page with some info about
what is the FSM driving it and what are the tags it uses to store
state?
Thanks!
-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Squid-4.1 (stable)

[Francesco Chemolli]

Great!

Looking forward to it

On Tue, Jun 26, 2018 at 8:33 AM Amos Jeffries  wrote:

>
> The latest Squid-4 beta has now passed 14 days with no new major bugs
> being reported. That means I can start the final countdown for the
> Squid-4.1 release.
>
> Unless something new comes up I intend to bundle that release on
> 2018-06-30.
>
>
> Amos
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>


-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Introduction

[Francesco Chemolli]

Please,
  Let’s all be respectful here. There is no need to call anyone names,
especially under the unfounded assumption of ill intent. There are plenty
of forums focused on policies and politics, and this isn’t one of them.



On Mon, 19 Mar 2018 at 12:08, Serge  wrote:

> >>Hello, I'm a networking and security analyst who works for the
> government in Brazil.
> >>bla-bla-bla content filter
>
> Rephrasing your words, you're whore for the government and you're fighting
> against basic human freedoms. Freedom to gather information of any kind.
> Freedom to know the truth about corrupt politicians.
> Freedom of speech. In addition, your country's goverment structures even
> can not afford to pay for professional products so they're asking you to
> use free software, whose ideas are directly
> contary to what you are doing.
>
> After this, you're stupid enough to write to this mailing list asking
> community for the further assistance in your "noble endeavors" and you're
> even not asking some particular question. Well, may god help you.
>
> 18.03.2018, 15:06, "Danilo V" :
>
> Hello, I'm a networking and security analyst who works for the government
> in Brazil.
> I work especially with free software. I am currently allocated to a
> content filter customization project using docker, puppet, squid,
> squidguard and sarg.
>
> I would like to join the mailing list for help with the issues I have
> encountered.
>
> Thanks,
> Danilo Teixeira
> ,
>
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>
-- 
@mobile
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Build failed in Jenkins: 4-matrix » clang,d-debian-wheezy #85

[Francesco Chemolli]

> On Sep 10, 2017, at 20:01, Amos Jeffries  wrote:
> 
> FWIW none of the compilers on Debian wheezy (and probably Jesse) can handle 
> Squid-4+ builds due to their incomplete C++11 implementation.

Ok, removing them from the build list.
Sorry for the noise, I’m reenabling and migrating jobs.

On the plus side, Unstable seems to be back :)

Kinkie

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Git-related wiki updates

[Francesco Chemolli]

Hi Alex,
thanks for taking the time!
The updated documents are very helpful and seem quite accurate, I'll try them 
out and amend if I find any need.

Did you have any challenges with wiki editing?

Thanks!
Francesco

> On 2 Aug 2017, at 07:49, Alex Rousskov  
> wrote:
> 
> Hello,
> 
>FYI, I have started updating developer wiki pages to reflect recent
> git/GitHub-related changes:
> 
>  * http://wiki.squid-cache.org/MergeProcedure
>  * http://wiki.squid-cache.org/GitHints
>  * http://wiki.squid-cache.org/DeveloperResources
> 
> We should not compete with many wonderful git guides and GitHUb manuals,
> but there is still a lot of work to be done summarizing Squid-specific
> details. Please contribute.
> 
> 
> Thank you,
> 
> Alex.
> ___
> squid-dev mailing list
> squid-dev@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] [PULL REQUEST] Pass-through with-openssl argument

[Francesco Chemolli]

Hi all,
https://github.com/squid-cache/squid/pull/31 
 is about passing through the 
—with-openssl argument in maximum-test build when openssl is installed in a 
non-system location (as it happens on macOS home-brew).

Please review :)

Kinkie___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] Log SSL Cryptography Parameters

[Francesco Chemolli]

On 10 Dec 2015, at 18:36, Christos Tsantilas  wrote:

> This patch adds the following formatting codes:

LGTM. +1.

Kinkie
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] Fix shared memory initialization, cleanup. Ensure its usability.

[Francesco Chemolli]

On 10 Dec 2015, at 19:23, Amos Jeffries  wrote:

> Okay. Good points, and some very good ones.
> 
> 
> So it comes down to doing it your way and we will have to come up with
> something to explain to confused admin why their proxies are now slow.

Well, slow in starting up, not in operating, hopefully.
And it is actually pretty detectable: let’s choose an arbitrary size of the 
shared segment and output a warning message to cache.log. This won’t help with 
the speed, but it might help with the confusion..

Kinkie
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] %ssl::

[Francesco Chemolli]

On 10 Dec 2015, at 18:04, Christos Tsantilas  wrote:

> This is a complement patch for "%ssl:: applied to trunk as r14343.

LGTM. +1.

Kinkie
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev