I am very sorry, I did not remove modperl@perl.apache.org from my email
to Klara systems. This was not intended for the list.
To answer your question, I don't want to compile and install from
source, although I could, I would prefer to use the FreeBSD ports /
packages system.
On 7/22/25 12:01, rand...@modperl.pl wrote:
Why is effort being put into patching libapreq2 v2.17 when simply
compiling v2.18 from source already solves the problems?
> We now know how to fix this problem. The installation I have for testing mixes
> packages from poudriere and ports installed from /usr/ports, which is not best
> practice. The question is how to apply a fix in production in the "right" way?
>
> A) make a poudriere based on an older snapshot of the ports tree that includes
> libapreq2 version 2.16. I am 85% sure that the bug was introduced in 2.17.
> Build only the libapreq2 package (which unfortunately has a lot of
> dependencies, including Apache itself), then have a repo pointing to that with
> priority higher than FreeBSD default "Latest" as well as higher than our own
> current "Latest" poudriere. The problem with this approach is we will end up
> with an older version of Apache and a lot of other important packages.
>
> B) Klara convinces apa...@freebsd.org (mailto:apa...@freebsd.org) to put out
an
> official upgrade in the ports tree version 2.17_1 with the patch that Xavier
> created
>
> C) We create a poudriere with Xavier's patch applied to libapreq2, or rather
> apply the patch to our existing "default" poudriere. I don't know how to do
> that, but it seems like a use case poudriere must have been designed for.
>
> D) I use my existing mix of ports & packages in prod, perhaps with some pkg
> lock, on the grounds that we know it works and we can roll forward to a better
> solution when one comes out soon. I have done worse things in the past.
>
> I hope this makes sense.
>
> - Alex
>
>
> On 7/18/25 19:31, Alex Aminoff wrote:
>
> I did this, and I believe it has fixed the problem!
>
> You can test this here
>
> http://backdev.nber.org/uploadtest
>
> What I did was apply your patch in /usr/ports on our diskless root
> FreeBSD-14.2-root-202507, after running make extract in www/libapreq2. Then
> I had to re-compile in ports mod_perl and p5-libapreq2 and some other
> stuff, and install those from ports.
>
> root@bsdalt:/usr/ports/www/p5-libapreq2 # pkg info | grep apreq
> libapreq2-2.17_1 Generic Apache2 Request Library
> p5-libapreq2-2.17 Perl binding for the Generic Apache2 Request Library
>
> Now the next question is what is the best way to have this "in production".
> Can we apply your patch in some sensible way on poudriere? Or will you
> contact the libapreq2 maintainers and try to get it accepted there?
>
> Also, there is now a weird problem where /usr/local/etc/rc.d/apache24
> always takes a really long time to run, like a minute. I need to track down
> what is slowing it down.
>
> - Alex
>
>
> On 7/18/25 02:22, Xavier Beaudouin wrote:
>
> Hello Alex,
> I made a try to integrate the 3 commits into current port.
> Can you have a try on your side, with the following patch (from current
> port tree)?
> Kind regards,/Xavier
>
> Le 18 juil. 2025 à 03:06, Alex Aminoff
> <support.free...@klarasystems.com>
(mailto:support.free...@klarasystems.com)
> a écrit :
> Ticket URL:
> https://support.klarasystems.com/Ticket/Display.html?id=2159
(https://support.klarasystems.com/Ticket/Display.html?id=2159)
>
> I did a bit of googling and found this unfortunately rather
> vitriolic thread
>
> https://lists.apache.org/list?d...@httpd.apache.org:2024-2:apreq
>
> I could not quite follow which of those people if any are the
> nominal maintainers of apreq. Patches to the current version might
> be a way forward. OTOH maybe the maintainers of the FreeBSD port
> know some of those people or are some of those people and are aware
> of or involved in the politics?
>
> - Alex
>
>
> On 7/17/25 15:58, Allan Jude wrote:
>
> There only appear to be 3 changes since 2.17, all from 2023.
>
> The first one talks specifically about a regression in 2.17,
> and restoring the behaviour from 2.16
>
> Might be the one
>
>
> Allan Jude
> --
> Principal Solutions Architect @ Klara Inc.
> W: klarasystems.com (https://klarasystems.com/)
> M: +1 289-260-5944
>
>
> On 2025-07-17 3:54 p.m., Kyle Evans wrote:
>
> Ticket URL:
> https://support.klarasystems.com/Ticket/Display.html?id=2159
(https://support.klarasystems.com/Ticket/Display.html?id=2159)
>
> Hi,
>
> If we knew which commits from libareq2 fix it, we could try
> to convince the port maintainer to accept them as patches
> to the current version if they don't want to hop to a
> snapshot of a development version -- assuming the patches
> aren't incredibly invasive.
>
> Thanks,
>
> Kyle Evans
>
> On 7/17/25 14:52, Alex Aminoff wrote:
>
> Ticket URL:
> https://support.klarasystems.com/Ticket/Display.html?id=2159
(https://support.klarasystems.com/Ticket/Display.html?id=2159)
>
> On 7/17/25 15:23, Alex Aminoff wrote:
> >
> > Meanwhile I will try wrapping upload() in an eval.
> >
> I tried this, and it is successful in that it returns control to
the
> perl code, but the result of the upload call is undef. As I
demonstrated
> in my initial post, if there are multiple file fields, any of
them being
> un-filled triggers the bug, so I can not get the info for the
file the
> user actually uploaded.
>
> Therefore one possible way forward will indeed be to download the
> bleeding edge libapreq2 from source and compile and install it. I
can do
> that, or you could. But please if you can do some more
investigation first.
>
> - Alex
>
>
>
> --
> Kyle Evans
> FreeBSD Engineering Manager, Klara Inc.
>
>
> Xavier Beaudouin-System Engineer @ Klara Inc.W: klarasystems.com
(http://klarasystems.com)
>
>
Randolf Richardson, CNA -rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
https://www.inter-corporate.com/
