Debian Bug report logs - #618462
php5: Use of systems' embedded timezone data causes performance regression

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Maciej Wiercinski <maciej@wiercinski.net>

To: submit@bugs.debian.org

Subject: php5: Use of systems' embedded timezone data causes performance regression

Date: Tue, 15 Mar 2011 11:52:24 +0000

Package: php5
Version: 5.3.5-1
Severity: normal
Patch use_embedded_timezonedb.patch, calls stat() on every single file in
/usr/share/zoneinfo upon first use of tje timezone data - in total over 600
syscalls. Example:
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 | grep
zoneinfo | head -10
     0.000110 open("/usr/share/zoneinfo/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
     0.000031 stat64("/usr/share/zoneinfo//localtime", {st_mode=S_IFREG|0644,
st_size=3661, ...}) = 0
     0.000061 stat64("/usr/share/zoneinfo//Zulu", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
     0.000055 stat64("/usr/share/zoneinfo//WET", {st_mode=S_IFREG|0644,
st_size=1873, ...}) = 0
     0.000055 stat64("/usr/share/zoneinfo//W-SU", {st_mode=S_IFREG|0644,
st_size=2194, ...}) = 0
     0.000056 stat64("/usr/share/zoneinfo//Universal", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
     0.000056 stat64("/usr/share/zoneinfo//UTC", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
     0.000054 stat64("/usr/share/zoneinfo//US", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
     0.000055 stat64("/usr/share/zoneinfo//UCT", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
     0.000054 stat64("/usr/share/zoneinfo//Turkey", {st_mode=S_IFREG|0644,
st_size=2721, ...}) = 0
Original discussion:
http://bugs.php.net/bug.php?id=54250


-- System Information:
Debian Release: wheezy/sid
Architecture: i386 (i686)
Kernel: Linux 2.6.31 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages php5 depends on:
ii  libapache2-mod-php5           5.3.5-1    server-side, HTML-embedded scripti
ii  php5-common                   5.3.5-1    Common files for packages built fr
php5 recommends no packages.
php5 suggests no packages.
-- no debconf information

Message #10 received at 618462@bugs.debian.org (full text, mbox, reply):

From: sean finney <seanius@debian.org>

To: Maciej Wiercinski <maciej@wiercinski.net>, 618462@bugs.debian.org

Subject: Re: [php-maint] Bug#618462: php5: Use of systems' embedded timezone data causes performance regression

Date: Tue, 15 Mar 2011 14:46:42 +0100

Hi Maciej,

Does this actually cause a quantifiable and significant performance
regression?  This possibility of performance issues was discussed some
time ago but it was decided that the stat calls would just hit the kernel
fs cache and not cause any serious problems.

If there are indeed problems, there are certainly ways this could be
worked around (building a binary cache kept up to date with the pkg
management system, for example), but it would add even further complexity
to the patch which we'd all prefer to avoid if possible.


To give you some extra background, since the PHP authors certainly have
their own take on the situation, but EVERY serious linux distribution
ships this patch in some form.  Redhat, Fedora, Debian, Ubuntu, SLES,
Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch.
So please keep that in mind when you here both sides of this argument :)


The problem is that when the OS distributors release a timezone update,
they don't want to *also* have to go package by package updating
indivudual and "customized" timezone databases that might be embedded
in a given application.  Neither do they want to continuously update the
version of PHP in their "stable" releases and have to deal with the numerous
regressions that would result.  The PHP tzdata changes are mixed in with the
mainline development, and sometimes depend on other changes within the
engine, so it's not really feasible to cherry pick out the changes into
a stable release, even if we wanted to.

This is a point of disagreement with the PHP authors, who want to have
control over this aspect of the engine themselves (and they certainly have
their justifications, such as systems with outdated or nonexistant tzdata,
plus they add some extra TZ annotations in their private copy).
Unfortunately they are interested in providing any other way to work
around this issue, despite the periodic overture from us or RedHat.
The invitation is still open to try and find a reasonable technical
solution for this, but I have been led to beleive that Derick has really
dug in his heels on the issue and it's not worth any of our time to
raise a big stink about it.



	sean

Message #15 received at 618462@bugs.debian.org (full text, mbox, reply):

From: Maciej Wiercinski <maciej@wiercinski.net>

To: sean finney <seanius@debian.org>

Cc: 618462@bugs.debian.org

Subject: Re: [php-maint] Bug#618462: php5: Use of systems' embedded timezone data causes performance regression

Date: Tue, 15 Mar 2011 15:40:28 +0000

Hi Sean,

I've spotted it while debugging system with misconfigured Apache2
prefork mpm. System kept spawning / killing processes at quite high
rate. Approximately 20% of the system time was spent in kernel mode,
of which my rough estimate (I have straced apache and its children,
not the whole system) is that 50% was spent on stat().

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 58.64   12.022001         446     26926      3275 stat
 23.83    4.884488        2429      2011       391 access
 15.42    3.160267          10    320599      1734 lstat

Another very rough estimate is that mentioned zoneinfo stat()s
accounted for about 80-85% of total stats(). When you sum it up you
will get a figure of less than 10% of CPU time.

Now the point is that the system was misconfigured, thus I could
expect performance fireworks. In light of this I wouldn't call this
issue critical, more a wishlist item.

I had a quick look through the code

 const timelib_tzdb *timelib_builtin_db(void)

is being called only twice in the main source tree and the actual use
is straightforward:

/* {{{ php_date_set_tzdb - NOT THREADSAFE */
PHPAPI void php_date_set_tzdb(timelib_tzdb *tzdb)
{
        const timelib_tzdb *builtin = timelib_builtin_db();

        if (php_version_compare(tzdb->version, builtin->version) > 0) {
                php_date_global_timezone_db = tzdb;
                php_date_global_timezone_db_enabled = 1;
        }
}
/* }}} */

It sounds feasible to try to rewrite it so it appends stuff to
timelib_tzdb->index as it's requested (with possible forced full read
on methods like timezone_abbreviations_list etc.). Are you aware of
any reasons why would you need the whole timezone index in the memory
(only thing I can think of is consistent indexing , as this data is
alpha sorted ) ?

Cheers,
Maciej


On Tue, Mar 15, 2011 at 1:46 PM, sean finney <seanius@debian.org> wrote:
> Hi Maciej,
>
> Does this actually cause a quantifiable and significant performance
> regression?  This possibility of performance issues was discussed some
> time ago but it was decided that the stat calls would just hit the kernel
> fs cache and not cause any serious problems.
>
> If there are indeed problems, there are certainly ways this could be
> worked around (building a binary cache kept up to date with the pkg
> management system, for example), but it would add even further complexity
> to the patch which we'd all prefer to avoid if possible.
>
>
> To give you some extra background, since the PHP authors certainly have
> their own take on the situation, but EVERY serious linux distribution
> ships this patch in some form.  Redhat, Fedora, Debian, Ubuntu, SLES,
> Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this patch.
> So please keep that in mind when you here both sides of this argument :)
>
>
> The problem is that when the OS distributors release a timezone update,
> they don't want to *also* have to go package by package updating
> indivudual and "customized" timezone databases that might be embedded
> in a given application.  Neither do they want to continuously update the
> version of PHP in their "stable" releases and have to deal with the numerous
> regressions that would result.  The PHP tzdata changes are mixed in with the
> mainline development, and sometimes depend on other changes within the
> engine, so it's not really feasible to cherry pick out the changes into
> a stable release, even if we wanted to.
>
> This is a point of disagreement with the PHP authors, who want to have
> control over this aspect of the engine themselves (and they certainly have
> their justifications, such as systems with outdated or nonexistant tzdata,
> plus they add some extra TZ annotations in their private copy).
> Unfortunately they are interested in providing any other way to work
> around this issue, despite the periodic overture from us or RedHat.
> The invitation is still open to try and find a reasonable technical
> solution for this, but I have been led to beleive that Derick has really
> dug in his heels on the issue and it's not worth any of our time to
> raise a big stink about it.
>
>
>
>        sean
>

Message #18 received at 618462-submitter@bugs.debian.org (full text, mbox, reply):

From: Filipus Klutiero <chealer@gmail.com>

To: 618462-submitter@bugs.debian.org

Subject: May be related with #571762

Date: Sat, 09 Jul 2011 17:38:49 -0400

Hi Maciej,
thanks for your report. I don't know if I'm experiencing this issue and 
I didn't look at the code at all, but reading this quickly makes me 
think a lot about #571762. Please see my message on 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571762#52 and those 
that follow. #571762 was solved in 5.3.2-1, but it's possible the 
solution causes a performance degradation in the order of what this bug 
talks about. I'm thinking that *maybe* the performance issue you 
identified is the result of a combination of the embedded timezone data 
patch and the patch for #571762.

If not, it would still be good to have these 2 reports in mind when 
thinking of a solution for this one.

Message #23 received at 618462@bugs.debian.org (full text, mbox, reply):

From: Erik Jacobson <azhrarn@underhanded.org>

To: Debian Bug Tracking System <618462@bugs.debian.org>

Subject: php5: Large quantities of timezone file stat() calls causing possible regression

Date: Mon, 05 Mar 2012 15:08:34 -0500

Package: php5
Version: 5.3.10-1
Severity: normal


Hi, while trying to narrow down possible causes of Apache child wait
states, I came across this possible issue with PHP apparently calling
stat() against the system timezone files repeatedly.  This bug seems to
be primarily with tz init/searching looking at *all* the timezone files
with a question as to if it's a performance impact.

My issue is related but slightly different.

On a loaded server with ~150 php page requests a second, I was showing
an unusual amount of stat() calls in a child strace like so:


www-data 27168  0.7  0.1 321968 21780 ?        SN   13:04   0:02  \_ /usr/sbin/apache2 -k start 

# strace -p 27168  -f -c 
Process 27168 attached - interrupt to quit 
  
^CProcess 27168 detached 
% time     seconds  usecs/call     calls    errors syscall 
------ ----------- ----------- --------- --------- ---------------- 
 33.95    0.042694           3     12898       375 stat 
 25.95    0.032636           1     42586           select 
  6.68    0.008394           3      2893           munmap 
  5.15    0.006479           0     21928           sendto  

Doing an strace dump and analyzing the stat calls pointed some at htaccess and include path
searches, but the vast majority were calls like so:

stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 
stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 
stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 
stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 
stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 
stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 
stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 
stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0

The above block of calls were contiguous, all in less then a second.
Blocks like the above seem to roll through more then once a minute, and
individual stat() calls to the same file seem to appear once every 10-20
syscalls. The above identical lookup is the vast majority of the listed
stat calls in strace.

This is in a SINGLE child thread, out of *hundreds* of active threads. 
The end result is thousands of stat calls a second.. To the same file.
Which never changes. And is never cached in APC. I haven't been able 
to test the above load with switching to UTC and hoping it doesn't 
try to lookup the file, as our current setup relies on local time for
certain operations (ugh).

I'm currently recompiling PHP to take advantage of their timezonedb lib,
and hoping it keeps everything in ram.  Either that or I put the
timezone directory in a ramdisk and hoping for the best.


-- System Information:
Debian Release: 6.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)

Versions of packages php5 depends on:
ii  libapache2-mod-php5           5.3.10-1   server-side, HTML-embedded scripti
ii  php5-common                   5.3.10-1   Common files for packages built fr

php5 recommends no packages.

php5 suggests no packages.

-- no debconf information

Message #28 received at 618462@bugs.debian.org (full text, mbox, reply):

From: Derick Rethans <derick@php.net>

To: Erik Jacobson <azhrarn@underhanded.org>, Debian Bug Tracking System <618462@bugs.debian.org>

Cc: debian-bugs-dist@lists.debian.org, Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>

Subject: Re: Bug#618462: php5: Large quantities of timezone file stat() calls causing possible regression

Date: Mon, 5 Mar 2012 21:56:55 +0000 (GMT)

On Mon, 5 Mar 2012, Erik Jacobson wrote:

> Hi, while trying to narrow down possible causes of Apache child wait
> states, I came across this possible issue with PHP apparently calling
> stat() against the system timezone files repeatedly.  This bug seems to
> be primarily with tz init/searching looking at *all* the timezone files
> with a question as to if it's a performance impact.

Just FYI, PHP-proper doesn't do this. It's a rogue patch by 
Debian/Redhat that causes the insane amount of stat calls.

cheers,
Derick

Message #33 received at 618462@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@debian.org>

To: Erik Jacobson <azhrarn@underhanded.org>, 618462@bugs.debian.org

Subject: Re: [php-maint] Bug#618462: php5: Large quantities of timezone file stat() calls causing possible regression

Date: Mon, 5 Mar 2012 23:41:42 +0100

Erik,

I have checked some of my all records and is there a chance that you
call timelib_timezone_id_is_valid() ?

I found this in my old records:

1. Added overhead when timezone is not set -> I don't think we should
really do anything in here. It's a simple matter of adding
date_default_timezone_set("xxx/yyy") to your application. After adding
this call PHP will use that value as first in guess_timezone().
However we could put something about it to README.Debian.

2. We call stat() everytime timelib_timezone_id_is_valid() is called.
That is adds some slowdown, but I don't really see a way how to fix
that unless you readahead all timezones, which will make PHP even more
slower (mainly at startup, but that happens basically every time with
non-threaded model).

O.

On Mon, Mar 5, 2012 at 21:08, Erik Jacobson <azhrarn@underhanded.org> wrote:
> Package: php5
> Version: 5.3.10-1
> Severity: normal
>
>
> Hi, while trying to narrow down possible causes of Apache child wait
> states, I came across this possible issue with PHP apparently calling
> stat() against the system timezone files repeatedly.  This bug seems to
> be primarily with tz init/searching looking at *all* the timezone files
> with a question as to if it's a performance impact.
>
> My issue is related but slightly different.
>
> On a loaded server with ~150 php page requests a second, I was showing
> an unusual amount of stat() calls in a child strace like so:
>
>
> www-data 27168  0.7  0.1 321968 21780 ?        SN   13:04   0:02  \_ /usr/sbin/apache2 -k start
>
> # strace -p 27168  -f -c
> Process 27168 attached - interrupt to quit
>
> ^CProcess 27168 detached
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  33.95    0.042694           3     12898       375 stat
>  25.95    0.032636           1     42586           select
>  6.68    0.008394           3      2893           munmap
>  5.15    0.006479           0     21928           sendto
>
> Doing an strace dump and analyzing the stat calls pointed some at htaccess and include path
> searches, but the vast majority were calls like so:
>
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
>
> The above block of calls were contiguous, all in less then a second.
> Blocks like the above seem to roll through more then once a minute, and
> individual stat() calls to the same file seem to appear once every 10-20
> syscalls. The above identical lookup is the vast majority of the listed
> stat calls in strace.
>
> This is in a SINGLE child thread, out of *hundreds* of active threads.
> The end result is thousands of stat calls a second.. To the same file.
> Which never changes. And is never cached in APC. I haven't been able
> to test the above load with switching to UTC and hoping it doesn't
> try to lookup the file, as our current setup relies on local time for
> certain operations (ugh).
>
> I'm currently recompiling PHP to take advantage of their timezonedb lib,
> and hoping it keeps everything in ram.  Either that or I put the
> timezone directory in a ramdisk and hoping for the best.
>
>
> -- System Information:
> Debian Release: 6.0
>  APT prefers unstable
>  APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
>
> Versions of packages php5 depends on:
> ii  libapache2-mod-php5           5.3.10-1   server-side, HTML-embedded scripti
> ii  php5-common                   5.3.10-1   Common files for packages built fr
>
> php5 recommends no packages.
>
> php5 suggests no packages.
>
> -- no debconf information
>
>
>
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint



-- 
Ondřej Surý <ondrej@sury.org>

Message #38 received at 618462@bugs.debian.org (full text, mbox, reply):

From: Erik Jacobson <azhrarn@underhanded.org>

To: Ondřej Surý <ondrej@debian.org>

Cc: 618462@bugs.debian.org

Subject: Re: [php-maint] Bug#618462: php5: Large quantities of timezone file stat() calls causing possible regression

Date: Tue, 6 Mar 2012 13:07:31 -0500

[Message part 1 (text/plain, inline)]

I wish it were easy as removing a function call, but as far as I can
tell, the only place we even use a function with "timezone" in it is in
one specific page that's rarely used.  We do use time() in many places,
but nothing else that I can find. :/

I did recompile php from upstream, and all the stat() issues went away.
The biggest syscall culprit now would be poll(), but there's not a whole
lot I can do about that.

On Mon, Mar 05, 2012 at 11:41:42PM +0100, Ondřej Surý wrote:
> Erik,
> 
> I have checked some of my all records and is there a chance that you
> call timelib_timezone_id_is_valid() ?
> 
> I found this in my old records:
> 
> 1. Added overhead when timezone is not set -> I don't think we should
> really do anything in here. It's a simple matter of adding
> date_default_timezone_set("xxx/yyy") to your application. After adding
> this call PHP will use that value as first in guess_timezone().
> However we could put something about it to README.Debian.
> 
> 2. We call stat() everytime timelib_timezone_id_is_valid() is called.
> That is adds some slowdown, but I don't really see a way how to fix
> that unless you readahead all timezones, which will make PHP even more
> slower (mainly at startup, but that happens basically every time with
> non-threaded model).
> 
> O.
> 
> On Mon, Mar 5, 2012 at 21:08, Erik Jacobson <azhrarn@underhanded.org> wrote:
> > Package: php5
> > Version: 5.3.10-1
> > Severity: normal
> >
> >
> > Hi, while trying to narrow down possible causes of Apache child wait
> > states, I came across this possible issue with PHP apparently calling
> > stat() against the system timezone files repeatedly.  This bug seems to
> > be primarily with tz init/searching looking at *all* the timezone files
> > with a question as to if it's a performance impact.
> >
> > My issue is related but slightly different.
> >
> > On a loaded server with ~150 php page requests a second, I was showing
> > an unusual amount of stat() calls in a child strace like so:
> >
> >
> > www-data 27168  0.7  0.1 321968 21780 ?        SN   13:04   0:02  \_ /usr/sbin/apache2 -k start
> >
> > # strace -p 27168  -f -c
> > Process 27168 attached - interrupt to quit
> >
> > ^CProcess 27168 detached
> > % time     seconds  usecs/call     calls    errors syscall
> > ------ ----------- ----------- --------- --------- ----------------
> >  33.95    0.042694           3     12898       375 stat
> >  25.95    0.032636           1     42586           select
> >  6.68    0.008394           3      2893           munmap
> >  5.15    0.006479           0     21928           sendto
> >
> > Doing an strace dump and analyzing the stat calls pointed some at htaccess and include path
> > searches, but the vast majority were calls like so:
> >
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> > stat("/usr/share/zoneinfo/America/New_York", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> >
> > The above block of calls were contiguous, all in less then a second.
> > Blocks like the above seem to roll through more then once a minute, and
> > individual stat() calls to the same file seem to appear once every 10-20
> > syscalls. The above identical lookup is the vast majority of the listed
> > stat calls in strace.
> >
> > This is in a SINGLE child thread, out of *hundreds* of active threads.
> > The end result is thousands of stat calls a second.. To the same file.
> > Which never changes. And is never cached in APC. I haven't been able
> > to test the above load with switching to UTC and hoping it doesn't
> > try to lookup the file, as our current setup relies on local time for
> > certain operations (ugh).
> >
> > I'm currently recompiling PHP to take advantage of their timezonedb lib,
> > and hoping it keeps everything in ram.  Either that or I put the
> > timezone directory in a ramdisk and hoping for the best.
> >
> >
> > -- System Information:
> > Debian Release: 6.0
> >  APT prefers unstable
> >  APT policy: (500, 'unstable')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
> >
> > Versions of packages php5 depends on:
> > ii  libapache2-mod-php5           5.3.10-1   server-side, HTML-embedded scripti
> > ii  php5-common                   5.3.10-1   Common files for packages built fr
> >
> > php5 recommends no packages.
> >
> > php5 suggests no packages.
> >
> > -- no debconf information
> >
> >
> >
> > _______________________________________________
> > pkg-php-maint mailing list
> > pkg-php-maint@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint
> 
> 
> 
> -- 
> Ondřej Surý <ondrej@sury.org>
> 

-- 
ICQ: 116080581 | Jabber: azhrarn@underhanded.org
AIM/Y!: AzhrarnLOD | IRC: Kross @ irc.escapistmagazine.com
( Vim, Tabs, BSD Braces, Debian, and Perl )

[signature.asc (application/pgp-signature, inline)]

Message #43 received at 618462-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 413713-done@bugs.debian.org,440775-done@bugs.debian.org,447764-done@bugs.debian.org,500087-done@bugs.debian.org,618462-done@bugs.debian.org,628079-done@bugs.debian.org,639268-done@bugs.debian.org,643282-done@bugs.debian.org,697800-done@bugs.debian.org,715264-done@bugs.debian.org,727143-done@bugs.debian.org,730067-done@bugs.debian.org,731055-done@bugs.debian.org,752100-done@bugs.debian.org,759195-done@bugs.debian.org,760454-done@bugs.debian.org,774154-done@bugs.debian.org,774975-done@bugs.debian.org,776564-done@bugs.debian.org,778596-done@bugs.debian.org,782778-done@bugs.debian.org,783246-done@bugs.debian.org,788060-done@bugs.debian.org,789442-done@bugs.debian.org,789702-done@bugs.debian.org,790472-done@bugs.debian.org,790841-done@bugs.debian.org,792239-done@bugs.debian.org,795572-done@bugs.debian.org,797799-done@bugs.debian.org,799136-done@bugs.debian.org,799851-done@bugs.debian.org,800564-done@bugs.debian.org,801831-done@bugs.debian.org,803260-done@bugs.debian.org,803305-done@bugs.debian.org,805591-done@bugs.debian.org,810244-done@bugs.debian.org,811130-done@bugs.debian.org,814907-done@bugs.debian.org,815794-done@bugs.debian.org,815797-done@bugs.debian.org,817917-done@bugs.debian.org,819139-done@bugs.debian.org,827486-done@bugs.debian.org,828498-done@bugs.debian.org,833133-done@bugs.debian.org,833543-done@bugs.debian.org,834579-done@bugs.debian.org,841618-done@bugs.debian.org,845890-done@bugs.debian.org,846244-done@bugs.debian.org,848661-done@bugs.debian.org,849767-done@bugs.debian.org,664595-done@bugs.debian.org,

Cc: php5@packages.debian.org, php5@packages.qa.debian.org

Subject: Bug#841781: Removed package(s) from unstable

Date: Fri, 13 Jan 2017 13:05:30 +0000

Version: 5.6.26+dfsg-1+rm

Dear submitter,

as the package php5 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/841781

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.