Bug #53881 [Wfx]: nl2.php.net IPv6 broken
Edit report at https://bugs.php.net/bug.php?id=53881&edit=1 ID: 53881 User updated by:tozz at kijkt dot tv Reported by:tozz at kijkt dot tv Summary:nl2.php.net IPv6 broken Status: Wont fix Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant Assigned To:danbrown Block user comment: N Private report: N New Comment: I understand IPv6 is not a requirement. However, some mirrors do have an -Address but fail to provide working connectivity to that address. The net result is that the PHP website is down for anyone with IPv6 connectivity if he/she is redirected to a mirror with bad IPv6 connectivity. So either the records should be removed or PHP.net should require mirrors to have decent IPv6 connectivity. Previous Comments: [2012-05-15 21:04:28] danbr...@php.net At this time, we do not require IPv6 capabilities on official php.net mirrors. We will begin to phase-in this requirement once the majority of the ISPs and NOCs which host the official mirrors have IPv6 support permanently enabled, and expect to see an increase in that number on 6 June, 2012 (World IPv6 Day), as is the norm each year. Thank you for submitting this report. [2011-01-30 00:04:33] tozz at kijkt dot tv IPv6 traceroute to the SinnerG broken mirror (to indicate its not a routing issue on my side): # traceroute6 2a00:f10:111::1337:1000 traceroute to 2a00:f10:111::1337:1000 (2a00:f10:111::1337:1000) from 2a01:1b0:7999:402::3, 30 hops max, 24 byte packets 1 2a01:1b0:7999:402::e (2a01:1b0:7999:402::e) 0.854 ms 0.952 ms 0.99 ms 2 2a01:1b0:2:6::1 (2a01:1b0:2:6::1) 4.985 ms 4.979 ms 4.991 ms 3 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 5.987 ms 5.968 ms 5.99 ms 4 tengig-1-1-0.bcr2.ams02.nl.as25525.net (2001:7f8:1::a502:5525:1) 6.987 ms 5.974 ms 5.988 ms 5 2001:16f8:bb2:197:0:a504:8635:2 (2001:16f8:bb2:197:0:a504:8635:2) 6.989 ms 7.972 ms 6.99 ms 6 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 6.987 ms 6.977 ms 6.99 ms 7 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 3010.85 ms !H 3010.81 ms !H 3007.83 ms !H [2011-01-29 23:58:16] tozz at kijkt dot tv Description: nl.php.net has some records which are very often broken (currently 2 out of 3 are broken). From what I've read PHP checks its mirrors on regular intervals, but apparently does not check if both IP4 and IP6 work. The lack of this IPv6 check causes the PHP website to load very slow as it waits a few seconds for a timeout on v6 and then falls back to v4. Perhaps this check can be extended to also check for correct IPv6 function and remove the mirror if its IPv6 connectivity is broken. Test script: --- # date Sat Jan 29 23:20:16 CET 2011 # telnet -6 nl2.php.net 80 Trying 2a01:448:1::1036:64:164... telnet: Unable to connect to remote host: Connection refused # telnet -6 nl.php.net 80 Trying 2a00:f10:111::1337:1000... telnet: Unable to connect to remote host: No route to host Expected result: I would expect that the PHP mirror check removes mirrors that have broken v6 connectivity. -- Edit this bug report at https://bugs.php.net/bug.php?id=53881&edit=1
Bug #53881 [Opn]: nl2.php.net IPv6 broken
Edit report at http://bugs.php.net/bug.php?id=53881&edit=1 ID: 53881 User updated by:tozz at kijkt dot tv Reported by:tozz at kijkt dot tv Summary:nl2.php.net IPv6 broken Status: Open Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: IPv6 traceroute to the SinnerG broken mirror (to indicate its not a routing issue on my side): # traceroute6 2a00:f10:111::1337:1000 traceroute to 2a00:f10:111::1337:1000 (2a00:f10:111::1337:1000) from 2a01:1b0:7999:402::3, 30 hops max, 24 byte packets 1 2a01:1b0:7999:402::e (2a01:1b0:7999:402::e) 0.854 ms 0.952 ms 0.99 ms 2 2a01:1b0:2:6::1 (2a01:1b0:2:6::1) 4.985 ms 4.979 ms 4.991 ms 3 bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2) 5.987 ms 5.968 ms 5.99 ms 4 tengig-1-1-0.bcr2.ams02.nl.as25525.net (2001:7f8:1::a502:5525:1) 6.987 ms 5.974 ms 5.988 ms 5 2001:16f8:bb2:197:0:a504:8635:2 (2001:16f8:bb2:197:0:a504:8635:2) 6.989 ms 7.972 ms 6.99 ms 6 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 6.987 ms 6.977 ms 6.99 ms 7 2a00:f10:10a:2::4 (2a00:f10:10a:2::4) 3010.85 ms !H 3010.81 ms !H 3007.83 ms !H Previous Comments: [2011-01-29 23:58:16] tozz at kijkt dot tv Description: nl.php.net has some records which are very often broken (currently 2 out of 3 are broken). From what I've read PHP checks its mirrors on regular intervals, but apparently does not check if both IP4 and IP6 work. The lack of this IPv6 check causes the PHP website to load very slow as it waits a few seconds for a timeout on v6 and then falls back to v4. Perhaps this check can be extended to also check for correct IPv6 function and remove the mirror if its IPv6 connectivity is broken. Test script: --- # date Sat Jan 29 23:20:16 CET 2011 # telnet -6 nl2.php.net 80 Trying 2a01:448:1::1036:64:164... telnet: Unable to connect to remote host: Connection refused # telnet -6 nl.php.net 80 Trying 2a00:f10:111::1337:1000... telnet: Unable to connect to remote host: No route to host Expected result: I would expect that the PHP mirror check removes mirrors that have broken v6 connectivity. -- Edit this bug report at http://bugs.php.net/bug.php?id=53881&edit=1
[PHP-BUG] Bug #53881 [NEW]: nl2.php.net IPv6 broken
From: Operating system: Irrelevant PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Bug Bug description:nl2.php.net IPv6 broken Description: nl.php.net has some records which are very often broken (currently 2 out of 3 are broken). From what I've read PHP checks its mirrors on regular intervals, but apparently does not check if both IP4 and IP6 work. The lack of this IPv6 check causes the PHP website to load very slow as it waits a few seconds for a timeout on v6 and then falls back to v4. Perhaps this check can be extended to also check for correct IPv6 function and remove the mirror if its IPv6 connectivity is broken. Test script: --- # date Sat Jan 29 23:20:16 CET 2011 # telnet -6 nl2.php.net 80 Trying 2a01:448:1::1036:64:164... telnet: Unable to connect to remote host: Connection refused # telnet -6 nl.php.net 80 Trying 2a00:f10:111::1337:1000... telnet: Unable to connect to remote host: No route to host Expected result: I would expect that the PHP mirror check removes mirrors that have broken v6 connectivity. -- Edit bug report at http://bugs.php.net/bug.php?id=53881&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53881&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53881&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53881&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53881&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53881&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53881&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53881&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53881&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53881&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53881&r=support Expected behavior: http://bugs.php.net/fix.php?id=53881&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53881&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53881&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53881&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53881&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53881&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53881&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53881&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53881&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53881&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53881&r=mysqlcfg
#23808 [Com]: Different behaviour of gd in blend images with 4.3.2rc4 than 4.3.1
ID: 23808 Comment by: tozz at kijkt dot tv Reported By: i dot a at signalsystem-bz dot it Status: Closed Bug Type: GD related Operating System: Win2k server PHP Version: 4.3.2RC4 New Comment: I just upgraded to 4.3.3RC1, and the problem is still there. The problem is a bit different now. In my previous report the blending went wrong, and the image looked like crap. Now the image is not blend at all, its just on top of the other image. Looks like this bug is not fixed, or it has not been fixed in 4.3.3RC1! Previous Comments: [2003-07-02 06:26:15] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Hello, Fixed in both php5 and php 4.3 branches. Merci Christophe :) pierre [2003-07-01 16:34:54] christophe dot bidaux at netcourrier dot com i made new tests with several php versions and i've putted the results on this page : http://christophe.bidaux.free.fr/imagecopymerge/imagecopymerge.html the first image is the original image and the others are made with the same php program shown at the bottom. the php version is written in the top-left corner of the images. only the 4.3.1 version gives me a good result. i use the binaries as they are and i use the same php.ini for all my tests. i run php on an Apache/1.3.20 Server on Windows 98. [2003-06-03 07:35:26] tozz at kijkt dot tv I experience the same bug on Linux with PHP 4.3.2, on PHP 4.3.1 everything works fine. Configure line: './configure' '--with-apxs' '--with-mysql' '--enable-ftp' '--with-openssl' '--with-gd' '--enable-bcmath' '--enable-dbase' '--with-freetype-dir' '--with-ttf' '--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--with-zlib-dir=/usr/lib/' The code: imagecopymerge ($board, $pawn, $w1, $h1, 0, 0, $w, $h, 30); imagecopymerge ($board, $pawn, $w2, $h2, 0, 0, $w, $h, 30); imagedestroy ($pawn); Imagejpeg($board,'',100); [2003-06-03 02:01:27] i dot a at signalsystem-bz dot it I putted the images as you requested .. http://signalsystem.merseine.nu/test/ image1.jpg is the main image; image2.png is the image that's "slitted" in trasnparency over the first image_431.jpg is the result of it in 4.3.1 (nice and good) image_432.jpg is the result of it in 4.3.2 (wrong and ugly) [2003-06-01 04:28:05] phpuser at panoramas dot de I was going to file this as a new bug, but thought i'd rather add it here, since it's the same basic problem: After upgrading to 4.3.2, the imagecopymerge function is broken. Reverting to 4.3.1 removes the error. My configure line: (unchanged since 4.3.1) './configure' '--with-mysql' '--prefix=/mysrv/php' '--enable-ftp' '--with-apxs=/mysrv/apache/sbin/apxs' '--with-config-file-path=/mysrv/php-conf' '--disable-pear' '--enable-track-vars' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local' '--disable-cli' '--with-t1lib=/usr/local' Summary of script function: - Takes one image A from file (JPEG 24bit). - generates another image B with same dimensions, 24 bit, and fills it with 50 percent gray - (left out: gets a set of imagemap coordinates from a database and draws them as black outline, white area inside the image B) - merges image B on top of image A with 40 percent transparency - returns the result. Effect of error: No blending occurs with 4.3.2. Only image B is returned, albeit "weaker" or "stronger" depending on the transparency setting in imagecopymerge(). Leaving out the imagecopymerge() command returns the original image A, as expected. Moving the coordinates results in a black background being visible (should be image A). My unqualified guess: Looks as if imagecopymerge() takes a black image instead of image A. Side notes: replacing imagecopymerge with imagecopymergegray actually returns the both images overlaid, but with pa
#23808 [Com]: Different behaviour of gd in blend images with 4.3.2rc4 than 4.3.1
ID: 23808
Comment by: tozz at kijkt dot tv
Reported By: i dot a at signalsystem-bz dot it
Status: Open
Bug Type: GD related
Operating System: Win2k server
PHP Version: 4.3.2RC4
New Comment:
I experience the same bug on Linux with PHP 4.3.2, on PHP 4.3.1
everything works fine.
Configure line:
'./configure' '--with-apxs' '--with-mysql' '--enable-ftp'
'--with-openssl' '--with-gd' '--enable-bcmath' '--enable-dbase'
'--with-freetype-dir' '--with-ttf' '--with-jpeg-dir=/usr/lib'
'--with-png-dir=/usr/lib' '--with-zlib-dir=/usr/lib/'
The code:
imagecopymerge ($board, $pawn, $w1, $h1, 0, 0, $w, $h, 30);
imagecopymerge ($board, $pawn, $w2, $h2, 0, 0, $w, $h, 30);
imagedestroy ($pawn);
Imagejpeg($board,'',100);
Previous Comments:
[2003-06-03 02:01:27] i dot a at signalsystem-bz dot it
I putted the images as you requested ..
http://signalsystem.merseine.nu/test/
image1.jpg is the main image;
image2.png is the image that's "slitted" in trasnparency over the
first
image_431.jpg is the result of it in 4.3.1 (nice and good)
image_432.jpg is the result of it in 4.3.2 (wrong and ugly)
[2003-06-01 04:28:05] phpuser at panoramas dot de
I was going to file this as a new bug, but thought i'd rather add it
here, since it's the same basic problem:
After upgrading to 4.3.2, the imagecopymerge function is broken.
Reverting to 4.3.1 removes the error.
My configure line: (unchanged since 4.3.1)
'./configure' '--with-mysql' '--prefix=/mysrv/php' '--enable-ftp'
'--with-apxs=/mysrv/apache/sbin/apxs'
'--with-config-file-path=/mysrv/php-conf' '--disable-pear'
'--enable-track-vars' '--with-gd' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local'
'--disable-cli' '--with-t1lib=/usr/local'
Summary of script function:
- Takes one image A from file (JPEG 24bit).
- generates another image B with same dimensions, 24 bit, and fills it
with 50 percent gray
- (left out: gets a set of imagemap coordinates from a database and
draws them as black outline, white area inside the image B)
- merges image B on top of image A with 40 percent transparency
- returns the result.
Effect of error:
No blending occurs with 4.3.2. Only image B is returned, albeit
"weaker" or "stronger" depending on the transparency setting in
imagecopymerge().
Leaving out the imagecopymerge() command returns the original image A,
as expected.
Moving the coordinates results in a black background being visible
(should be image A).
My unqualified guess:
Looks as if imagecopymerge() takes a black image instead of image A.
Side notes:
replacing imagecopymerge with imagecopymergegray actually returns the
both images overlaid, but with palette image color mixup effects.
Example source code
(requires a jpeg image "test.jpg" of arbitrary size to test)
-- begin code --
$uim = imagecreatefromjpeg("test.jpg")
or die ("Cannot Initialize new GD image stream");
imagealphablending ($uim, TRUE ); # leaving this out changes nothing
fill overlay with gray
$im = imagecreatetruecolor( imagesx($uim) , imagesy($uim) ); #
Overlay-Bild
$migra=imagecolorallocate ($im, 128,128,128);
imagefilledrectangle ( $im , 0,0 , imagesx($im)-1 , imagesy($im)-1 ,
$migra );
# database drawin left out here
imagecopymerge ( $uim, $im, 0, 0, 0, 0, imagesx($uim), imagesy($uim),
40);
header ("Content-type: image/jpeg");
imagejpeg ($uim ,'', 75);
imagedestroy($uim);
imagedestroy($im);
-- end code --
[2003-05-30 08:32:21] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Could you provide a copy of the images used in your example as well as
the expected output image.
[2003-05-26 04:24:58] i dot a at signalsystem-bz dot it
I had under php 4.3.1 some code to blend in transparency a logo over
some pictures before displaying them - all was working perfectly.
When i installed php 4.3.2rc4, i noticed that the same code stopped
working - where first was blending 2 images, now is acting this way:
- with high transparency value in imagecopymerge, the 2nd image covers
