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/
