No worries. I'm glad you included [email protected] in this
development of software that is important to mod_perl2.
I'm curious though, why not upgrade the libapreq2 package in the
FreeBSD ports/pacakges system to libapreq2 v2.18, which already
resolved the problem, instead of creating a different branch of v2.17
(along with the additional effort that entails)?
Or is there something about libapreq2 v2.18 that creates other
problems that makes it the wrong candidate?
Thanks.
> I am very sorry, I did not remove [email protected] 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, [email protected] 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 [email protected] (mailto:[email protected]) 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
> > > <[email protected]>
> > > (mailto:[email protected])
> > > 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/[email protected]: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 [email protected]
> > Inter-Corporate Computer & Network Services, Inc.
> > Beautiful British Columbia, Canada
> > https://www.inter-corporate.com/
> >
> >
Randolf Richardson, CNA - [email protected]
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
https://www.inter-corporate.com/
