Amos Jeffries wrote: > On Tue, 20 Oct 2009 01:04:26 +0200, Henrik Nordstrom > <hen...@henriknordstrom.net> wrote: > >> mån 2009-10-19 klockan 12:10 +1300 skrev Amos Jeffries: >> >> >>> Um, is that function libcap2 specific? >>> >> Not sure when it was added. Checking... seems to be 2.09. Added to the >> git repository Sat Mar 29 21:40:06 2008 -0700. >> >> There is also a libcap-ng project these days, with yet another API.. >> > > The other was mentioned as a possible requirement as well. I have not > spent any time seeing whether its worth it or not to support libcap-ng. Do > you know enough about them both to pick? > > >>> It may be related to the LIBCAP_BROKEN identifier or another such test >>> for the specific function may be worth adding... >>> >> I rather have one code base than two here.. either libcap is used or it >> is not. Using libcap if found working or raw syscalls if not does not >> sound like a good idea to me. >> >> But maybe we can require a reasonably current libcap-2 for TPROXY >> support? It requires a custom kernel anyway on the systems with too old >> libcap implementations I think. >> > > We can do that yes. I think I would also rather do it too. It paves the > way for a clean deprecation cycle now that TPROXYv4 kernels are effectively > mainstream: > > 3.0: (2008-2010) TPROXYv2 with libcap + libcap2 > 3.1: (2010-2012) support TPROXYv2 + TPROXYv4 with libcap2 > 3.2: (2011?) support TPROXYv4 with libcap2 > > Amos > > i guess this fix went into squid 3.1.0.14 ... ? the gentoo package for that version just appeared in the portage tree and i installed it. no more warning messages in dmesg. good job! will this find it's way into squid 3.0 too ? or can i wait for 3.2 ? i did not find a planned release date.
regards -alex
