Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 13:13:41 +0100, Pawel Golaszewski wrote: _Maybe_ he shouldn't do this... But it's done now and we shouldn't reverse it. Well, let sb fix HEAD, but it's obvious that this change MUST be reverted in Ac. This line is frozen and there is NO PLACE for ANY changes, especially so invasive. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Fri, Dec 04, 2009 at 14:18:57 +0200, Elan Ruusamäe wrote: reverted in Ac. This line is frozen and there is NO PLACE for ANY changes, especially so invasive. it is not in ac main/updates, so calm down? CVS tags: auto-th-php-5_2_11-13, auto-ac-php-5_2_11-13, AC-branch -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Fri, Dec 04, 2009 at 20:41:21 +0200, Elan Ruusamäe wrote: reverted in Ac. This line is frozen and there is NO PLACE for ANY changes, especially so invasive. it is not in ac main/updates, so calm down? CVS tags: auto-th-php-5_2_11-13, auto-ac-php-5_2_11-13, AC-branch so? So it's still not reverted. package being built, does not mean it is in updates Bogus change on AC-branch means it could go to updates anytime. Do you think we are going to remember about this or maybe you do count we would not? -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 08:51:23 +0100, Tomasz Pala wrote: /usr/sbin/httpd.prefork: symbol lookup error: /usr/lib/php/eaccelerator.so: undefined symbol: php_session_register_module Doinstaluj php-session. Teraz wszystko jest w osobnych modułach. Też się na to naciąłem. Czy nie można by wstawić php-session do listy sugerowanych ? Osoba, która wydzieliła moduł, powinna zadbać o odpowiednie R tam, gdzie jest to niezbędne, czyli webapps (jak phpPgAdmin już dodany, phpMyAdmin który raczej potrzebuje, squirrelmail itp. setka innych pakietów, w tym także eaccelerator). As the author of PHP changes that made shared pcre/spl/session you are welcome to do consecutive changes, i.e. adding missing R: php(X) to webapps. I'd like to help and prepared a list of webapps using session_*() I'm using: cacti mediawiki netmrg phpMyAdmin phpwiki postfixadmin squirrelmail stacks-wiki. Also I see you're the one who send php with these changes to upgrade, so please send all the fixed packages as well (don't forget about already fixed phpPgAdmin). -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:24:30 +0200, Elan Ruusamäe wrote: you're writing of yourself in third tense? what is this letter about? About broken PHP. Not by me. everybody is welcome to fix packages and stbr them to builders, there's even !stbr bot on irc for really everyone(?). There are already two votes to revert your change. I can do THAT. I won't fix dozen of packages YOU have broken. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 10:39:10 +0100, Pawel Golaszewski wrote: The only mistake here is requires missing. ...in how many packages? I can't even count them. Do any of you have and idea how to match those apps? php-common should require packeges that are in separate modules now. So what's the point of sharing it? For few months, to satisfy existing instalations. After that is could be suggest only, if any. Of course - if Someone(TM) fixes all the packages. But apparently he's not going to. And it's broken NOW not in few months. package spliting itself is ok, IMO. I don't really care if it's shared or not. I do care about working apps. The one who broke them and fellowship he gathers should do that BEFORE STBR. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 10:45:50 +0100, Tomasz Pala wrote: package spliting itself is ok, IMO. I don't really care if it's shared or not. I do care about working apps. The one who broke them and fellowship he gathers should do that BEFORE STBR. Although it definitely is bad idea. Let me repeat from -pl: I don't know a single installation not using sessions and so limited in resources that it makes a difference. Give me just one justification other than let's split everything we can, ONLY BECAUSE WE CAN. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:56:27AM +0200, Elan Ruusamäe wrote: and php is not sent to main, so all is in a way pld operates. It is in main. -- --= Michal Kochanowicz =--==--==BOFH==--==--= mic...@michal.waw.pl =-- --= finger me for PGP public key or visit http://michal.waw.pl/PGP =-- --==--==--==--==--==-- Vodka. Connecting people.--==--==--==--==--==-- A chodzenie po górach SSIE!!! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:55:06 +0200, Elan Ruusamäe wrote: there's been only one bugreport with missing symbols. and that bug is now fixed. So please consider my initial mail as bugreport - list of packages missing R:php(session). Some of them probably miss php(pcre) too, ENOTIME to check, ENOTIME to rel++, ENOTIME to STBR and I really have more interesting things to do than enumerating every single file some packages require. It's dumb, that's all. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:54:13 +0200, Elan Ruusamäe wrote: goal is to write down deps in pkgs. too bad original spec developer didn't care writing down requirements. these are usually written in README files, You're kidding? Maybe we should enumerate such things like glibc or FHS too, in case someone in future has a brilliant idea and splits something? welcome to pld... ...you made it. so are packages broken with sense of requiring exact apache modules they use. and they still are since 2.0 split each module. nobody is in care to fix those. Maybe it was stupid too. Do you volunteer to KEEP track of exact PHP Rs? Because it's virtually impossible to maintain such Rs during package upgrades. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:56:27 +0200, Elan Ruusamäe wrote: deps should be fixed in packages that are broken. and php is not sent to main, so all is in a way pld operates. welcome to pld! Please, don't break something and mock about it. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:11:35 +0100, Patryk Zawadzki wrote: Do you volunteer to KEEP track of exact PHP Rs? Because it's virtually impossible to maintain such Rs during package upgrades. Uhm, it's packager's job to make sure software actually works. It will work for anyone who has working _environment_ (yes, IMHO missing php-session is flawned env). People are not unerring and I doubt anyone removes all his packages in order to track every single R. And I'm sure noone reads sources or diff against previous version to track changes. Separating core modules without any reason creates only another Point Of Failure. That's an error in terms of engineering. Otherwise we could replace everyone with a short perl script that just bump the version to the latest stable. That's the way it is done for many packages I've seen. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 12:14:17 +0200, Elan Ruusamäe wrote: the list changes added and STBR'ed. Thnx. ps: and it it all took 18 minutes, not whole day... (and before you start fury on the 18 minutes, ask yourself how much time you spent heating the stove on this thread) Unfortunately: 1. the list obviously wasn't complete nor trustworthy, it was simple grep - did you check if they really require session? Maybe some of them just S... 2. Did you check them for PCRE? 3. How about the rest of webapps? 4. Why squirrelmail has php(session) and phpMyAdmin php-session? [*] 5. What's the point? (question still not answered) And it's not about 18 minutes (add 11 minutes it took ME to enumerate them here, it's half an hour), but about the rules. Rules on influencing other packages without fixing them and logical sense of some actions. * in fact I know why, but I'm not sure what happens in some future splits/renaming/whatever. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 12:18:14 +0200, Elan Ruusamäe wrote: glibc is enumerated. you're welcome to write php autodep generator. One more (it was included in polish part): error: /usr/lib/php/eaccelerator.so: undefined symbol: php_session_register_module I don't know if it would be autogenerated or not, maybe STBR is enough. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:47:49 +0100, Pawel Golaszewski wrote: Although it definitely is bad idea. Let me repeat from -pl: I don't know a single installation not using sessions I do. Not only one. What's the traffic volume? and so limited in resources that it makes a difference. It makes difference with apache in memory usage. What's the footprint? -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 11:56:32 +0100, Pawel Golaszewski wrote: What's the traffic volume? 2 of them - big. and so limited in resources that it makes a difference. It makes difference with apache in memory usage. What's the footprint? I didn't checked but every php module loaded causes memory usage increase of each apache process. Crazy but it's the way apache works. If you have big traffic you shouldn't use PHP as apache module at all (as already patrys said). Well, you shouldn't use apache;) If you have huge traffic you shouldn't even use PLD packages. Do you know what's the memory footprint and performance loss when using everything as modules? -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 12:15:36 +0100, Pawel Golaszewski wrote: What's the footprint? I didn't checked but every php module loaded causes memory usage increase of each apache process. Crazy but it's the way apache works. [...] There are arguments to make these modules as separate ones. Yes, memory overhead... OTOH I don't know any systems that don't use session isn't anything significant. You can talk about any module like that... But there are only a few I can't imagine PHP without. What can do large PHP traffic without sessions? Make performance, memory tests and proof that it's not the right direction. ...now please step back and read first paragraph. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 13:22:33 +0200, Elan Ruusamäe wrote: 4. Why squirrelmail has php(session) and phpMyAdmin php-session? [*] ^^^ php(pcre) notes php4 or php5 virtual. php-pcre notes: php5 only. php4-pcre notes: php4 only. There were footnote to read;) I wonder what's going to happen when PHP 6.0 arises. Would package maintainers (means who?) review all the Rs, or we use some dumb 'perl script' to update them? -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Aktualne PHP powinno wy magać aktualnego pcre, problem z php-eaccelerator
On Wed, Dec 02, 2009 at 12:51:54 +0100, Pawel Golaszewski wrote: But there are only a few I can't imagine PHP without. What can do large PHP traffic without sessions? A lot of things can be done without sessions. Don't think about webpage in internet only. php can do much more things... I'm aware of it as I (unfortunately) use PHP for other purposes. However it's not the case of big traffic. And it shouldn't be apache. But this way we could end with one-big-php-lib because each module is unsignificant. I guess that's the way PHP is used when performance is the issue. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
