- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 10 2021
Jan 9 2021
Jan 8 2021
Works like charm samm, thank you very much! :) Feel free to commit it! :)
Jan 3 2021
Dec 29 2020
Dec 23 2020
Dec 18 2020
Dec 3 2020
Nov 22 2020
Nov 2 2020
Nov 1 2020
Oct 26 2020
Oct 23 2020
In D26848#599940, @ale wrote:The main question is if it is really needed at all. I never saw a use-case for the zts/debug handling. While i can understand the idea you explained, it looks like these cases will only occur when building the code by yourself AND switching such basic options afterward. And i think with pkg becoming the main source of installation this scenarios are even more unlikely. So i personally would try to remove it all, but the last attempt failed badly :D
I'm not sure what you mean with "I never saw a use-case for zts handling". If you are using a threaded SAPI (like apache mpm worker or event) or calling the libphp from a threaded app you must build everything with thread-safe support. With fastcgi or mpm prefork that's not needed and in fact the default is to not build a thred safe php. But while a TS php can work in single threaded apps, the opposite is not true and the bugs may be subtle to be found. I agree with you that mixing extensions compiled with different options is something that usually happens when you manually build ports (and perhaps you were referring to this with zts handling), but that's exactly the reason to have it. If there are ports that install extensions in the non-zts directory when php is built with zts, then this should trigger an alarm: was the extension really compiled in thread safe mode? If so, why did it install in the wrong dir? The last thing you want is to call a non thread safe library from a threaded app.
Said so, I'm not completely against the removal of different directories, but if you do I'd like you to know exactly what were the original reasons so that you can verify that you are not hiding potential issues with its removal.
Oct 22 2020
Oct 21 2020
In D26848#599533, @ale wrote:In D26848#599504, @tz wrote:Are you sure it's your basic setting? The ports failing because of the ZTS option. And this option is broken since 7.0 or even earlier. Same for DEBUG option. See for example here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245034
So this is expected ;)
I don't know the status on 7.0 and later, so there may be a new issue I'm not aware of, but in all PHP versions I maintained it was working fine. The reason to use different directories is to avoid mixing extensions with different build options, e.g. if now I want a thread safe php I don't want to use an old extension compiled without thread-safety. Once the PHP port is installed, the correct directory is taken from the php.conf file, but if it's not installed yet there is an heuristic, that perhaps needs some adjustment.
Oct 20 2020
In D26848#599355, @mfechner wrote:I executed: poudriere testport -p gitlab -j 121amd64 lang/php80-extensions
But I got some errors:
https://pkg.fechner.net/build.html?mastername=121amd64-gitlab&build=2020-10-20_13h53m23sI enabled some more ports in php80-extensions (the normal settings I use for all php versions).
Oct 19 2020
In D26848#598658, @pascal.christen_hostpoint.ch wrote:xmlrpc is also gone as an extension, right?
So no need to install the php7?-xmlrpc port for PHP 7.X
Oct 9 2020
Oct 8 2020
Sep 13 2020
Sep 8 2020
Sep 7 2020
Aug 25 2020
Aug 19 2020
Jul 28 2020
Jul 23 2020
Jul 16 2020
Jul 15 2020
Jul 14 2020
Jul 13 2020
This was committed in r542132.
I forgot the reference in the commit log -.-
In D25648#567498, @bofh wrote:This bug is not very easy to reproduce; specially this cannot be reproduced on a fresh poudriere jail at least. But I have faced multiple occurrences of this same scenario and changing to panda-cclient at least solve the problem. The diff looks good but I think we will need a bump in the PORTREVISION for php7[2-4] as the default OPTIONS are changing for slave ports.
Added the portbumps