Re: [Mageia-dev] new urpmi release ?
On 15 March 2012 22:02, Guillaume Rousse guillomovi...@gmail.com wrote: I have fixed two bugs in urpmi bash completion: - https://bugs.mageia.org/show_bug.cgi?id=373 - https://bugs.mageia.org/show_bug.cgi?id=4937 However, I'm unaware of any other changes in the perl code itself. Is it sage to proceed with a new release ? It is. Only translations have been updated since last release
Re: [Mageia-dev] php pear mga2 upgrade issues (file conflicts)
On 16 March 2012 03:36, Anssi Hannula an...@mageia.org wrote: I've seen some mga1-mga2 upgrade issues with php-pear packages: file /usr/share/pear/PHPUnit/Extensions/Database/Operation/Exception.php from install of php-pear-DbUnit-1.1.2-1.mga2.noarch conflicts with file from package php-pear-PHPUnit-3.3.17-3.mga1.noarch file /usr/share/pear/PHPUnit/Extensions/SeleniumTestCase/append.php from install of php-pear-PHPUnit_Selenium-1.2.3-1.mga2.noarch conflicts with file from package php-pear-PHPUnit-3.3.17-3.mga1.noarch It looks like php-pear-PHPUnit_Selenium and php-pear-DbUnit were probably splitted from php-pear-PHPUnit and so need Conflicts: php-pear-PHPUnit 3.5. Similar issues seem to exist (without closer look) in other pkgs like at least php-pear-File* and php-pear-PHPUnit_Story. Attached is the output of ./check-distro-files-conflicts /mirror/mageia/1/x86_64 \ /mirror/mageia/cauldron/x86_64 | grep php-pear | grep mga2 (check-distro-files-conflicts is the old Pixel's script at http://svn.mandriva.com/viewvc/soft/build_system/distrib/cleaning/check-distro-files-conflicts) You should open a BR instead of sending a mail...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release nginx-1.0.10-2.mga2
On 15 March 2012 20:47, guillomovitch buildsystem-dae...@mageia.org wrote: guillomovitch guillomovitch 1.0.10-2.mga2: + Revision: 223512 - sync configuration files with fedora package - drop useless apache dependency - spec cleanup - systemd support ahem: 8/36: nginx ##warning: /etc/nginx/nginx.conf created as /etc/nginx/nginx.conf.rpmnew ### Migrating sysvinit service 'nginx' to systemd native unit 'nginx.service' for target 'graphical.target' warning: %post(nginx-1.0.10-2.mga2.x86_64) scriptlet failed, exit status 1
Re: [Mageia-dev] [Freeze] please let in xonotic
Le jeudi 15 mars 2012 20:35:08, Maarten Vanraes a écrit : Op donderdag 15 maart 2012 18:35:04 schreef Juan Luis Baptiste: On Thu, Mar 15, 2012 at 12:24 PM, Bertaux Xavier berta...@yahoo.fr wrote: If this is the case, then I say that xonotic should be allowed to be updated. I'm not about to be okay with that, a version Freeze only accepts updates on bug fixes and security warnings, so RC to Release is OK but not to revision's change, otherwise that would mean that if fate xonotic in version 0.7 just before the Release we should built. To me this should be pushed Backport, to limit the update after Release Backports are for new versions, not bug fixes. In this case even as this is a new version, the use of an older version of the game client with a new game server version could bring issues to users, so that makes this release more of a bug fix release, because we are trying to avoid any possible problem to our users, not because we want to have the latest version of the game. If we leave the current version and then a user reports a problem while playing the game, the 0.6 or 0.7 or whatever version is available at the time would be pushed as an update, not as a backport. well, the version policy is for updates. my point here is that we should maybe equalize simplify our policys by having the same kind of exceptions in both policies. It's already the case. If you re-read Ennael's mail about version freeze, it says exactly that about exceptions. Samuel
Re: [Mageia-dev] freeze push mgaonline
On Thu, Mar 15, 2012 at 10:54:43PM +0100, Kamil Rytarowski wrote: On 15.03.2012 22:44, Dan Fandrich wrote: On Thu, Mar 15, 2012 at 10:15:34PM +0100, Kamil Rytarowski wrote: If you don't know what it is used for why are you so opposed? We have our own names and suffixes, so I don't why you are against. For exactly the same reason we dropped X-Mandriva-* in favor of X-Mageia in .desktop files. If the formats are identical, then creating a brand-new MIME type is unnecessary complication. Server adminstrators who want to serve up .bundle files for both Mandriva and Mageia then have to deal with sending different two MIME types for files with the same extension. Not true! The only thing to deal with is shipping files with the same extension. Think outside of a local machine. Extensions aren't used if something is served over http. It uses the MIME type. That locally the extension would be used to determine the MIME type still means it uses the MIME type. Locally a MIME type change doesn't have much of an effect. But it does if your interact with others (http, etc). -- Regards, Olav
Re: [Mageia-dev] Mageia 2 Beta 2 is available
16.03.2012 03:07, tux99-...@uridium.org kirjutas: On Thu, 15 Mar 2012, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ We need your tests and reports more than ever! Hi Anne, I gave feedback with regards to serious issues when trying beta 1 on a Cedarview Atom system, but apart from a couple of isolated replies (thanks to those who did reply) that unfortunately didn't solve the issues I got no further interest. And the bug number is? -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release nginx-1.0.10-2.mga2
Le 16/03/2012 08:37, Thierry Vignaud a écrit : On 15 March 2012 20:47, guillomovitchbuildsystem-dae...@mageia.org wrote: guillomovitchguillomovitch 1.0.10-2.mga2: + Revision: 223512 - sync configuration files with fedora package - drop useless apache dependency - spec cleanup - systemd support ahem: 8/36: nginx ##warning: /etc/nginx/nginx.conf created as /etc/nginx/nginx.conf.rpmnew ### Migrating sysvinit service 'nginx' to systemd native unit 'nginx.service' for target 'graphical.target' warning: %post(nginx-1.0.10-2.mga2.x86_64) scriptlet failed, exit status 1 There is no specific handling for this issue in nginx spec file, si I'd rather think of a generic migration issue. Maybe the fact than pid file location changed between the two releases ? -- BOFH excuse #133: It's not plugged in.
Re: [Mageia-dev] lighttpd and others now require apache
Le 16/03/2012 03:01, Anssi Hannula a écrit : So I'd rather revert the change, and make lighttpd autonomous also. Unless someone can convince me there is an advantage having lighttpd executing as 'apache' :) The web applications policy has files being owned by 'apache' user, and I don't see how that could work if lighttpd used a different user: https://wiki.mageia.org/en/Web_applications_policy This policy was crafted with apache in mind only, not all available web servers. And its explicitely refers to apache integration, not generic webserver compatibility. For instance, the configuration file provided is apache-specific. Even if we have compatible file permissions, and if we asked packagers to also provide a default lighttpd configuration file (slighly more work), that would still be mostly theorical compatibility without actual testing from the packagers (many more work). So, rather than a potential compatibility, without documented limits, should we rather not make clear than adapting our web applications package to any other web server than apache is fully up to the end user ? -- BOFH excuse #202: kernel panic: write-only-memory (/dev/wom0) capacity exceeded.
Re: [Mageia-dev] freeze push mgaonline
On Fri, Mar 16, 2012 at 01:10, Anssi Hannula an...@mageia.org wrote: 15.03.2012 22:07, Dan Fandrich kirjoitti: On Thu, Mar 15, 2012 at 03:25:40PM +0100, n...@gmx.com wrote: * stop using Mandriva URLs and replace them by www.mageia.org (mga#1590) * replace Mandriva strings by Mageia in gnome-mandrakeonline.desktop * replace MIME Type application/x-mdv-exec by application/x-mga-exec Replacing Mandriva - Mageia in user-visible text makes sense, but what exactly is the MIME type used for? If the underlying data format hasn't changed (whatever it is), then this isn't something that should really be modified, any more than renaming image/vnd.microsoft.icon to something else. +1, we shouldn't change the MIME type here. Agreed. But it's not that important now: this code portion was a prototype at the time, has not been used/tested for years (no Kiosk server serving application/x-mdv-exec since Dec. 2006), and this MIME type was created for this very use case. Should we think about some sort of Web-based app store, we'd need to redesign it from scratch and in a better, modular way (options are not the same today).
Re: [Mageia-dev] freeze push: setup
On Thu, 15 Mar 2012, Kamil Rytarowski wrote:
On 15.03.2012 19:53, nicolas vigier wrote:
On Thu, 15 Mar 2012, Guillaume Rousse wrote:
It's just an update of /etc/{services,protocols} files (current ones are
3-years old).
Submitted.
Please push it again. It's updated. I have excluded firmly run-parts from
setup, it's provided through a stand-alone package.
pushed
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release nginx-1.0.10-2.mga2
On Fri, 16 Mar 2012 08:37:26 +0100, Thierry Vignaud wrote: On 15 March 2012 20:47, guillomovitch buildsystem-dae...@mageia.org wrote: guillomovitch guillomovitch 1.0.10-2.mga2: by the way, you also need to patch it or to update it to 1.0.14 to fix security issue CVE-2012-1180: http://seclists.org/oss-sec/2012/q1/644 -- Frederik Himpe
Re: [Mageia-dev] Mageia 2 Beta 2 is available
On Fri, 16 Mar 2012, Sander Lepik wrote: 16.03.2012 03:07, tux99-...@uridium.org kirjutas: On Thu, 15 Mar 2012, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ We need your tests and reports more than ever! Hi Anne, I gave feedback with regards to serious issues when trying beta 1 on a Cedarview Atom system, but apart from a couple of isolated replies (thanks to those who did reply) that unfortunately didn't solve the issues I got no further interest. And the bug number is? Does your post mean you looked at the info I provided in the previous emails and you concluded that I'm hitting a bug? As I said before I don't know if I'm hitting a bug or if it's a configuration issue, that's what I was trying to find out here. My main problem is I don't really understand how the GMA3600 needs to be configured, I don't know what this DRM kernel driver that's included in 3.3.7rc7 is, is it equivalent to a framebuffer driver, or do I still have to use the generic vesa framebuffer? Regardless of that, out of the box I'm not getting any picture with this GPU (the screen goes into stand-by once the DRM kernel module is activated at boot). I did manage to manually configure xorg to use the generic vesa framebuffer but this way I don't seem to get any DRI capability which I thought the GMA3600 DRM kernel module was supposed to provide. There don't seem to be any docs anywhere with regards to this, neither in the kernel docs nor on the internet, at least I didn't find anything. As it stands Mageia is unusable on a Cedarview Atom for a normal user, and even I'm quite at loss here as I only managed to get generic vesa xorg working (after a lot of trial and error). At least with other distros (Centos 6.2 or Fedora 17 alpha) xorg with the generic vesa driver works out of the box (but those distros don't have the latest kernel with the GMA3600 DRM kernel module).
Re: [Mageia-dev] Mageia 2 Beta 2 is available
16.03.2012 12:56, tux99-...@uridium.org kirjutas: On Fri, 16 Mar 2012, Sander Lepik wrote: 16.03.2012 03:07, tux99-...@uridium.org kirjutas: On Thu, 15 Mar 2012, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ We need your tests and reports more than ever! Hi Anne, I gave feedback with regards to serious issues when trying beta 1 on a Cedarview Atom system, but apart from a couple of isolated replies (thanks to those who did reply) that unfortunately didn't solve the issues I got no further interest. And the bug number is? Does your post mean you looked at the info I provided in the previous emails and you concluded that I'm hitting a bug? Well, if it doesn't work for you out-of-the-box then yes, AFAIK you are hitting some kind of bug. It's bug at least for you. And you should report it so we can track it. Complaining in the list has no use here. You can't assign thread to some packager. If it comes out that it's not bug but some kind of other problem then there is solution for that - it's called RESOLVED - INVALID. ;) -- Sander
Re: [Mageia-dev] Mageia 2 Beta 2 is available
On 15/03/12 19:45, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ This is the last beta for Mageia 2 and before RC. We need your tests and reports more than ever! Thanks again all for the hard work Cheers -- Anne http://www.mageia.org You may want to fix this ;) Your download of Mageia 2 beta2 64bit DVD should start within a few seconds (download size is about ).
Re: [Mageia-dev] lighttpd and others now require apache
On 16/03/12 09:02, Guillaume Rousse wrote: Le 16/03/2012 03:01, Anssi Hannula a écrit : So I'd rather revert the change, and make lighttpd autonomous also. Unless someone can convince me there is an advantage having lighttpd executing as 'apache' :) The web applications policy has files being owned by 'apache' user, and I don't see how that could work if lighttpd used a different user: https://wiki.mageia.org/en/Web_applications_policy This policy was crafted with apache in mind only, not all available web servers. And its explicitely refers to apache integration, not generic webserver compatibility. For instance, the configuration file provided is apache-specific. Even if we have compatible file permissions, and if we asked packagers to also provide a default lighttpd configuration file (slighly more work), that would still be mostly theorical compatibility without actual testing from the packagers (many more work). So, rather than a potential compatibility, without documented limits, should we rather not make clear than adapting our web applications package to any other web server than apache is fully up to the end user ? I agree with Guillaume on that. Some web applications might work with lighttpd and apache, but the other web servers might be incompatible. It's better for now to say that web apps are packaged for apache, and maybe, in the wiki, people can write how to adapt to other web servers. Best, -- Malo
Re: [Mageia-dev] systemd network.service issues
On 16/03/12 03:45, Anssi Hannula wrote: Hi all! So, I've just upgraded my home server to mga2/cauldron. Something seems fishy in the network.service handling, systemd thinks it has failed: # systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Fri, 16 Mar 2012 05:25:09 +0200; 11min ago CGroup: name=systemd:/system/network.service ├ 4679 /sbin/ifplugd -I -b -i eth0 ├ 4723 /sbin/ifplugd -I -b -i eth1 └ 5372 /sbin/dhclient -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf /etc/dhclient-eth0.conf... Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Using detection mode: SIOCETHTOOL Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Initialization complete, link beat not detected. Mar 16 05:25:09 delta.onse.fi network[4397]: [161B blob data] Mar 16 05:25:09 delta.onse.fi network[4397]: [14B blob data] Mar 16 05:25:13 delta.onse.fi ifplugd(eth0)[4679]: Link beat detected. Mar 16 05:25:14 delta.onse.fi ifplugd(eth0)[4679]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPACK from 109.204.128.1 Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: client: Determining IP information for eth0... done. Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: Program executed successfully. Trying to restart it I seem to hit other issues: # systemctl restart network.service Job failed. See system journal and 'systemctl status' for details. # systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Fri, 16 Mar 2012 05:36:39 +0200; 3s ago Process: 8027 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/network.service ├ 8195 /sbin/ifplugd -I -b -i eth0 └ 8353 /sbin/dhclient -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf /etc/dhclient-eth0.conf... Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi dhclient[8261]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Mar 16 05:36:40 delta.onse.fi dhclient[8261]: DHCPACK from 109.204.128.1 Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: Determining IP information for eth0...NETLINK: Error: File exists Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: done. Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: NETLINK: Error: File exists Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: Program executed successfully. Any ideas? If not, I'll investigate this myself later. On a related note, I also got dropped to emergency console on first boot, not sure why was that (it didn't tell me the reason... maybe the reason was in another virtual console, but I didn't remember to check there at the time). I just exited the console and it continued to boot... I see the following in systemctl --failed: # systemctl --failed UNIT LOAD ACTIVE SUBJOB DESCRIPTION bootparamd.service loaded ESC[1;31mfailed failedESC[0m SYSV: The bootparamd server allows older Sun workstations to net boot from Linux boxes. It (along with rarp) is rarely used anymore; bootp and dhcp have mostly replaced both of them. fedora-loadmodules.service loaded ESC[1;31mfailed failedESC[0m Load legacy module configuration network.service loaded ESC[1;31mfailed failedESC[0m LSB: Bring up/down networking systemd-modules-load.service loaded ESC[1;31mfailed failedESC[0m Load Kernel Modules Not sure if its related, but I am seeing the same failures of fedora-loadmodules and systemd-modules-load, however the network comes up OK. [root@zmhost baz]# systemctl status systemd-modules-load.service systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: timeout) since Wed, 14 Mar 2012 13:38:28 +; 1 day and 22h ago Main PID: 391 CGroup: name=systemd:/system/systemd-modules-load.service [root@zmhost baz]# systemctl status fedora-loadmodules.service fedora-loadmodules.service - Load legacy module configuration Loaded: loaded (/lib/systemd/system/fedora-loadmodules.service; static) Active: failed (Result: exit-code) since Wed, 14 Mar 2012 13:38:28 +; 1 day and 22h ago Main
Re: [Mageia-dev] systemd network.service issues
'Twas brillig, and Anssi Hannula at 16/03/12 03:45 did gyre and gimble: Hi all! So, I've just upgraded my home server to mga2/cauldron. Something seems fishy in the network.service handling, systemd thinks it has failed: # systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Fri, 16 Mar 2012 05:25:09 +0200; 11min ago CGroup: name=systemd:/system/network.service ├ 4679 /sbin/ifplugd -I -b -i eth0 ├ 4723 /sbin/ifplugd -I -b -i eth1 └ 5372 /sbin/dhclient -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf /etc/dhclient-eth0.conf... Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Using detection mode: SIOCETHTOOL Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Initialization complete, link beat not detected. Mar 16 05:25:09 delta.onse.fi network[4397]: [161B blob data] Mar 16 05:25:09 delta.onse.fi network[4397]: [14B blob data] Mar 16 05:25:13 delta.onse.fi ifplugd(eth0)[4679]: Link beat detected. Mar 16 05:25:14 delta.onse.fi ifplugd(eth0)[4679]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPACK from 109.204.128.1 Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: client: Determining IP information for eth0... done. Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: Program executed successfully. Trying to restart it I seem to hit other issues: # systemctl restart network.service Job failed. See system journal and 'systemctl status' for details. # systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Fri, 16 Mar 2012 05:36:39 +0200; 3s ago Process: 8027 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/network.service ├ 8195 /sbin/ifplugd -I -b -i eth0 └ 8353 /sbin/dhclient -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf /etc/dhclient-eth0.conf... Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi dhclient[8261]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Mar 16 05:36:40 delta.onse.fi dhclient[8261]: DHCPACK from 109.204.128.1 Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: Determining IP information for eth0...NETLINK: Error: File exists Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: done. Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: NETLINK: Error: File exists Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: Program executed successfully. Any ideas? If not, I'll investigate this myself later. network.service fails here too, but I've not been able to work out exactly why. It doens't bother me too much tho' as all my devices are using network manager! THat said, it seems that network.service has still started an ifplugd for my wlan, despite the ifcfg file clearly saying that NM should take care of that interface... needs some investigating for sure. On a related note, I also got dropped to emergency console on first boot, not sure why was that (it didn't tell me the reason... maybe the reason was in another virtual console, but I didn't remember to check there at the time). I just exited the console and it continued to boot... Interesting. Was it a dracut shell or a systemd one? (sometimes hard to tell which is which, but the text usually tells you. Knowing which should help identify why. Does it happen on subsequent boots? I see the following in systemctl --failed: # systemctl --failed UNIT LOAD ACTIVE SUBJOB DESCRIPTION bootparamd.service loaded ESC[1;31mfailed failedESC[0m SYSV: The bootparamd server allows older Sun workstations to net boot from Linux boxes. It (along with rarp) is rarely used anymore; bootp and dhcp have mostly replaced both of them. fedora-loadmodules.service loaded ESC[1;31mfailed failedESC[0m Load legacy module configuration dmorgan reported this as well, but it's a really simple script and really shouldn't fail. I think it must be the /etc/rc.modules script that is likely failing here. Perhaps trying to modprobe a module that no longer exists due to old configuration? If possible can you debug the fedora-load-modules service and comment out one half of the script such that only the rc.modules
Re: [Mageia-dev] lighttpd and others now require apache
16.03.2012 11:02, Guillaume Rousse kirjoitti: Le 16/03/2012 03:01, Anssi Hannula a écrit : So I'd rather revert the change, and make lighttpd autonomous also. Unless someone can convince me there is an advantage having lighttpd executing as 'apache' :) The web applications policy has files being owned by 'apache' user, and I don't see how that could work if lighttpd used a different user: https://wiki.mageia.org/en/Web_applications_policy This policy was crafted with apache in mind only, not all available web servers. And its explicitely refers to apache integration, not generic webserver compatibility. For instance, the configuration file provided is apache-specific. Even if we have compatible file permissions, and if we asked packagers to also provide a default lighttpd configuration file (slighly more work), that would still be mostly theorical compatibility without actual testing from the packagers (many more work). So, rather than a potential compatibility, without documented limits, should we rather not make clear than adapting our web applications package to any other web server than apache is fully up to the end user ? It is rather easy for the user to create a lighttpd configuration file themselves etc, however it is much more difficult for the user to start changing/guessing the needed file permissions for the larger applications. Also, any changes would be overwritten by any upgrade, which is quite bad IMO. (and yes, I do have seen actual users using lighttpd with our webapp packages) -- Anssi Hannula
Re: [Mageia-dev] Please push openvpn
Ping... Enviado desde mi teléfono Verizon Wireless -Mensaje original- De: Luis Daniel Lucio Quiroz dlu...@okay.com.mx Para: mageia-dev@mageia.org Enviado: jue, mar 15, 2012 20:33:46 GMT+00:00 Asunto: [Mageia-dev] Please push openvpn It updates to 2.2.2, and adds S3 to fix bug 4936 Enviado desde mi teléfono Verizon Wireless
Re: [Mageia-dev] systemd network.service issues
16.03.2012 14:45, Colin Guthrie kirjoitti: 'Twas brillig, and Anssi Hannula at 16/03/12 03:45 did gyre and gimble: Hi all! So, I've just upgraded my home server to mga2/cauldron. Something seems fishy in the network.service handling, systemd thinks it has failed: # systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Fri, 16 Mar 2012 05:25:09 +0200; 11min ago CGroup: name=systemd:/system/network.service ├ 4679 /sbin/ifplugd -I -b -i eth0 ├ 4723 /sbin/ifplugd -I -b -i eth1 └ 5372 /sbin/dhclient -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf /etc/dhclient-eth0.conf... Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Using detection mode: SIOCETHTOOL Mar 16 05:25:09 delta.onse.fi ifplugd(eth1)[4723]: Initialization complete, link beat not detected. Mar 16 05:25:09 delta.onse.fi network[4397]: [161B blob data] Mar 16 05:25:09 delta.onse.fi network[4397]: [14B blob data] Mar 16 05:25:13 delta.onse.fi ifplugd(eth0)[4679]: Link beat detected. Mar 16 05:25:14 delta.onse.fi ifplugd(eth0)[4679]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Mar 16 05:25:15 delta.onse.fi dhclient[5312]: DHCPACK from 109.204.128.1 Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: client: Determining IP information for eth0... done. Mar 16 05:25:15 delta.onse.fi ifplugd(eth0)[4679]: Program executed successfully. Trying to restart it I seem to hit other issues: # systemctl restart network.service Job failed. See system journal and 'systemctl status' for details. # systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Fri, 16 Mar 2012 05:36:39 +0200; 3s ago Process: 8027 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/network.service ├ 8195 /sbin/ifplugd -I -b -i eth0 └ 8353 /sbin/dhclient -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid -cf /etc/dhclient-eth0.conf... Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi network[8027]: RTNETLINK answers: File exists Mar 16 05:36:39 delta.onse.fi dhclient[8261]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Mar 16 05:36:40 delta.onse.fi dhclient[8261]: DHCPACK from 109.204.128.1 Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: Determining IP information for eth0...NETLINK: Error: File exists Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: done. Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: client: NETLINK: Error: File exists Mar 16 05:36:40 delta.onse.fi ifplugd(eth0)[8195]: Program executed successfully. Any ideas? If not, I'll investigate this myself later. network.service fails here too, but I've not been able to work out exactly why. It doens't bother me too much tho' as all my devices are using network manager! THat said, it seems that network.service has still started an ifplugd for my wlan, despite the ifcfg file clearly saying that NM should take care of that interface... needs some investigating for sure. On a related note, I also got dropped to emergency console on first boot, not sure why was that (it didn't tell me the reason... maybe the reason was in another virtual console, but I didn't remember to check there at the time). I just exited the console and it continued to boot... Interesting. Was it a dracut shell or a systemd one? (sometimes hard to tell which is which, but the text usually tells you. I think it was a systemd one (it seemed to be quite late in the boot, when I exited it the next thing it did was build DKMS stuff). Knowing which should help identify why. Does it happen on subsequent boots? No idea yet, but will reboot the system now. I see the following in systemctl --failed: # systemctl --failed UNIT LOAD ACTIVE SUBJOB DESCRIPTION bootparamd.service loaded ESC[1;31mfailed failedESC[0m SYSV: The bootparamd server allows older Sun workstations to net boot from Linux boxes. It (along with rarp) is rarely used anymore; bootp and dhcp have mostly replaced both of them. fedora-loadmodules.service loaded ESC[1;31mfailed failedESC[0m Load legacy module configuration dmorgan reported this as well, but it's a really simple script and really shouldn't fail. I think it must be the /etc/rc.modules script that is
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release nginx-1.0.10-2.mga2
Le 16/03/2012 10:46, Frederik Himpe a écrit : On Fri, 16 Mar 2012 08:37:26 +0100, Thierry Vignaud wrote: On 15 March 2012 20:47, guillomovitch buildsystem-dae...@mageia.org wrote: guillomovitchguillomovitch 1.0.10-2.mga2: by the way, you also need to patch it or to update it to 1.0.14 to fix security issue CVE-2012-1180: http://seclists.org/oss-sec/2012/q1/644 In progress... -- BOFH excuse #47: Complete Transient Lockout
[Mageia-dev] [systemd error flag] Re: [changelog] [RPM] cauldron core/release nginx-1.0.10-2.mga2
Le 16/03/2012 09:51, Guillaume Rousse a écrit : Le 16/03/2012 08:37, Thierry Vignaud a écrit : On 15 March 2012 20:47, guillomovitchbuildsystem-dae...@mageia.org wrote: guillomovitchguillomovitch 1.0.10-2.mga2: + Revision: 223512 - sync configuration files with fedora package - drop useless apache dependency - spec cleanup - systemd support ahem: 8/36: nginx ##warning: /etc/nginx/nginx.conf created as /etc/nginx/nginx.conf.rpmnew ### Migrating sysvinit service 'nginx' to systemd native unit 'nginx.service' for target 'graphical.target' warning: %post(nginx-1.0.10-2.mga2.x86_64) scriptlet failed, exit status 1 There is no specific handling for this issue in nginx spec file, si I'd rather think of a generic migration issue. Maybe the fact than pid file location changed between the two releases ? Let me call a joker... Colin :) ? -- BOFH excuse #193: Did you pay the new Support Fee?
[Mageia-dev] freeze push: nginx
security issue: http://mailman.nginx.org/pipermail/nginx-announce/2012/76.html -- BOFH excuse #174: Backbone adjustment
Re: [Mageia-dev] [systemd error flag] Re: [changelog] [RPM] cauldron core/release nginx-1.0.10-2.mga2
'Twas brillig, and Guillaume Rousse at 16/03/12 13:55 did gyre and gimble: Le 16/03/2012 09:51, Guillaume Rousse a écrit : Le 16/03/2012 08:37, Thierry Vignaud a écrit : On 15 March 2012 20:47, guillomovitchbuildsystem-dae...@mageia.org wrote: guillomovitchguillomovitch 1.0.10-2.mga2: + Revision: 223512 - sync configuration files with fedora package - drop useless apache dependency - spec cleanup - systemd support ahem: 8/36: nginx ##warning: /etc/nginx/nginx.conf created as /etc/nginx/nginx.conf.rpmnew ### Migrating sysvinit service 'nginx' to systemd native unit 'nginx.service' for target 'graphical.target' warning: %post(nginx-1.0.10-2.mga2.x86_64) scriptlet failed, exit status 1 There is no specific handling for this issue in nginx spec file, si I'd rather think of a generic migration issue. Maybe the fact than pid file location changed between the two releases ? Let me call a joker... Colin :) ? :) Not sure why the scriptlet failed This is part of %_post_service btw. I guess I'll have to have a look. 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] [Freeze] please let in xonotic
Op vrijdag 16 maart 2012 08:57:45 schreef Samuel Verschelde: [...] It's already the case. If you re-read Ennael's mail about version freeze, it says exactly that about exceptions. Samuel i'm looking at this mail, but don't see the exact same exceptions? https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html which email are you looking at?
Re: [Mageia-dev] [Freeze] please let in xonotic
On Fri, Mar 16, 2012 at 15:11, Maarten Vanraes al...@rmail.be wrote: Op vrijdag 16 maart 2012 08:57:45 schreef Samuel Verschelde: [...] It's already the case. If you re-read Ennael's mail about version freeze, it says exactly that about exceptions. Samuel i'm looking at this mail, but don't see the exact same exceptions? https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html which email are you looking at? Criteria for accepting updates -- Since we aim for stability, the criteria would be near the ones of updates.
Re: [Mageia-dev] [Freeze] please let in xonotic
Op vrijdag 16 maart 2012 16:15:22 schreef Pascal Terjan: On Fri, Mar 16, 2012 at 15:11, Maarten Vanraes al...@rmail.be wrote: Op vrijdag 16 maart 2012 08:57:45 schreef Samuel Verschelde: [...] It's already the case. If you re-read Ennael's mail about version freeze, it says exactly that about exceptions. Samuel i'm looking at this mail, but don't see the exact same exceptions? https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html which email are you looking at? Criteria for accepting updates -- Since we aim for stability, the criteria would be near the ones of updates. ah, like this... i read this as near (ie: not exact) and then the next parts were clarifications on the criteria (and the client/server protocol ones weren't in there). my bad, although in my defence, it could have been worded better, or a wiki policy with a link to it in this email. imho, if this were clearer, then i would guess misc would on his original email likely ask questions regarding client/server protocol changes as well... so i can only conclude that it might not have been 100% clear for everyone. (and i wasn't the only one)
Re: [Mageia-dev] Freeze push: mariadb (beta)
16.03.2012 01:24, Maarten Vanraes kirjoitti: Please push mariadb: mariadb (and mysql) seem to have an odd method of increasing version number for each of there alpha/beta/rc/final versions. This updates to the 5.5 Beta release (it's not announced yet, but they are waiting for it to hit all the mirrors) Normally, the final is expected to released in about 2 weeks. Submitted. -- Anssi Hannula
Re: [Mageia-dev] new urpmi release ?
On 16 March 2012 08:25, Thierry Vignaud thierry.vign...@gmail.com wrote: I have fixed two bugs in urpmi bash completion: - https://bugs.mageia.org/show_bug.cgi?id=373 - https://bugs.mageia.org/show_bug.cgi?id=4937 However, I'm unaware of any other changes in the perl code itself. Is it sage to proceed with a new release ? It is. Only translations have been updated since last release Just run the testsuite once as root before uploading. It should pass now that I've fixed the regressions from mdv@2010
Re: [Mageia-dev] lighttpd and others now require apache
On 03/16/2012 01:00 PM, Malo wrote: It's better for now to say that web apps are packaged for apache, and maybe, in the wiki, people can write how to adapt to other web servers. Maybe the approach used for the backuppc package is a good compromise: The package contains and installs the apache server definition. But the package also contains a README.MGA file that - among other items - contains a recommendation on how to create a backuppc server for lighttpd. This approach is perfectly in line with the packaged-for-apache concept, and it makes life easy for users who - for whatever reason - need to run lighttpd. The mageia wiki is great, and there is interest to push people to go to the wiki. But a README file that comes with the package is the first place where a user will look for this kind of information; and it is more likely to get updated with a new release of backuppc than a - separate - page in the wiki. Juergem
Re: [Mageia-dev] new urpmi release ?
Le 16/03/2012 18:09, Thierry Vignaud a écrit : On 16 March 2012 08:25, Thierry Vignaudthierry.vign...@gmail.com wrote: I have fixed two bugs in urpmi bash completion: - https://bugs.mageia.org/show_bug.cgi?id=373 - https://bugs.mageia.org/show_bug.cgi?id=4937 However, I'm unaware of any other changes in the perl code itself. Is it sage to proceed with a new release ? It is. Only translations have been updated since last release Just run the testsuite once as root before uploading. It should pass now that I've fixed the regressions from mdv@2010 Actually, I'd prefer to let you handle it. Yes, I know, I'm a lazy opportunist :) -- BOFH excuse #189: SCSI's too wide.
Re: [Mageia-dev] Please push openvpn
16.03.2012 15:34, Luis Daniel Lucio Quiroz kirjoitti: Ping... /Enviado desde mi teléfono Verizon Wireless/ -Mensaje original- *De: *Luis Daniel Lucio Quiroz dlu...@okay.com.mx* Para: *mageia-dev@mageia.org* Enviado: *jue, mar 15, 2012 20:33:46 GMT+00:00* Asunto: *[Mageia-dev] Please push openvpn It updates to 2.2.2, and adds S3 to fix bug 4936 /Enviado desde mi teléfono Verizon Wireless/ Submitted. -- Anssi Hannula
[Mageia-dev] freeze push: perl_checker, perl-URPM
Hi Please let in: - perl_checker: It has been updated for better tracking issues within perl-URPM urpmi - perl-URPM: fix a crash with urpme --env See you
Re: [Mageia-dev] freeze push: perl_checker, perl-URPM
On Fri, 16 Mar 2012, Thierry Vignaud wrote: Hi Please let in: - perl_checker: It has been updated for better tracking issues within perl-URPM urpmi - perl-URPM: fix a crash with urpme --env pushed
Re: [Mageia-dev] [bugs] [Bug 3466] Add radeon-firmware in the Isos or add radeon.modeset=0 option
On Fri, Mar 16, 2012 at 1:19 PM, Priscus bugzilla-dae...@mageia.org wrote: https://bugs.mageia.org/show_bug.cgi?id=3466 --- Comment #26 from Priscus wizz...@twa-corbies.net 2012-03-16 21:19:18 CET --- (In reply to comment #23) That is as intended: all radeon video cards need the firmware files for KMS Just fyi. My 7 year old Radeon 9200 SE doesn't have any firmware available, and worked fine without any, prior to Mageia 2. With Magiea 2, I have to set radeon.modeset=0 to avoid the thousands of lines of error messages. Probably because KMS was not yet the default for the Radeon 9200? Needing the firmware is a rather recent development. The R9200 firmware is the usual all-in-one radeon-firmware package. The beta2 still needs radeon.modeset=0 at first boot. I know it is in the errata, but non-technical users will not look at it, and they're the one to need it most. It would probably be better to configure it by default. This would give everyone a working system at first boot (and typing the line is a bother when you do not use qwerty: you get the a.m to guess on azerty, for example). It should be possible to automagically remove the line from the bootloader with a post-install script in radeon-firmware, with bonus points for leaving it in failsafe mode. Even without this last luxury, I think it is much better to give users a working setup by default. The current version will give bad reviews from blogs with more reach than technical know-how (I'll not give names, but I'm thinking of some) and tonnes of questions/complaints in the forums, with users unable to understand they all have the same damn problem (happened for Mageia 1). Mageia and the community would be better off without the noise and botheration. Best regards, and thank you for all your work. -- Configure bugmail: https://bugs.mageia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. +1. I can't recommend Mageia to friends when there is a high probability that there system will be unusable on first boot. On two of my three systems I couldn't even a command-line because the video for that was corrupted as well. --Jeff
Re: [Mageia-dev] lighttpd and others now require apache
16.03.2012 19:47, Juergen Harms kirjoitti: On 03/16/2012 01:00 PM, Malo wrote: It's better for now to say that web apps are packaged for apache, and maybe, in the wiki, people can write how to adapt to other web servers. Maybe the approach used for the backuppc package is a good compromise: The package contains and installs the apache server definition. But the package also contains a README.MGA file that - among other items - contains a recommendation on how to create a backuppc server for lighttpd. This approach is perfectly in line with the packaged-for-apache concept, and it makes life easy for users who - for whatever reason - need to run lighttpd. The mageia wiki is great, and there is interest to push people to go to the wiki. But a README file that comes with the package is the first place where a user will look for this kind of information; and it is more likely to get updated with a new release of backuppc than a - separate - page in the wiki. This doesn't work for webapps that need server-writable directories/files that are owned by the server user, since any changes to the ownerships the user makes would be overridden on upgrade. Hence I suggest a single user id to be used. (I'm fine with any other solution which works as well) -- Anssi Hannula
