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/

Reply via email to