Bug#1050458: apache2: given is deprecated at /usr/sbin/a2enmod
Package: apache2 Version: 2.4.57-2 Severity: important Tags: trixie sid User: debian-p...@lists.debian.org Usertags: perl-5.38-transition autopkgtest Control: affects -1 munin Installing this package spews warnings with Perl 5.38 (currently in experimental) because a2enmod uses the deprecated 'given' and 'when' Perl keywords. Setting up apache2 (2.4.57-2) ... given is deprecated at /usr/sbin/a2enmod line 577. when is deprecated at /usr/sbin/a2enmod line 578. when is deprecated at /usr/sbin/a2enmod line 586. Enabling module mpm_event. given is deprecated at /usr/sbin/a2enmod line 577. when is deprecated at /usr/sbin/a2enmod line 578. when is deprecated at /usr/sbin/a2enmod line 586. [...] This breaks at least the munin autopkgtest checks as seen at https://ci.debian.net/data/autopkgtest/unstable/amd64/m/munin/37098324/log.gz 429s master-cgi-systemd FAIL stderr: given is deprecated at /usr/sbin/a2enmod line 577. so filing at 'important' (but feel free to adjust.) -- Niko Tyni nt...@debian.org
Bug#916375: apache2: Segmentation fault when mod_perl.so is loaded
Control: reassign -1 libmariadbclient18 10.1.37-0+deb9u1 This reportedly regressed with DSA-4341-1, reassigning to the correct package. -- Niko Tyni nt...@debian.org
Bug#916375: apache2: Segmentation fault when mod_perl.so is loaded
On Thu, Dec 13, 2018 at 06:44:32PM +0100, h.thien wrote: > Package: apache2 > Version: 2.4.25-3+deb9u6 > Severity: grave > Tags: patch > Justification: renders package unusable > gdb> Thread 1 "/opt/otrs/bin/cgi-bi" received signal SIGSEGV, > Segmentation fault. > gdb> bt > #0 0x7fffdcd290c7 in free_defaults () from > /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 > We are using unattended upgrades (security only), and we suspect that > an automatic system update has installed a new Perl version that now causes > these problems. Have you ruled out the MariaDB update? That one seems the most likely to have triggered this regression. https://www.debian.org/security/2018/dsa-4341 (Not sure how reliably you got the list of loaded shared libraries; you seem to be running the prefork mpm so presumably only some of your apache processes will have the libraries loaded by the actual Perl application.) -- Niko Tyni nt...@debian.org
Re: Bug#849082: libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25
On Sat, Dec 24, 2016 at 07:02:26AM +0100, Stefan Fritsch wrote: > The problem is that the injected header lines only have a LF and no CR. I > suggest the attached patch. Oh! Silly of me, should've thought of that. Glad it was that easy. I'll apply this and upload a fixed package soon. Happy holidays & many thanks for your help and the great work you're doing for Debian! -- Niko
Re: Bug#849082: libapache2-mod-perl2: FTBFS: test failures with Apache 2.4.25
Control: retitle -1 libapache2-mod-perl2: FTBFS: test failures with Apache
2.4.25
Control: tag -1 patch
@apache2 maintainers (cc'd): it seems that mod_perl is no longer able
to 'inject headers' with apache2 2.4.25. See below. A workaround is to
explicitly configure the server for 'unsafe' behaviour. Is mod_perl just
doing something "wrong" at the moment, or is the whole feature something
that should not be possible anymore?
On Thu, Dec 22, 2016 at 05:17:34PM +0100, gregor herrmann wrote:
> On Thu, 22 Dec 2016 17:23:24 +0200, Niko Tyni wrote:
>
> > Package: libapache2-mod-perl2
> > Version: 2.0.10-1
> > Severity: serious
> From the apache2 changelog:
>
> * Security: CVE-2016-8743:
> Enforce HTTP request grammar corresponding to RFC7230 for request lines
> and request headers, to prevent response splitting and cache pollution by
> malicious clients or downstream proxies.
> * The stricter HTTP enforcement may cause compatibility problems with
> non-conforming clients. Fine-tuning is possible with the new
> HttpProtocolOptions directive.
Indeed, these changes seem to be the cause for the two new test failures.
> > # Failed test 1 in t/apache/read.t at line 52
> > request has failed (the response code was: 400)
This one is trivial: in t/apache/read.t
-for my $string ("POST $location http/1.0",
+for my $string ("POST $location HTTP/1.0",
Patch attached.
The other failure seems to be harder. The test is installing a "filter"
on the request headers and injecting new header lines on the server
side. The client code is t/filter/in_bbs_inject_header.t and the server
side is in t/filter/TestFilter/in_bbs_inject_header.pm.
# ./t/TEST -trace=debug t/filter/in_bbs_inject_header.t
[...]
request has failed (the response code was: 400)
see t/logs/error_log for more details
t/filter/in_bbs_inject_header.t .. Dubious, test returned 255 (wstat 65280,
0xff00)
Failed 36/36 subtests
>From t/logs/error_log:
[ debug] input filter called -
[ debug] filter read:
[
]
[ debug] END of original HTTP Headers
[ debug] queued header [X-Extra-Header2: Value 2
]
[ debug] queued header [X-Extra-Header3: Value 3
]
[ debug] queued header [
]
[ debug] injected header: [X-Extra-Header2: Value 2
]
[Fri Dec 23 16:05:28.968699 2016] [core:debug] [pid 15527:tid
139982245197568] protocol.c(957): (22)Invalid argument: [client
127.0.0.1:53182] Failed to read request header line X-Extra-Header2: Value 2
[Fri Dec 23 16:05:28.968717 2016] [core:debug] [pid 15527:tid
139982245197568] protocol.c(1313): [client 127.0.0.1:53182] AH00567: request
failed: error reading the headers
It looks to me like the server is checking back on the received request
and noticing that the injected header was not there originally. The
400 response is certainly not caused by anything in the request itself;
a plain GET request gets the same response as well.
This passage in RFC 7230, section 9.4., seems relevant:
A more effective mitigation is to prevent anything other than the
server's core protocol libraries from sending a CR or LF within the
header section, which means restricting the output of header fields to
APIs that filter for bad octets and not allowing application servers
to write directly to the protocol stream.
I would expect mod_perl to be classified as a 'core protocol library' in
this sense, but I have no idea yet if it's just doing something wrong.
Patch attached to revert to the old "unsafe" behaviour in the virtual
host specific to this test.
--
Niko Tyni nt...@debian.org
>From f4dd0394f0975892b51a889f023d0e207553a656 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Fri, 23 Dec 2016 18:27:23 +0200
Subject: [PATCH 1/2] Fix t/apache/read.t HTTP syntax for Apache 2.4.25
compatibility
HTTP/1.1 RFC 7230, section 2.6. "Protocol Versioning" says the HTTP name
is case sensitive. Starting with Apache 2.4.25, using lower case will
make the server issue a 400 Bad request response, causing a test failure.
https://tools.ietf.org/html/rfc7230#section-2.6
Bug-Debian: https://bugs.debian.org/849082
---
t/apache/read.t | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/apache/read.t b/t/apache/read.t
index 83670c9..9f7f504 100644
--- a/t/apache/read.t
+++ b/t/apache/read.t
@@ -24,7 +24,7 @@ close $fh;
my $size = length $data;
-for my $string ("POST $location http/1.0",
+for my $string ("POST $location HTTP/1.0",
"Content-length: $size",
"") {
my $line = "$string\r\n";
--
2.11.0
>From edd3ca5e9f2666e8e4936ac98446d94a5907c137 Mon Sep 17 00:00:00 2001
From: Niko Tyni <nt...@debian.org>
Date: Fri, 23 Dec 2016 18:31:01 +0200
Subject: [PATCH 2
Bug#820824: libapache2-mod-perl2: FTBFS: t/protocol/pseudo_http.t failure
On Mon, May 09, 2016 at 09:49:13PM +0300, Niko Tyni wrote: > I intend to disable the test in libapache2-mod-perl2 for now until > a better solution is found. Done in 2.0.9-5 which I just uploaded. > Do you want to track the apache2 crash > with this bug, or should we reassign it back? In the latter case feel free to reassign and close, or let me know and I'll do that. -- Niko
Bug#820824: libapache2-mod-perl2: FTBFS: t/protocol/pseudo_http.t failure
On Thu, Apr 14, 2016 at 07:48:47AM +0200, Stefan Fritsch wrote: > reassign 820824 apache2 > On Tuesday 12 April 2016 23:04:42, Niko Tyni wrote: > > Looking at the CI results at > > > > https://ci.debian.net/packages/liba/libapache2-mod-perl2/unstable/a > > md64/ this started happening between 2016-04-09 and 2016-04-10, > > probably with the apache2 2.4.18 -> 2.4.20 upgrade. > > > > I can get this to happen with just > > # ./t/TEST -verbose -httpd_conf $(pwd)/debian/apache2.conf > > t/protocol/pseudo_http.t > > > > and I see the Apache server process dies with SIGSEGV. Backtrace > > below. > > > > Cc'ing the Apache maintainers, seems to be a regression there? > > Seems likely. Reassigning to keep 2.4.20-1 from migrating to testing > for now. This is also https://mail-archives.apache.org/mod_mbox/httpd-dev/201604.mbox/%3CCACsi250G0azcA-XyJHGLxacpDEg_ezJ=taus31pyb7g_8-x...@mail.gmail.com%3E which says that while apache2 shouldn't crash, the mod_perl2 test is buggy and should be fixed. Unfortunately mod_perl2 upstream is very quiet these days, so nothing has happened so far on this front. I intend to disable the test in libapache2-mod-perl2 for now until a better solution is found. Do you want to track the apache2 crash with this bug, or should we reassign it back? Thanks, -- Niko Tyni nt...@debian.org
Bug#820824: libapache2-mod-perl2: FTBFS: t/protocol/pseudo_http.t failure
Package: libapache2-mod-perl2 Version: 2.0.9-4 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest X-Debbugs-Cc: apac...@packages.debian.org This package fails to build on current sid/amd64. # Failed test 3 in t/protocol/pseudo_http.t at line 59 # Failed test 4 in t/protocol/pseudo_http.t at line 64 t/protocol/pseudo_http.t Failed 11/13 subtests [...] Test Summary Report --- t/protocol/pseudo_http.t (Wstat: 13 Tests: 4 Failed: 2) Failed tests: 3-4 Non-zero wait status: 13 Parse errors: Bad plan. You planned 13 tests but ran 4. Looking at the CI results at https://ci.debian.net/packages/liba/libapache2-mod-perl2/unstable/amd64/ this started happening between 2016-04-09 and 2016-04-10, probably with the apache2 2.4.18 -> 2.4.20 upgrade. I can get this to happen with just # ./t/TEST -verbose -httpd_conf $(pwd)/debian/apache2.conf t/protocol/pseudo_http.t and I see the Apache server process dies with SIGSEGV. Backtrace below. Cc'ing the Apache maintainers, seems to be a regression there? Core was generated by `/usr/sbin/apache2 -d /home/niko/tmp/libapache2-mod-perl2/t -f /home/niko/tmp/li'. Program terminated with signal SIGSEGV, Segmentation fault. #0 apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, flags=flags@entry=0) at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663 663 /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c: No such file or directory. [Current thread is 1 (Thread 0x7fd44740d700 (LWP 13678))] (gdb) bt #0 apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, flags=flags@entry=0) at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663 #1 0x55feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, type=type@entry=3, str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990 #2 0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=, a=) at mod_access_compat.c:279 #3 0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332 #4 0x55feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87 #5 0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=) at HookRun.c:235 #6 0x7fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22 #7 0x7fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22 #8 0x7fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22 #9 0x7fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750, p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0) at modperl_callback.c:100 #10 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0, c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:236 #11 0x7fd44f91fd4f in modperl_callback_connection (idx=, c=, run_mode=) at modperl_callback.c:359 #12 0x55feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42 #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0) at connection.c:226 #14 0x7fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1, my_child_num=0, sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631 #15 worker_thread (thd=0x7fd453eb27a0, dummy=) at worker.c:990 #16 0x7fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334 #17 0x7fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 -- Niko Tyni nt...@debian.org
Bug#805737: libembperl-perl: FTBFS: apache2 crash during test suite
Package: libembperl-perl Version: 2.5.0-4 Severity: serious Tags: sid stretch X-Debbugs-Cc: apac...@packages.debian.org This package fails to build on current sid. Testing mod_perl mode... #0 ascii... ok #1 pure.htm...ERR:Status read failed: Connection reset by peer The test apache2 process is crashing with this backtrace: Core was generated by `/usr/sbin/apache2 -X -f /home/niko/tmp/libembperl-perl-2.5.0/test/conf/httpd.co'. Program terminated with signal SIGSEGV, Segmentation fault. #0 ap_mpm_pod_check (pod=0x0) at mpm_unix.c:459 459 mpm_unix.c: No such file or directory. (gdb) bt #0 ap_mpm_pod_check (pod=0x0) at mpm_unix.c:459 #1 0x7f280ff3cb17 in child_main (child_num_arg=child_num_arg@entry=0, child_bucket=child_bucket@entry=0) at prefork.c:732 #2 0x7f280ff3cd32 in make_child (s=0x7f2811a2c470, slot=slot@entry=0, bucket=bucket@entry=0) at prefork.c:767 #3 0x7f280ff3e292 in prefork_run (_pconf=, plog=0x7f2811a27028, s=0x7f2811a2c470) at prefork.c:979 #4 0x56038855f9ae in ap_run_mpm (pconf=0x7f2811a53028, plog=0x7f2811a27028, s=0x7f2811a2c470) at mpm_common.c:94 #5 0x560388559040 in main (argc=4, argv=0x7ffed5563c88) at main.c:777 This regressed with apache2 upgrade from 2.4.16-3 to 2.4.17-2, so I'm cc'ing the apache2 maintainers in case they have ideas. -- Niko Tyni nt...@debian.org
Re: Bug#711213: libapache2-mod-perl2: occasional core dumps after the test suite
On Fri, Jun 14, 2013 at 10:24:07AM +0200, Stefan Fritsch wrote:
The problem is that MP_CMD_SRV_DECLARE2(authz_provider) and
MP_CMD_SRV_DECLARE2(authn_provider) register the cleanup against
parms-server-process-pool which lives longer than the pconf pool
and therefore the load time of the mod-perl shared object. It should
probably use parms-pool (which is pconf) instead.
Now, if there is a good reason that the above functions use server-
process-pool, we need to figure out a way to fix that. But the
original commit of that code has no comment with respect to the pool
requirement. Therefore I think it may be simply a bug and you should
test it with a cleanup against pconf, first.
Thanks! The attached patch indeed fixes the problem for me without
introducing any new regressions in the test suite.
@pkg-perl: I'm away from my keys ATM; could somebody please upload
this? The ia64 problem (#711167) is still a mystery but I have high
hopes this at least fixes the armel buildd crashes.
--
Niko Tyni nt...@debian.org
From 75662f4285bad8d28fe787d1293bdd95a535cad1 Mon Sep 17 00:00:00 2001
From: Niko Tyni nt...@debian.org
Date: Fri, 14 Jun 2013 14:07:22 +0300
Subject: [PATCH] Make sure authn and authz providers are cleaned up in time
The authn and authz providers need to be registered in the configuration
pool rather than the server process pool. The latter outlives the load
time of the mod_perl shared object, so cleanup hooks could get called
after the registered functions were unloaded, causing SIGSEGVs and other
undefined behaviour.
Fix suggested by Stefan Fritsch.
Bug-Debian: http://bugs.debian.org/711213
---
src/modules/perl/modperl_cmd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/modules/perl/modperl_cmd.c b/src/modules/perl/modperl_cmd.c
index 4ae0a62..d14b330 100644
--- a/src/modules/perl/modperl_cmd.c
+++ b/src/modules/perl/modperl_cmd.c
@@ -419,7 +419,7 @@ MP_CMD_SRV_DECLARE(init_handlers)
MP_CMD_SRV_DECLARE2(authz_provider)
{
-apr_pool_t *p = parms-server-process-pool;
+apr_pool_t *p = parms-pool;
char *name = apr_pstrdup(p, arg1);
char *cb = apr_pstrdup(p, arg2);
@@ -431,7 +431,7 @@ MP_CMD_SRV_DECLARE2(authz_provider)
MP_CMD_SRV_DECLARE2(authn_provider)
{
-apr_pool_t *p = parms-server-process-pool;
+apr_pool_t *p = parms-pool;
char *name = apr_pstrdup(p, arg1);
char *cb = apr_pstrdup(p, arg2);
--
1.7.10.4
Re: Bug#711213: libapache2-mod-perl2: occasional core dumps after the test suite
On Sun, Jun 09, 2013 at 11:23:01PM +0300, Niko Tyni wrote: On Fri, Jun 07, 2013 at 02:23:43PM +0300, Niko Tyni wrote: I can reproduce the SIGSEGV at the end of the main test suite (#711213) on amd64. The armel problem might well be related, as the log ends at the same point. I'm somewhat further now: what happens is that register_auth_provider() in modperl_util.c calls apr_pool_pre_cleanup_register(pool, NULL, cleanup_perl_global_providers); once in the parent process, then another time in a child. For some reason that I do not understand yet, the cleanup_perl_global_providers() function resides at a different memory location (with a 0x2c000 offset or so) on the second time. The first location has at that point become an invalid memory address, resulting in a SIGSEGV when libapr calls the registered cleanup functions and jumps into the old location. Another progress report. I now mostly understand what's happening. Contrary to the above, all the interesting stuff happens inside the parent process. Cc'ing the apache2 maintainers; any ideas? See below. (The jump to an invalid address is crashing armel buildds so it's a rather big problem ATM. See #711167, where this has diverged.) First, apache2 main() calls read_config() (from main.c:624), which loads all the modules. Loading mod_perl installs the pre_cleanup hook cleanup_perl_global_providers() as above. Then, there's a loop starting at main.c:704 that has this comment: /* This is a hack until we finish the code so that it only reads * the config file once and just operates on the tree already in * memory. rbb */ and calls apr_pool_clear(pconf), which unloads the modules and should do all the cleanup AIUI. A bit later, at main.c:724, ap_read_config() is called again, and under some conditions (when stack limit is 'unlimited' and the number of modules is suitable?), mod_perl gets loaded at a different place than the first time. However, the earlier installed pre_cleanup hook is still in place, so we jump into an out-of-bounds location (where cleanup_perl_global_providers() used to reside) in the end when the cleanups are actually called. So I suppose mod_perl should somehow register a module uninstall hook that calls apr_pool_cleanup_run(..., cleanup_perl_global_providers, ...) [or apr_pool_cleanup_kill(), not sure] to remove the to-be-unloaded pre_cleanup hook. I haven't found a way to do that yet. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130614060941.GA4643@madeleine.local.invalid
Bug#652331: libapache2-mod-perl2: FTBFS with apache2-mpm-event: tests hang
Package: libapache2-mod-perl2 Version: 2.0.5-4 Severity: normal X-Debbugs-Cc: apache2-mpm-ev...@packages.debian.org When building libapache2-mod-perl2 with apache2-mpm-event instead of apache2-mpm-worker, the test suite hangs. The test order is randomized and the hanging test name isn't printed out when it hangs, but looking at the process list reveals at least these (from different attempts): t/error/runtime.t t/hooks/startup.t t/protocol/pseudo_http.t Given this paragraph in the apache2-mpm-event description: This MPM is experimental and less tested than the worker and prefork MPMs. I think that just a Build-Conflicts declaration would be an appropriate fix for this problem on the libapache2-mod-perl2 side. Ideally the issues should of course be investigated properly and fixed in the MPM code where applicable, but I'm not going to work on that. Cc'ing the apache2 maintainers. Feel free to clone/reassign if you want to track this. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111216094359.GA12924@madeleine.local.invalid
Re: Bug#636651: libapache2-mod-perl2: FTBFS with perl 5.14: -D_FILE_OFFSET_BITS stripped from CFLAGS
retitle 636651 libapache2-mod-perl2: FTBFS with perl 5.14: -D_FILE_OFFSET_BITS
stripped from CFLAGS
thanks
On Thu, Aug 04, 2011 at 10:01:52PM +0100, Dominic Hargreaves wrote:
Source: libapache2-mod-perl2
Version: 2.0.5-2
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.14-transition
As discussed on Debian bug #628522, this package fails to build with
perl 5.14.1 (in experimental) on i386 because $Config{ccflags} is being
overridden by local CCFLAGS options:
I'm afraid this one isn't quite that simple.
Not a CODE reference at /usr/lib/perl/5.14/DynaLoader.pm line 207.
As discussed in #624460 and in the thread at
http://www.nntp.perl.org/group/perl.perl5.porters/2011/04/msg171535.html
the binary interface skew that causes this error is a missing
-D_FILE_OFFSET_BITS=64 declaration, and it's missing because it's
explicitly stripped in Apache2::Build. Quoting:
# if perl is built with uselargefiles, but apr not, the build won't
# work together as it uses two binary incompatible libraries, so
# reduce the functionality to the greatest common denominator (C code
# will have to make sure to prevent any operations that may rely on
# effects created by uselargefiles, e.g. Off_t=8 instead of Off_t=4)
See strip_lfs() and has_large_files_conflict() in lib/Apache2/Build.pm.
If I understand this correctly, we have libapr built without large file
support and perl built with large file support. Now, mod_perl2 used to
do without LFS and still work with perl, but that's not the case with
Perl 5.14 anymore.
I'm Ccing the libapr1 maintainers for any ideas.
Dominic, could you try hardwiring has_large_files_conflict() to return 0
(so it doesn't strip the flags anymore) and see if that passes the test
suite on i386 with Perl 5.14?
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111015130920.GA1261@madeleine.local.invalid
Bug#482270: block 482207 with 482270, block 482262 with 482270
# Automatically generated email from bts, devscripts version 2.10.25+local block 482207 with 482270 # the bug is in libaprutil1-dev block 482262 with 482270 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
