Re: [Mageia-dev] web virtual management solution
On 08/01/2013 17:50, Armando B. wrote: Hi friends, i looking in svn repo for some solution about KVM web management solution, but i haven't founded applications. I used, for a little virtual cluster, VirtualBox + VbTool + phpVirtualbox (all presents in our repo). For KVM there is great virt-manager for cli gui but nothing for web gui. Searching online i saw: http://www.openqrm-enterprise.com http://www.ovirt.org/Home https://www.webvirtmgr.net http://archipelproject.org http://karesansui-project.info/ https://code.osuosl.org/projects/ganeti-webmgr packaging of some of these is difficult for dependencies not already in our repo, perhaps ganeti could be more simple to package (in repo missing only 2 packages: python-whoosh and django-fields) what do you think about ? Would we have a web management solution for KVM in Mageia ? I started packaging ovirt, but on my Mageia 2 system, and I got stuck on a java dependency. I should probably import the packages that succeeded so far. Regards, Buchan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release shorewall-4.5.10.1-1.mga3
Le 09/01/2013 08:05, Johnny A. Solbu a écrit : On Wednesday 9. January 2013 06.10, Thierry Vignaud wrote: Now here's the result: Installation failed:file /usr/share/shorewall/lib.base from install of shorewall-core-4.5.10.1-1.mga3.noarch conflicts with file from package shorewall-4.4.23.1-9.mga2.noarch file /usr/share/shorewall/lib.cli from install of shorewall-core-4.5.10.1-1.mga3.noarch conflicts with file from package shorewall-4.4.23.1-9.mga2.noarch file /usr/share/shorewall/lib.common from install of shorewall-core-4.5.10.1-1.mga3.noarch conflicts with file from package shorewall-4.4.23.1-9.mga2.noarch shorewall-core is needed by shorewall-4.5.10.1-1.mga3.noarch Please revert that non sense split. Upong reading their website, it is a split from upstream as of v4.5.0: ftp://ftp.shorewall.no/pub/shorewall/4.5/shorewall-4.5.0/releasenotes.txt So I'm unsure as to what to do. You're the only one, everybody else know... -- BOFH excuse #165: Backbone Scoliosis
Re: [Mageia-dev] web virtual management solution
Le 08/01/2013 17:54, Juan Luis Baptiste a écrit : While this is something that I would love to see on Mageia, I think it's late for inclusion on Mageia 3, version freeze is tomorrow, so even if ganeti could be packaged and imported with all of the missing deps today, I'm not sure there's enough time to test it before tomorrow's freeze. version freeze only prevent you to update an existing package, not to introduce a new one. -- BOFH excuse #71: The file system is full of it
Re: [Mageia-dev] PXE boot on cauldron failed
Le 08/01/2013 21:04, eatdirt a écrit : On 08/01/13 20:51, AL13N wrote: Any idea ? huh, i never knew that you could specify URLs in pxe configs... for kernel and initrds Me neither, this is very cool actually. If you make it work again Olivier, that would deserve a mini wiki somewhere... Unless something changed, tough, there is still a length limit to appended parameters (probably 255), so using an URL for initrd is likely to reach this limit earlier. -- BOFH excuse #435: Internet shut down due to maintenance
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release shorewall-4.5.10.1-1.mga3
On Wednesday 9. January 2013 09.22, Guillaume Rousse wrote: So I'm unsure as to what to do. You're the only one, everybody else know... That's not true, and you ought to know that! -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
[Mageia-dev] Your Firefox is out of date. Get the newest version here.
After latest Cauldron updates - Firefox was updated to 17.0.2 ESR But when it first starts, I get a page which states: Your Firefox is out of date. Get the newest version here. The latest is 18 Is this the intended action?? Thx, R.Fox
Re: [Mageia-dev] Your Firefox is out of date. Get the newest version here.
Le 09/01/2013 09:51, Robert Fox a écrit : Is this the intended action?? ;-)
Re: [Mageia-dev] [343016] provide need /var/run/ nscd in nscd package otherwise nscd failed to start
'Twas brillig, and Colin Guthrie at 09/01/13 10:11 did gyre and gimble:
'Twas brillig, and Olivier Thauvin at 08/01/13 18:32 did gyre and gimble:
* Thomas Backlund (t...@mageia.org) wrote:
root-odjjhxpcy38dnm+yrof...@public.gmane.org skrev 8.1.2013 20:06:
Revision
343016
Author
nanardon
Date
2013-01-08 19:06:55 +0100 (Tue, 08 Jan 2013)
Log Message
provide need /var/run/nscd in nscd package otherwise nscd failed to start
Nope, wrong fix...
if there is something wrong, it must be fixed in SOURCE9 (nscd.conf)
as /run (to wich /var/run point at) is a tmpfs
There is no /var/run/nscd in nscd.conf but:
-- Logs begin at Thu, 2012-11-08 21:13:36 CET, end at Thu, 2012-11-08
21:15:11 CET. --
Jan 08 19:23:30 localhost.localdomain nscd[2063]: 2063
/var/run/nscd/socket: No such file or directory
Jan 08 19:23:30 localhost.localdomain systemd[1]: nscd.service never
wrote its PID file. Failing.
Indeed it's a tmpfs. Obviously this directory exists on my laptop, don't
know how but on my freshly installed cauldron it does not.
I suspect /var/run/nscd/ is the path also used by glibc to find the nsdc
socket.
There is no option in nscd.conf to change it according man page.
I just revert my changes, feel free to fix.
There isn't any fix needed as far as I can tell. It was fixed a long,
long time ago by adding /usr/lib/tmpfiles.d/nscd.conf to the package
which is what Thomas was referring to I believe and it very much does
refer to /var/run/nscd directory.
Not also that as mentioned to you previously on this list, you should no
longer package any files in /var/run, /var/lock and /run and instead use
tmpfiles for this. rpmlint should even reject any such packages with
such files. Unless I've messed up the rpmlint. Did glibc get through the
build system like this or was it never submitted?
In order to debug this specific problem, can you check systemctl status
systemd-tmpfiles-setup.service Has this run correctly at boot?
Perhaps the main problem is actually that nscd was installed and then
you tried to start it immediately without rebooting? It seems that nscd
package is missing a call to the necessary tmpfiles macro in it's %post
to ensure that systemd-tmpfiles --create nscd.conf is run such that
this is supported. Can you confirm if you rebooted after installing nscd
or not so I can put my mind at rest as to what the actual problem is?
More info about the tmpfiles calls and macros here:
https://wiki.mageia.org/en/System_Service_policy
as you can see the missing call in %post nscd is simply:
%_tmpfilescreate %{name}
Actually, it's %_tmpfilescreate nscd due to it being a sub package.
Correct fix should be:
http://svnweb.mageia.org/packages?view=revisionrevision=343643
If it looks good, feel free to bump and push :)
Col
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
[Mageia-dev] [RPM Groups] Final change for Mageia 3 done
Dear Packagers, As a final amendment to the RPM group policy for Mageia 3, the following changes were made yesterday: - creation of Games/Simulation - Graphics/Editors renamed as Graphics/Editors and Converters - Graphics/Other renamed as Graphics/Utilities - Office/Other renamed as Office/Utilities - removal of Sound/Visualization - creation of Video/Television The renames will be handled by scripts, so do not worry about them. However, feel free to use the two new groups: Games/Simulation and Video/Television. I remind you that the policy is at: https://wiki.mageia.org/en/RPM_groups_policy#List_of_official_groups Thanks a lot ! -- Malo
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
On Tue, 08 Jan 2013 16:35:30 +, I wrote: Anyone know of a fix for the above, please? Is there really no way of rescuing my updated MGA3-cauldron installation from the Kernel Panic showstopper? -- /\/\aurice
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
'Twas brillig, and Maurice Batey at 09/01/13 13:00 did gyre and gimble: Is there really no way of rescuing my updated MGA3-cauldron installation from the Kernel Panic showstopper? There are many ways... If you are lucky you will have *.old initrds so just edit your grub prompt to use initrd.img.old rather than initrd.img (via text mode in grub) Failing that, boot with a rescue dvd, chroot into your install and force the install of util-linux from mga2. Then regenerate your initrd. Failing massive filesystem corruption it's almost always possible to rescue things - just takes varying degrees of effort! :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] web virtual management solution
On Wed, Jan 9, 2013 at 3:23 AM, Guillaume Rousse guillomovi...@gmail.comwrote: version freeze only prevent you to update an existing package, not to introduce a new one. Ah I didn't knew this, thanks !! For new packages, when would be the deadline ? -- Juancho
Re: [Mageia-dev] web virtual management solution
'Twas brillig, and Juan Luis Baptiste at 09/01/13 14:33 did gyre and gimble: On Wed, Jan 9, 2013 at 3:23 AM, Guillaume Rousse guillomovi...@gmail.com mailto:guillomovi...@gmail.com wrote: version freeze only prevent you to update an existing package, not to introduce a new one. Ah I didn't knew this, thanks !! For new packages, when would be the deadline ? I think it's probably the same as release freeze. That's when we all have to justify pretty much everything. Until that point we can all break things via provides/requires as much as a new package so I think this is the correct point to call a cut off for new packages (of course exceptions can always be made - the main risk with new packages is that they provide something (in the spec) that is also provided by another package and thus are pulled in accidentally - if this can be shown to be very unlikely to cause problems for a given package then it could get an exception. Obviously we should not encourage this :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
On Wed, 09 Jan 2013 13:21:06 +, Colin Guthrie wrote: If you are lucky you will have *.old initrds so just edit your grub prompt to use initrd.img.old rather than initrd.img (via text mode in grub) Where are such initrd.img.old files found? (No such files anywhere in its menu.lst.) -- /\/\aurice
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
On 09/01/13 16:24, Maurice Batey wrote: On Wed, 09 Jan 2013 13:21:06 +, Colin Guthrie wrote: If you are lucky you will have *.old initrds so just edit your grub prompt to use initrd.img.old rather than initrd.img (via text mode in grub) Where are such initrd.img.old files found? We all assume that, with a boot cd, live dvd, you can mount your root partition /somewhere ls -trl /somewhere/boot/ and try to find a initrd-x.x.x which has been generated before the bug. In my case, I got: initrd-3.6.5-tmb-desktop-3.mga3.img and I have also the kernel vmlinuz-3.6.5-tmb-desktop-3.mga3 (thanks to master tmb) Now add a new entry in /boot/grub/menu.lst referring to compatible versions of initrd (not corrupted) and vmlinuz (be inspired by the ones already written in this file) Reboot et select these ones.
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
On Wed, 09 Jan 2013 16:34:45 +0100, EatDirt wrote: initrd-3.6.5-tmb-desktop-3.mga3.img and I have also the kernel vmlinuz-3.6.5-tmb-desktop-3.mga3 OK - found /boot/initrd-3-7-0-desktop-1-mga3.img and /boot/vmlinuz-3.7-0-desktop-1.mga3 (The latest (panicky) kernel is 3.7.1.) and - in menu.lst - replaced: /boot/vmlinuzwith /boot/vmlinuz-3.7-0-desktop-1.mga3 and initrd /boot/initrd.imgwith initrd /boot/initrd-3-7-0-desktop-1-mga3.img in a clone of the 'official' (but kernel panic) stanza. But although a reboot starts well, after 6 lines the action *hangs* at the 'initrd' line. -- /\/\aurice
Re: [Mageia-dev] PXE boot on cauldron failed
On 9 January 2013 09:26, Guillaume Rousse guillomovi...@gmail.com wrote: Any idea ? huh, i never knew that you could specify URLs in pxe configs... for kernel and initrds Me neither, this is very cool actually. If you make it work again Olivier, that would deserve a mini wiki somewhere... Unless something changed, tough, there is still a length limit to appended parameters (probably 255), so using an URL for initrd is likely to reach this limit earlier. good point! it's supposed to be fixed with kernel-2.6.26 but I guess some boot loaders do not use the latest boot protocol (/usr/share/doc/kernel-doc/x86/boot.txt) or still silently cut after 255/256 bytes.
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
On Wed, 09 Jan 2013 19:13:14 +, Maurice Batey wrote about Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c: and - in menu.lst - replaced: But although a reboot starts well, after 6 lines the action *hangs* at the 'initrd' line. If you change menu.lst, you also have to execute /boot/grub/install.sh, else it does not have any effect. HTH Cheers, =Dick Gevers=
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
On 01/09/2013 02:26 PM, Dick Gevers wrote: On Wed, 09 Jan 2013 19:13:14 +, Maurice Batey wrote about Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c: and - in menu.lst - replaced: But although a reboot starts well, after 6 lines the action *hangs* at the 'initrd' line. If this was a previous kernel installed on this partition, then your menu.lst should already have a version-specific entry for it. Try booting that directly without modifying anything. Also, bug 8614 for all this was just fixed. If you change menu.lst, you also have to execute /boot/grub/install.sh, else it does not have any effect. I used to think that, but was recently corrected by Barry Jackson, and found that it wasn't the case, at least for modifying labels and such. Maybe there's something special about the kernel/initrd specifications, tho.
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
On 09/01/13 20:13, Maurice Batey wrote: and - in menu.lst - replaced: /boot/vmlinuzwith /boot/vmlinuz-3.7-0-desktop-1.mga3 and initrd /boot/initrd.imgwith initrd /boot/initrd-3-7-0-desktop-1-mga3.img in a clone of the 'official' (but kernel panic) stanza. But although a reboot starts well, after 6 lines the action *hangs* at the 'initrd' line. Weird, that should work. Check for typos in the names. For instance you have one above: 3-7-0 instead of 3.7.0.
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Luc Menut lme...@free.fr writes: Hi all, /usr/bin/file is broken on cauldron (file-5.12-4.mga3). It gives weird bogus results (i586 and x86_64), and breaks some builds. eg. file /usr/bin/xdg* /usr/bin/xdg-desktop-icon: , 28265 /usr/bin/xdg-desktop-menu: , 28265 /usr/bin/xdg-email:, 28265 /usr/bin/xdg-icon-resource:, 28265 /usr/bin/xdg_menu: assembler source text /usr/bin/xdg-mime: , 28265 /usr/bin/xdg-open: , 28265 /usr/bin/xdg-screensaver: , 28265 /usr/bin/xdg-settings: , 28265 /usr/bin/xdg-user-dir: , 28265 /usr/bin/xdg-user-dirs-gtk-update: ELF 64-bit LSB executable, ... /usr/bin/xdg-user-dirs-update: ELF 64-bit LSB executable, ... Hi, Upstream file 5.12 looks quite broken :-/ They updated the 5.12 release tarball (!) on the FTP site with a collection of fixes, that's quite a bad practice... See this thread about your issue: http://mx.gw.com/pipermail/file/2013/001019.html It should be fixed in 5.12-5.mga Cheers -- Olivier Blin - blino
Re: [Mageia-dev] Packages with changes on svn
On Wed, Jan 9, 2013 at 8:23 PM, David Walser luigiwal...@yahoo.com wrote: updates to a new version - danger! -- tcl telepathy-idle Done transfugdrake tree Submitted usbutils It was actually not, just some version change + revert I haven't looked at tcl and transfugdrake
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Hi, Le 09/01/2013 22:57, Olivier Blin a écrit : Luc Menutlme...@free.fr writes: Hi all, /usr/bin/file is broken on cauldron (file-5.12-4.mga3). It gives weird bogus results (i586 and x86_64), and breaks some builds. eg. file /usr/bin/xdg* /usr/bin/xdg-desktop-icon: , 28265 /usr/bin/xdg-desktop-menu: , 28265 /usr/bin/xdg-email:, 28265 /usr/bin/xdg-icon-resource:, 28265 /usr/bin/xdg_menu: assembler source text /usr/bin/xdg-mime: , 28265 /usr/bin/xdg-open: , 28265 /usr/bin/xdg-screensaver: , 28265 /usr/bin/xdg-settings: , 28265 /usr/bin/xdg-user-dir: , 28265 /usr/bin/xdg-user-dirs-gtk-update: ELF 64-bit LSB executable, ... /usr/bin/xdg-user-dirs-update: ELF 64-bit LSB executable, ... Hi, Upstream file 5.12 looks quite broken :-/ They updated the 5.12 release tarball (!) on the FTP site with a collection of fixes, that's quite a bad practice... See this thread about your issue: http://mx.gw.com/pipermail/file/2013/001019.html It should be fixed in 5.12-5.mga Thanks Olivier to look at this pb. I've just locally rebuilt file-5.11 and your new file-5.12-5. It's better, but file-5.12-5 still mis-detects some script files; I can see that some Perl or shell scripts are reported as 'assembler source text' with 5.12-5. eg. file -v; file /usr/bin/autoconf /usr/bin/automake /usr/bin/iurt file-5.11 magic file from /usr/share/misc/magic /usr/bin/autoconf: POSIX shell script, ASCII text executable /usr/bin/automake: Perl script, ASCII text executable /usr/bin/iurt: Perl script, ISO-8859 text executable, with very long lines file -v; file /usr/bin/autoconf /usr/bin/automake /usr/bin/iurt file-5.12 magic file from /usr/share/misc/magic /usr/bin/autoconf: POSIX shell script, ASCII text executable /usr/bin/automake: assembler source text /usr/bin/iurt: assembler source text It's very annoying because /usr/bin/file is used by find-requires and find-provides, and if we do the mass rebuild with a broken /usr/bin/file, we will build some rpms with incorrect provides and requires. regards, Luc -- Luc Menut
Re: [Mageia-dev] Packages with changes on svn
Pascal Terjan pterjan@... writes: I haven't looked at tcl and transfugdrake transfugrade was updated in SVN by ennael. tcl was updated to 8.6 in SVN. I think we had a prerelease of 8.6 in mga1 but someone said it caused problems and we rolled back to 8.5 for mga2. Now 8.6 final has been released, so we either want to stick with 8.5 again for mga3, or move tcl and tk to 8.6 (and I think expect is supposed to be updated along with those).
Re: [Mageia-dev] Packages with changes on svn
Le 09/01/2013 21:23, David Walser a écrit : scilab i'm working on the new version as the old one refuse to pass on BS. but i'll be late for version freeze /o\ python-scikits-learn done. Claire
Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c
Le 09/01/2013 20:26, Dick Gevers a écrit : On Wed, 09 Jan 2013 19:13:14 +, Maurice Batey wrote about Re: [Mageia-dev] Kernel Panic after latest Mageia-3-Alpha2 s/w update c: and - in menu.lst - replaced: But although a reboot starts well, after 6 lines the action *hangs* at the 'initrd' line. If you change menu.lst, you also have to execute /boot/grub/install.sh, else it does not have any effect. No, menu.lst just affect second part of the bootloader (stage2), whereas /boot/grub/install.sh installe the firsts part (stage1) on the MRB (or elsewhere). That's one of the main interest of grub vs lilo. Also, if you just have to boot once, you don't have to first boot on some rescue system to change menu.lst, there is an interactive shell where you can freely set every parameter needed to boot. -- BOFH excuse #177: sticktion
Re: [Mageia-dev] Packages with changes on svn
Le 10/01/2013 00:12, Claire Revillet a écrit : Le 09/01/2013 21:23, David Walser a écrit : scilab i'm working on the new version as the old one refuse to pass on BS. but i'll be late for version freeze /o\ Just push it with an empty file list now, but with the new version number, and fix it later :) -- BOFH excuse #226: A star wars satellite accidently blew up the WAN.
Re: [Mageia-dev] Packages with changes on svn
On Wednesday 9. January 2013 21.23, David Walser wrote: tmux ufoai Done. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Packages with changes on svn
Le 10/01/2013 00:32, Guillaume Rousse a écrit : Le 10/01/2013 00:12, Claire Revillet a écrit : Le 09/01/2013 21:23, David Walser a écrit : scilab i'm working on the new version as the old one refuse to pass on BS. but i'll be late for version freeze /o\ Just push it with an empty file list now, but with the new version number, and fix it later :) Thank you for this wonderfull tip ;)
Re: [Mageia-dev] Packages with changes on svn
On 09.01.2013 18:36, nicolas vigier wrote: rasmol version upgrade reverted
Re: [Mageia-dev] rpmrc [5221] build with -fPIC on x86_64 too (pok, mdv)
26.09.2012 22:57, Thierry Vignaud kirjoitti: On 26 September 2012 20:30, Anssi Hannula an...@mageia.org wrote: Author tv Log Message build with -fPIC on x86_64 too (pok, mdv) Why? -fPIC should already be used on x86_64 or you'll get sooner or later in troubles (for instance when linking libs). I think that any sane build script should already default to -fPIC on x86_64 but some other weird build script may not. (rtp) I have to strongly disagree with this. - This hides problems in build scripts. Shared libraries should normally be linked with -fPIC on *all* architectures. Not doing this causes some issues, like the library to actually become unshareable across different processes. Since these are allowed in iX86 but not on x86_64, building all objects on x86_64 with -fPIC will hide any missing -fPIC from build script issues. Note that there can't be very many problematic failing packages, since we and mdv have managed this far without it. - It is not needed except on shared libraries, and will cause a small performance penalty (due to one less register being available when using relative addressing). (AFAIU it is negligible, but still..) - Other major distros (not counting MDV) do not do this -- Anssi Hannula
[Mageia-dev] Freeze push: lcov
Hello, lcov 1.9 isn't working with the current GCC, upgrade to 1.10 fixes it. Fedora uses a patch against 1.9 [1], not needed anymore with the current version. Please push this package. [1] http://pkgs.fedoraproject.org/cgit/lcov.git/diff/?id=25a274d9dbd6813b160e8c8c6ab12791dff8733e
Re: [Mageia-dev] PHP treadsafe
On Tuesday, January 08, 2013 03:04:45 AM Frederik Himpe wrote: On Sat, 05 Jan 2013 10:20:35 -0700, Thomas Spuhler wrote: If nobody objects I am going to rebuild php treadsafe (--enable-maintainer-zts) it is needed for running apache with mpm-module-worker instead of prefork and php apache module worker is needed by 389-ds. It is now declared as stable. But apache mpm-prefork starts with php compiled treadsafe apache mpm-worker doesn't start with php compiled none-treadsafe You can run PHP with apache2-mpm-worker with mod_fcgid and php5-cgi or php5-fpm. This is what Debian Wheezy's README file for php says: Using PHP 5 with threaded webservers (e.g. apache2-mpm-worker) -- After much back-and-forth with upstream (and even building our packages thread-safe for a while), we're currently admitting defeat on that front, and are NOT building any thread-safe versions of PHP 5 for any webservers. Our recommendation is that, if you need to use a threaded webserver, you should use php5-fpm and interface to your webserver with FastCGI. I think Mageia is hurting itself by enabling too experimental features. Another example is the uas kernel module, of which I saw a complaint recently in this mailing list. This module is known to be buggy, and disabled in Debian. Would you mind to provide some help on how the run apache-mpm-worker with php NTS? -- Best regards Thomas Spuhler signature.asc Description: This is a digitally signed message part.
