[php-maint] [Pkg-php-commits] r1243 - php5/branches/etch/debian
steffen.joeris at skolelinux.de
Mon Apr 20 09:14:45 UTC 2009
> On Wed, Jan 28, 2009 at 09:05:13AM +0100, Thijs Kinkhorst wrote:
> > > * Backport the patch from lenny/sid to use the system timezone
> > > database instead of the embedded php timezone database which is out of
> > > date. Patch: 143-use_embedded_timezonedb.patch (closes: #471104). *
> > > Repack the etch version of php5, stripping out the (unused) dbase
> > > module which contained licensing problems (closes: #498621).
> > Are you planning on letting this upload go through stable-security?
> > Because the changes listed above are not changes that are usually
> > considered appropriate for the security archive. Especially the latter
> > change changes the behaviour of php5 on stable which is not something
> > expected to happen with a mere security update.
> I was planning on *proposing* it to go along with a security upload. It's
> work that needs to be done, but once done can be removed and added back in
> for a later s-p-u package if that's necessary.
> the former change is the more controversial of the two and brings a pretty
> hefty chunk of code along with it, but the patch is fairly well tested and
> not too different from the version in testing/unstable (i had massage it
> just a little to remove some fuzz), and a similar variant is in use by
> redhat (from whom the patch came) in older versions of php5.
> the latter change should not have any affect on packages that we ship,
> as we don't provide any dbase related stuff.
> > I think an upload to security with the security fixes and after its
> > release one to stable with the other fixes may be the best way to go.
> > CC'ing the security team in case anyone has further comments.
> it would be creating some additional work due to the extra steps, but i'm
> willing to do that if that's what's required.
> On Wed, Jan 28, 2009 at 12:33:30PM -0600, Raphael Geissert wrote:
> > I can't speak for Sean, but doing that IMHO would be suboptimal and
> > too much hassle. In the event that somebody actually builds the dbase
> > extension by hand, they could keep using the one they have previously
> > built, it won't break at all.
> and i'm not sure this is a corner case we should go out of our way to
> support, given that this is a pretty clear-cut licensing issue that needs
> to be resolved.
> On Wed, Jan 28, 2009 at 07:51:09PM +0100, Moritz Muehlenhoff wrote:
> > > I think an upload to security with the security fixes and after its
> > > release one to stable with the other fixes may be the best way to go.
> > > CC'ing the security team in case anyone has further comments.
> > Since the next php5 stable-security update after the stable update will
> > incorporate the changes from the stable update anyway, this seems like a
> > waste of ressources. We should treat ever-moving packages like PHP or the
> > kernel in a more reasonable way and just announce in the DSA that the
> > update incorporates changes, which would be added in the next point
> > update anyway.
> okay... i have a few more open security issues against the etch packages
> (and then there's the oft-neglected php4...), but i'll keep the patch
> included for the time being and bring up the matter again once the
> package is prepared. due to the above mentioned hardware problems i'm
> a bit behind where i'd like to be, but hopefully i'll be able to have
> something RSN.
What's the status of an update for stable-security and oldstable-security?
Some other issues came up, please see the respective entries on the sides
. I'll take care of php-json-ext for etch now, but it would be good to get
new php5 packages out for (old)stable. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the pkg-php-maint