hi guys,
sorry to butt in here, but thought i'd have something to add/ask:
On Mon, 2007-05-21 at 15:49 -0500, Richard Lynch wrote:
>
> If I'm understanding this correctly, (and that's definitely debatable)
> there seems to be an awfully large "hole" there of being able to poke
> random bits of R
hi folks,
On Monday 28 May 2007 17:56:54 Wez Furlong wrote:
> I think we could do with investing a little bit of time into finding a
> way to automatically review commits to see if they have been merged to
> all relevant branches. For this to be viable, we should probably
> adopt the practice of
On Wednesday 20 June 2007 10:40:51 Gustaf Gunnarsson wrote:
> Hi,
> the following patch fixes memory leaks in the snmp module.
ftr, i've had memory leaks in snmp reported in debian as well:
http://bugs.debian.org/423296
though i'm not familiar enough with the code to comment on the patch
hi guys,
On Tuesday 03 July 2007 16:48:44 Rasmus Lerdorf wrote:
> That is still a binary compatibility break. Binary compatibility isn't
> just backwards, but also forwards within a major version. eg. if I
> build an extension against PHP 5.2.3 I expect it to also work in PHP
> 5.2.1 and it won'
hi,
On Tuesday 03 July 2007 17:36:07 Rasmus Lerdorf wrote:
> Dmitry Stogov wrote:
> > Btw I canot imagine extension that may use this new PG(in_user_include)
> > flag.
> > In any case the issue is not very critical and this patch may wait for
> > 5.3.
>
> If there really is no reason for an extens
hey guys,
i'm just going through the latest batch of CVE's and it doesn't look like
there's a fix for CVE-2007-4840 yet:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4840
Description
PHP 5.2.4 and earlier allows context-dependent attackers to cause a denial of
service (application c
On Tuesday 18 September 2007 09:54:05 pm Stanislav Malyshev wrote:
> > i'm just going through the latest batch of CVE's and it doesn't look like
> > there's a fix for CVE-2007-4840 yet:
>
> It's funny that glibc bug gets listed as PHP issue. But I think we may
> impose limit on charset length for i
hi stanislav,
(hope you don't mind i'm going to cc this off to a few addresses, no need to
keep them cc'd for further correspondance though)
On Tuesday 18 September 2007 10:56:16 pm Stanislav Malyshev wrote:
> > ah, so it's a glibc issue then? istr a similar thing come up with
> > truetype font
hi,
some non-php-dev comments in case they're helpful...
On Monday 15 October 2007 12:13:50 am Wez Furlong wrote:
> This bug has been open for a while:
> http://bugs.php.net/bug.php?id=27792
> Having run into this issue recently, here's a patch (hopefully
> attached, mail.app and list filters wi
hi,
On Monday 15 October 2007 09:26:30 am Stefan Esser wrote:
> please keep in mind that compiling PHP with large file support breaks
> binary compatibility...
> One of the globals contain a "stat" struct that has different size for
> LFS or no LFS.
yes, this is of course a big deal for some peop
hi,
On Monday 15 October 2007 07:41:11 pm Stanislav Malyshev wrote:
> I didn't dive yet too deep into the patch, but shouldn't it be fixed on
> stream level and not function level? I.e. there are a lot of functions
> using streams (including files) - would they support bigger files too?
i would s
hi stanislav,
On Wednesday 17 October 2007 02:08:06 am Stanislav Malyshev wrote:
> > yes, this is of course a big deal for some people, esp if you're using
> > proprietary software that's built against the "original" abi. of course
> > if you're only using OSS extensions, you can simply recompile
On Tuesday 16 October 2007 04:37:57 pm Wez Furlong wrote:
> PHP's native integer type is long, how else are you going to relay
> numbers longer than a long back to the script without rewriting the
> engine to add additional integer types, which is a massive changeset?
okay, chalk this up to my IAN
On Wednesday 17 October 2007 09:13:03 am Stanislav Malyshev wrote:
> Of course. If there are two different PHP versions with different API
> numbers, it's OK. What's less OK is when there's two PHP builds with
> same API numbers which are binary incompatible.
right.
> > in the context of running
7; packages... wouldn't it be
possible to at least make this some kind of compile-time option for those of
us who do like the idea?
sean finney
(debian php package maintainer)
signature.asc
Description: This is a digitally signed message part.
hi derick,
On Thursday 10 January 2008 09:50:14 am Derick Rethans wrote:
> > Personally I think this patch would be great, and I will recommend it to
> > the other debian php maintainers for review.
>
> Let me just remind you:
> This patch BREAKS functionality.
which of course should be avoided i
hey pierre,
(removed some folks from the cc)
On Thursday 10 January 2008 11:22:52 am Pierre wrote:
> Besides the issues listed by Derick, there is two problems with these
> choices (distro making design changes to upstream software). First it
that's sort of the point of open-source software, tho
Hi Clint,
On Sat, Feb 04, 2012 at 11:20:24AM -0800, Clint Byrum wrote:
> I think a more interesting discussion than the current one of "who
> plays nice with whom" and "why I don't like your processes", is whether
> anyone other than Stefan would be willing to champion RFCs for all of
> the Suhosi
hey all,
a quick introduction: i'm one of the folks maintaining the debian
php4/php5 packages. we're currently on the cusp of cutting a new stable
release "etch" (funny, i'd *swear* we've been saying that since
december...), which will include the second-to-most-recent releases of
4.4.x and 5.2.
hi,
On Tue, Feb 17, 2009 at 02:02:35AM -0500, Eric Stewart wrote:
> 14. A few other directives have been question but I don't have enough
> experience with these particular settings so please weight in on them.
>
> extension_dir = "./"
> enable_dl = On
i'd be incredibly weary of this setting, ev
hi greg,
On Sun, Apr 19, 2009 at 05:56:46PM -0500, Greg Beaver wrote:
> blasted piece of scripting doesn't work:
>
> @if test "a$(program_prefix)" != "a"; then \
>PEAR_PREFIX = " -dp php_prefix=$(program_prefix)"; \
> fi
> @if test "a$(program_suffix)" != "a"; then \
>PEAR_SUFFIX = " -ds p
hi everyone,
(if there's a better place to ask this, my apologies and feel free to
redirect me!)
does anyone know here if there is any machine-friendly interface to
the php bug tracking system?
in debian we have a service called "bts-link"[1] which we can use to track
"forwarded" bugs in remote
hi david,
On Mon, Jul 13, 2009 at 03:38:04PM -0400, David Soria Parra wrote:
> svn.php.net repository using git-svn. As this operation will retrieve
> every version in the repository, we decided to offer a semi-official git
> mirror.
>
> This mirror will be hosted on the php.net infrastructure, s
On Wed, Sep 09, 2009 at 03:42:44AM +0100, dreamcat four wrote:
> > Not sure about bundling libevent though - does it have to be bundled?
> Don't know. Libevent is frozen in there and a couple of files were
> modified with references back into the fpm headers.
> The Libevent was updated recently any
On Wed, Sep 09, 2009 at 10:46:53AM +0300, Jani Taskinen wrote:
> Yeah, NO THANKS. We have enough of unmaintained code already. Since
> you want this fpm thing into upstream PHP releases, why not make the
> changes into libevent go upstream as well and then reconsider
> bundling, merging, etc.
that
hi everyone,
sorry to drag something from the bug system onto the ML, but i'm unable
to comment on the closed bug. furthermore, the topic was already brought
up in the "strol for int parsing" thread, so i dare say that it is
relevant :)
afaict the bug in question is closed and marked bogus/dupli
On Thu, Mar 18, 2010 at 11:37:09PM +0100, Pierre Joye wrote:
> While wondering what was the reasoning behind this commit, I came to
> the conclusion that we should not do such thing in stable branches and
> we should respect something we decided long time ago, to stop to add
> bad options which can
On Tue, Mar 23, 2010 at 10:01:20PM +, Michael Maclean wrote:
> The patch:
> http://mgdm.net/~michael/patches/php-fnv.txt
just to throw something out there, shouldn't the various inputLen
parameters be of type size_t instead of unsigned int?
sean
signature.asc
Description: Digital
On Tue, Mar 23, 2010 at 11:18:09PM +, Michael Maclean wrote:
> >just to throw something out there, shouldn't the various inputLen
> >parameters be of type size_t instead of unsigned int?
>
> The function signature in php_hash.g says unsigned int, so that's
> what I used (though I note some of
On Wed, Mar 24, 2010 at 10:26:45AM +0100, Pierre Joye wrote:
> As far as I can tell that's not only for the hash module. Many areas
> in php and its libraries rely on (u)int instead of size_t. It is or
> was a common mistake. The problem is to change the signature now
> without breaking ABI.
>
> T
hi florian,
On Sat, Mar 27, 2010 at 03:28:39PM +0100, Florian Anderiasch wrote:
> The core differences I'm seeing here is:
>
> - DPL (Debian Project Leader) != PHP RM (Release Manager)
> It's actually not even remotely comparable.
what would be more comparable would be the debian RM('s). and
On Mon, Jul 12, 2010 at 03:50:19PM +0200, Reindl Harald wrote:
> It would be really relaxter if there are easy patches
> available which i could use in rpm-spec-file in a way
> like the following - the orinial source-tarball is
> unchanged and rpmbuild applys the patches diectly before
> build
whi
On Mon, Mar 21, 2011 at 11:06:28PM -0600, Raphael Geissert wrote:
> It's easy to understand the wish of hacking libmagic to provide some more
> features, but it would be great to keep the divergence to the strict
> minimum.
And ideally we could find some kind of technical solution/compromise tha
Hi,
On Sun, Oct 02, 2011 at 05:56:10PM +0200, Reindl Harald wrote:
> Am 02.10.2011 17:28, schrieb Lars Nielsen:
> no - complain to debian!
Or don't bother complaining at all, it's already been discussed ad naseum.
Furthermore AIUI it's semi-moot in the latest debian/ubuntu packages as
Pierre has
On Sun, Oct 02, 2011 at 07:34:28PM +0200, Reindl Harald wrote:
> i do now know from where what source is, but i use the packages from
> fedora for my own php-builds and gd is wroking like a charme
>
> so if this doe snot work on debian THEY make something wrong
TTBOMK (i.e. there have not been an
On Sun, Oct 23, 2011 at 03:36:04PM -0700, Clint Byrum wrote:
> I appreciate the sentiments of all who have weighed in on this, and I
> do want to make sure that we are paying attention to the greater PHP
> community's needs, not just Ubuntu's users. Shipping really old PHP
> versions is definitely
hi everyone,
sorry for digging up this dead horse...
On Thursday 10 January 2008 01:05:35 pm Joe Orton wrote:
> On Wed, Jan 09, 2008 at 09:03:02PM +0100, Derick Rethans wrote:
> > On Wed, 9 Jan 2008, Joe Orton wrote:
> > > It's a bit of a maintenance headache for distributions when
> > > packages
hi,
On Thursday 27 March 2008 10:26:57 pm Richard Lynch wrote:
> Just recently, somebody wondered why PHP had the CORRECT time when
> their web-server didn't...
and vice versa. see for example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471104
if there were an *option* for php to
hiya,
sorry to jump in a little late here,
On Tuesday 13 May 2008 09:03:08 pm Stanislav Malyshev wrote:
> > So if you think the multi-path extension_dir= change isn't going to be
> > accepted to PHP53, I might as well stop right here.
>
> I don't know - it depends how broad is the need for it and
hi barry,
oops, guess this one got lost under the pile for a bit...
On Monday 26 May 2008 12:50:08 pm Barry Carlyon wrote:
> So please add anything you would like to see in the bug tracker to the
> specs page.
> If you have any questions or wish to discuss anything I can currently be
> found on
hi there,
On Tue, Oct 14, 2008 at 09:55:27AM +0200, Pierre Joye wrote:
> On Tue, Oct 14, 2008 at 8:46 AM, Krister Karlström
> <[EMAIL PROTECTED]> wrote:
> > About this bug #44872, I run my small sample script (posted on the bug
> > reporting page) through valgrind and got the attached output. I'm
hi,
(wow, de-lurking twice in one day!)
On Tue, Oct 14, 2008 at 04:06:11PM +0200, Johannes Schlüter wrote:
> The last time it was discussed it was said we can't easily turn it on
> globally as it would interfere with "small" stat pointer received by
> Apache and others, nobody proposed a patch an
hi everyone,
i'm looking for a sanity check here, as i've already lost more time than
i'd like chasing ghosts on my treasure hunt through {bugs,lists,cvs}.php.net :(
afaict, CVE-2008-5658[1] is only half-fixed on 5.2.8, while it was supposed
to be fixed in 5.2.7.
while the zip library no longe
hi pierre
sorry, was already asleep when you came looking for me on IRC :)
On Wed, Jan 21, 2009 at 11:25:21PM +0100, Pierre Joye wrote:
> it is fixed in 5.2.7RC2 or RC3, see:
> http://cvs.php.net/viewvc.cgi/php-src/ext/zip/php_zip.c?r1=1.1.2.43&r2=1.1.2.44
FSVO "fixed" that includes segfaulting,
hi pierre,
i've tested the patch that you proposed via IRC (attached) and it seems
to work for me against 5.2.8. passes valgrind too, without any detected
errors or leaks.
it's unfortunate that there isn't a more surgical fix (301 insertions!),
but i'll take your word for it that it would be too
hi again,
On Fri, Jan 23, 2009 at 08:23:59AM +0100, sean finney wrote:
> it's unfortunate that there isn't a more surgical fix (301 insertions!),
> but i'll take your word for it that it would be too complicated/dangerous
> to try and modify virtual_file_ex() directly.
hi everyone,
On Sat, Jan 24, 2009 at 11:40:08AM -0500, Ilia Alshanetsky wrote:
> I think our bug current tracker is pretty good and most importantly
> makes it easy to report and update bugs which is conducive to more
> issues being reported. Often extra features of bug trackers make them
>
On Sun, Jan 25, 2009 at 02:17:31PM +, ba...@barrycarlyon.co.uk wrote:
> In that case why wasn't this pointed out last year, and I could of done
> something more useful with my GSoC time last year..
http://markmail.org/message/daf4zi5dfktv7jjt
sean
signature.asc
Description: Dig
48 matches
Mail list logo
