libapache2-mod-xsendfile packaging inconsistency

[GJB]

Hi Robie,

Thanks for replying. Yes, I can see the sources linked and I'm quite 
sure they are not the source that built the supplied module binary.

Open source systems supplying binaries that are not built using the 
correct/advertised/documented sources kind of undermines the whole 
concept of OS packaging. Hence my consternation.

Not sure if you are the  right guy to get into the details with but the 
supplied binary does not support the "Content-Encoding" feature, fails 
when processing g-zipped files and has probably been built with source 
with the following 2 lines 398-340 removed

apr_table_unset(r->err_headers_out, "Content-Encoding");

apr_table_unset(r->headers_out, "Content-Encoding");


Perhaps a rebuild using recent, known source is in order to be sure what 
is exactly in the 9 year old binary?

Regards,

Greg B.


On 13/10/22 10:10, Robie Basak wrote:
> Hi,
>
> On Wed, Oct 12, 2022 at 05:49:00PM +1300, GJB wrote:
>> this module is packaged with a binary built by the following source linked
>> on this page
> I'm not sure exactly what you're asking, but you can see the sources
> used to build libapache2-mod-xsendfile for Ubuntu 22.04 (Jammy) here:
>
> https://git.launchpad.net/ubuntu/+source/libapache2-mod-xsendfile/log/?h=applied/ubuntu/jammy-devel
>
> The "applied" refs are the most relevant for inspection by developers
> not familiar with Debian's quilt-based packaging.
>
> It looks like the build for amd64 was made in 2013 when Saucy was in
> development, and hasn't changed since.
>
> Hope that helps,
>
> Robie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20221013/268f8f98/attachment.html>