Since 2002 amavisd-new doesn't require spamd (see bug #11245), so, when sa-update is run, amavisd-new should reload the rules. The problem is compounded by the fact that sa-update is run by a script provided by spamassassin-spamd, which isn't required, so putting an "/etc/rc.d/init.d/amavisd reload" there isn't a solution. Adding a cron script to amavisd-new isn't a solution neither: while spamd isn't needed by amavisd, it could be installed and used alongside it, and in this case only the first script running sa-update would notice an update and restart the corresponding daemon, while the other wouldn't see it. I suggest a solution like the one in debian: 1) the script to run sa-update should go in the spamassassin package (instead of spamassassin-spamd) 2) when that scripts sees that sa-update updated the rules, it does a "run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d" (that maybe should be /etc/mail/spamassassin/sa-update-hooks.d in mageia?) 3) the spamassassin-spamd package could then have a file in sa-update-hooks.d that restarts it, an likewise amavisd-new could drop a file there to have its rules reloaded As a reference the debian spamassassin package is here: http://packages.debian.org/wheezy/spamassassin Note that I see the problem with mageia 2, but looking at svnweb it should be the same in cauldron. Reproducible: Steps to Reproduce:
Created attachment 4356 [details] /etc/cron.daily/spamassassin script from debian This is the /etc/cron.daily/spamassassin script in the debian package. With some modifications (paths, functions, etc.) it could be adapted to mageia.
This could be auomated by a rpm filetrigger
CC: (none) => tmb
I don't see how a filetrigger could help here
Keywords: (none) => TriagedAssignee: bugsquad => thomasSource RPM: (none) => amavisd-new
Status: NEW => ASSIGNED
This is now resolved in cauldron. But I need to do some further testing
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
I've changed the version since I recently upgraded the server to mageia 3 and the bug is still valid there.
Version: 2 => 3
I consider this a feature request not an bug. In mga2 and mga3 we have spamassassin-spamd and spamassassin-spamc as a requires. So we are running sa-update as a cron job every day. I have changed this in cauldron, using a script from Fedora, but it still needs some testing. Thomas
The problem is that even so the script in spamassassing-spamd just restarts spamd but not amavisd (and since amavisd isn't using spamd it will not use the new rules). So it's not just a feature request.
I agree, it needs a reload. The script in Cauldron seems to work now, but I need to do some additional testing.
OK, the script in cauldron now does reload amavisd after sa-update. I will port it back to mga3 sometimes next week.
The packages are now in updates_testing. I have been running this update on my server and the updates are done per the scripts. To test it, install the package and check the logs and journal the next day. The cron job runs at 4:10am and the update script has a random delay so that not all servers run the update at the exact same time and overwhelms the update server. The packages that have been updated and need to be updated on the test machine for the test to succeed are: amavisd-new-2.8.0-14.2 spamassassin-3.3.2-13.1 spamassassin-compile-3.3.2-13.1 spamassassin-tools-3.3.2-13.1 Remove for the test: spamassassin-spamd spamassassin-spamc After the test completed successful add and and retest with the updated spamassassin-spamd-3.3.2-13.1 spamassassin-spamc-3.3.2-13.1 assigning this now to QA
CC: (none) => thomasAssignee: thomas => qa-bugs
Advisory: Since 2002 amavisd-new doesn't require spamd, so, when sa-update is run, amavisd-new should reload the rules instead. This update does reload amavisd and/or spamd if they are running after the the cron job has triggered an sa-update. See comment 11 about the successful test. Updated packages in core/updates_testing: ======================== amavisd-new-2.8.0-14.2.mga3.noarch.rpm spamassassin-3.3.2-13.1 spamassassin-compile-3.3.2-13.1 spamassassin-tools-3.3.2-13.1 spamassassin-spamd-3.3.2-13.1 spamassassin-spamc-3.3.2-13.1 spamassassin-3.3.2-13.3.mga3.src.rpm
Whiteboard: (none) => has_procedureCC: (none) => stormi
Luca Olivetti: Could you test the new packages from updates_testing and report if they fix your problem? Please also indicate which platfrom (i586 or x86_64) you are testing on and (if possible) how you tested. This would help the QA team to speed up the testing of this update, and make it available for everybody as soon as possible. Thanks in advance!
CC: (none) => wassi
I manually updated to spamassassin-3.3.2-13.3.mga3.x86_64.rpm and amavisd-new-2.8.0-14.2.mga3.noarch.rpm, I removed spamd and spamc a long time ago (with --nodeps) and I never installed spamassassin-compile or spamassassin-tools. I also removed my cron script to update spamassassin and restart amavisd since the new package already does it. It's not as clean as the debian solution but it seems to be working.
Blocks: (none) => 12587
Blocks: 12587 => (none)
I recently upgraded from Mageia 2 to Mageia 4, and note that the script removed the sa-compile step. The test to determine whether sa-compile is needed is whether this line appears in a .pre file in /etc/mail/spamassassin: loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody
CC: (none) => Dan.mcdonald
Hmm, comment 12 seems wrong. There is no package called spamassassin-compile (I checked with "find -name spamassassin-compile*" on the distro tree). Can you clarify if that package is missing or somehow otherwise provided?
CC: (none) => mageia
Something that does seem odd however is that the spamd systemd unit used to be called spamassassin.service and it is now called spamd.service. When updating the packages, it left things in a bit of a strange state. You'll note that previously I provided a symlink to spamd.service for spamassassin.service which in the commit that renamed the service file commented out. If things are going to be changed round, a similar compatibility symlink should be provided and care should be taken to create appropriate symlinks prior to calling post service. Just renaming units is not recommended unless you take care to ensure you transition smoothly. Commit in question: http://svnweb.mageia.org/packages/updates/3/spamassassin/current/SPECS/spamassassin.spec?r1=563920&r2=563919&pathrev=563920
I note that this has also been done in cauldron and thus mga4 too :( So I guess it's too late to bother fixing it, but probably something to put in errata. Users will have to: 1. Manually kill any spamd processes 2. rm the /etc/systemd/system/multi-user.target.wants/spamassassin.service 3. systemctl enable spamd 4. systemctl start spamd to fix things up.
Oh and for the record, I chose the spamassassin.service name to remain compatible with fedora/rhel and (hopefully) upstream. Now we'll be doing something different and may eventually have to adapt to whatever the upstream name is in due course. All in all, this change wasn't needed so it's a shame it's gone through to releases.
(In reply to Colin Guthrie from comment #16) > Hmm, comment 12 seems wrong. There is no package called spamassassin-compile > (I checked with "find -name spamassassin-compile*" on the distro tree). > > Can you clarify if that package is missing or somehow otherwise provided? The package is there: [dmcdonald@ns1 ~]$ which sa-compile /usr/bin/sa-compile [dmcdonald@ns1 ~]$ rpm -qf /usr/bin/sa-compile spamassassin-sa-compile-3.3.2-21.mga4 But sa-compile needs to be run after each sa-update. That's not happening with the script /usr/share/spamassassin/sa-update.cron provided by spamassassin-3.3.2-21.mga4
@Daniel are you sure about sa-compile? The sa-update manpage doesn't say so: Note that "sa-update" will not restart "spamd" or otherwise cause a scanner to reload the now-updated ruleset automatically. Instead, "sa-update" is typically used in something like the following manner: sa-update && /etc/init.d/spamassassin reload @Colin, maybe you should open a bug regarding spamassassin: amavisd-new doesn't require spamd
(In reply to Luca Olivetti from comment #21) > @Daniel are you sure about sa-compile? The sa-update manpage doesn't say so: > If you have enabled the Mail::SpamAssassin::Plugin::Rule2XSBody plugin, then sa-compile is required each time you update rules, before you reload whichever daemon is used. I have an sa-update.cron file from Mandriva Enterprise Server 5 that I was using for my local builds. Oden Eriksson had added some directives in /etc/sysconfig/spamd that would conditionally trigger the sa-compile action. I like the current script much better, except that I need the shim to get sa-compile run before restarting amavisd
Ahh thanks Daniel. Seems the packages were listed incorrectly in comments 11 & 12. I don't have that package installed here (don't think I've had it for a while), and after installing the other packages in the update last night, I found this morning that amavisd service had failed: Feb 16 04:51:46 marley.rasta.guthr.ie systemd[1]: Reloading AMAVIS interface between MTA and content checkers. Feb 16 04:51:48 marley.rasta.guthr.ie amavisd[14837]: Signalling a SIGHUP to a running daemon [8445] Feb 16 04:51:48 marley.rasta.guthr.ie amavis[8445]: (!)Net::Server: 2014/02/16-04:51:48 HUP'ing server Feb 16 04:51:48 marley.rasta.guthr.ie systemd[1]: Reloaded AMAVIS interface between MTA and content checkers. Feb 16 04:51:48 marley.rasta.guthr.ie systemd[1]: amavisd.service: main process exited, code=exited, status=13/n/a Feb 16 04:51:48 marley.rasta.guthr.ie systemd[1]: Unit amavisd.service entered failed state So it seems the process entered it's failed state (i.e. main process exited) after receiving a sighup. Doing this test currently it does indeed seem to crash things: [root@marley ~]# systemctl status amavisd.service amavisd.service - AMAVIS interface between MTA and content checkers Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled) Active: active (running) since Sun, 2014-02-16 11:47:44 GMT; 9s ago Process: 22961 ExecReload=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf -P /run/amavis/amavis.pid reload (code=exited, status=0/SUCCESS) Process: 23029 ExecStart=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf -P /run/amavis/amavis.pid (code=exited, status=0/SUCCESS) Main PID: 23031 (/usr/sbin/amavi) CGroup: name=systemd:/system/amavisd.service â 23031 /usr/sbin/amavisd (master) â 23037 /usr/sbin/amavisd (virgin child) â 23038 /usr/sbin/amavisd (virgin child) Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Found decoder for .cab at /usr/bin/cabextract Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Found decoder for .tnef at /usr/bin/tnef Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Found decoder for .exe at /usr/bin/unrar; /usr/bin/lha Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: No decoder for .F Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: No decoder for .arj Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: No decoder for .zoo Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Using primary internal av scanner code for ClamAV-clamd Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Deleting db files snmp.db,__db.001,__db.002,nanny.db,__db.003 in /var/lib/amavis/db Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Creating db in /var/lib/amavis/db/; BerkeleyDB 0.51, libdb 5.3 [root@marley ~]# systemctl reload amavisd.service [root@marley ~]# systemctl status amavisd.service amavisd.service - AMAVIS interface between MTA and content checkers Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled) Active: failed (Result: exit-code) since Sun, 2014-02-16 11:48:02 GMT; 3s ago Process: 23054 ExecReload=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf -P /run/amavis/amavis.pid reload (code=exited, status=0/SUCCESS) Process: 23029 ExecStart=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf -P /run/amavis/amavis.pid (code=exited, status=0/SUCCESS) Main PID: 23031 (code=exited, status=13) CGroup: name=systemd:/system/amavisd.service Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Using primary internal av scanner code for ClamAV-clamd Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Deleting db files snmp.db,__db.001,__db.002,nanny.db,__db.003 in /var/lib/amavis/db Feb 16 11:47:44 marley.rasta.guthr.ie amavis[23031]: Creating db in /var/lib/amavis/db/; BerkeleyDB 0.51, libdb 5.3 Feb 16 11:48:01 marley.rasta.guthr.ie systemd[1]: Reloading AMAVIS interface between MTA and content checkers. Feb 16 11:48:02 marley.rasta.guthr.ie amavisd[23054]: Signalling a SIGHUP to a running daemon [23031] Feb 16 11:48:02 marley.rasta.guthr.ie amavis[23031]: (!)Net::Server: 2014/02/16-11:48:02 HUP'ing server Feb 16 11:48:02 marley.rasta.guthr.ie systemd[1]: Reloaded AMAVIS interface between MTA and content checkers. Feb 16 11:48:02 marley.rasta.guthr.ie systemd[1]: amavisd.service: main process exited, code=exited, status=13/n/a Feb 16 11:48:02 marley.rasta.guthr.ie systemd[1]: Unit amavisd.service entered failed state So NAK on this update from me unless someone can explain to me what's wrong!!!
Seems to be working fine here (otherwise I'd have heard from my angry users): [luca@mail ~]$ sudo systemctl reload amavisd [luca@mail ~]$ sudo systemctl status amavisd amavisd.service - AMAVIS interface between MTA and content checkers Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled) Active: active (running) since Tue, 2014-02-11 10:32:22 CET; 5 days ago Process: 18572 ExecReload=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf -P /run/amavis/amavis.pid reload (code=exited, status=0/SUCCESS) Process: 1390 ExecStart=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf -P /run/amavis/amavis.pid (code=exited, status=0/SUCCESS) Main PID: 3842 (/usr/sbin/amavi) CGroup: name=systemd:/system/amavisd.service â 3842 /usr/sbin/amavisd (master) â 18577 /usr/sbin/amavisd (virgin child) â 18578 /usr/sbin/amavisd (virgin child) â 18579 /usr/sbin/amavisd (virgin child) â 18580 /usr/sbin/amavisd (virgin child) â 18581 /usr/sbin/amavisd (virgin child) [luca@mail ~]$ rpm -qi amavisd-new Name : amavisd-new Version : 2.8.0 Release : 14.2.mga3 Architecture: noarch Install Date: dv 31 gen 2014 19:00:14 CET Group : Networking/Mail Size : 3284420 License : GPL Signature : RSA/SHA1, ds 21 des 2013 23:58:04 CET, Key ID b742fa8b80420f66 Source RPM : amavisd-new-2.8.0-14.2.mga3.src.rpm Build Date : ds 21 des 2013 23:56:29 CET Build Host : sucuk.mageia.org Relocations : (not relocatable) Packager : spuhler <spuhler> Vendor : Mageia.Org URL : http://www.ijs.si/software/amavisd/ Summary : A Mail Virus Scanner Description : AMaViS is a perl script that interfaces a Mail Transport Agent (MTA) with one or more virus scanners (not provided).
OK, so it's obviously not a universal problem. I would likely blame my system for now as this is a very old install and has been constantly upgraded. I suspect something is wrong at my end. I'll see what more I can find out today.
My mail server started life as mageia 2, later upgraded to mageia 3 (and I will upgrade it to 4 as soon as I have the time and determination to do it). Trying to look for differences between your log and mine (apart from the fact that I don't log through systemd), where you have amavis[23031]: (!)Net::Server: 2014/02/16-11:48:02 HUP'ing server I have amavis[3842]: starting. (warm) /usr/sbin/amavisd at mail.wetron.local amavisd-new-2.8.0 (20120630), Unicode aware, LC_CTYPE="ca_ES.UTF-8", LANG= "ca_ES.UTF-8"
Is this one ready for QA or is it still being worked on?
I think it's OK For QA. My server I was testing on has now been upgraded and I have the same problem in MGA4, but as mentioned above, I suspect it's due to some changes I've made over the years and not a very good test bed. I'll let others test it as I don't trust myself!
FWIW, I found the problem I was having and it *is* a local config problem. The /etc/amavisd/amavisd.conf file needs to be group owned+readable by amavis user. Out of the box, this is how the RPM is configured, but my system got out of sync at some point over the years. I got the hint from this post: http://lists.amavis.org/pipermail/amavis-users/2012-July/001738.html After correcting this, the reload works fine. Perhaps we should add a safety chgrp+chmod g+w to the %post now that we're using reload as it seems I'm not alone getting bitten by this (see #12755)
I added a %post to fix ensure permissions are correct (I meant g+r above, not g+w!). Updated packages in core/updates_testing: ======================== amavisd-new-2.8.0-14.3.mga3.noarch.rpm + the spamassassin pkgs mentioned comment 12. I also applied the same fix to the MGA4 packages which were mentioned in bug #12755 I figure they can just be included in this update but if you'd prefer to keep it separate that's OK too (I'm trying to save hassle but if the opposite is true, please do what you think is best!) MGA 4 SRPM: amavisd-new-2.8.2-0.rc1.4.1.mga4.noarch.rpm The only difference on MGA4 is to chgrp/chmod the config file. Simply installing it and checking the permissions/ownership is sufficient to test it (and as it's noarch, I guess only one arch of testing is strictly needed).
Version: 3 => 4Whiteboard: has_procedure => MGA3TOO has_procedure
This bug is a bit chaotic and difficult to follow. It looks like we now have updates for mga3 and mga4 and have different advisories for each. Could somebody please write them? Is there a simple test procedure please? Compiling the package lists into one place. Is this correct? MGA3 ==== amavisd-new-2.8.0-14.3.mga3.noarch.rpm spamassassin-3.3.2-13.1 spamassassin-compile-3.3.2-13.1 spamassassin-tools-3.3.2-13.1 spamassassin-spamd-3.3.2-13.1 spamassassin-spamc-3.3.2-13.1 from spamassassin-3.3.2-13.3.mga3.src.rpm amavisd-new-2.8.0-14.3.mga3.src.rpm MGA4 ==== amavisd-new-2.8.2-0.rc1.4.1.mga4.noarch.rpm from amavisd-new-2.8.2-0.rc1.4.1.mga4.src.rpm Thankyou.
Hi Claire. Please see my comments above where I pre-answered your questions: (In reply to Colin Guthrie from comment #30) > I also applied the same fix to the MGA4 packages which were mentioned in bug > #12755 I figure they can just be included in this update but if you'd prefer > to keep it separate that's OK too (I'm trying to save hassle but if the > opposite is true, please do what you think is best!) Would you prefer I keep it separate for MGA4? - happy to do so as mentioned above. > MGA 4 SRPM: > amavisd-new-2.8.2-0.rc1.4.1.mga4.noarch.rpm > > The only difference on MGA4 is to chgrp/chmod the config file. Simply > installing it and checking the permissions/ownership is sufficient to test > it (and as it's noarch, I guess only one arch of testing is strictly needed). The only test procedure on MGA4 is to simply install it and check the permissions of the /etc/amavisd/amavisd.conf as as per the package (rpm -V) The test procedure for MGA3 is noted above, but I can confirm the previous package worked fine for me other than this permission problem (and that's the only change I made to the package in the current iteration).
No bother using one bug colin as long as it's clearly presented. This one seems to have grown and become quite convoluted. I'm having difficulty following what has been done where and why, and what to look for. Please see https://wiki.mageia.org/en/Example_update_advisory_announcement This is the kind of thing we have to put together when we validate the update, they go onto http://advisories.mageia.org and as emails to updates-announce ML. Could you please bring everything together for us. Thanks.
If Luca and Daniel (and Colin too) can test i586 and x86_64 for mga3 and mga4 between you then we will just need the advisory text
As per my comment #14 I already tested under mga3/x86_64. I now also installed the package posted by Colin with (apparently) no adverse effects. I also setup a vm with mga4/x86_64, installing amavisd from the normal repositories which has already the fix. I then installed the package updated by Colin and, again, no apparent problem. I only tested that the commands systemctl start amavisd systemctl reload amavisd systemctl stop amavisd work as they should (and they do). I have no idea on how to enable the Mail::SpamAssassin::Plugin::Rule2XSBody plugin, so I didn't test sa-compile (I don't even have it installed). Note anyway that the real fix for this particular bug ("amavisd should be reloaded after running sa-update") is in spamassassin, not in amavisd-new.
Yup, mga4 64 tested OK (it's trivial to test - the only change is during the install proceedure itself - as it's noarch, I'd be tempted to say mga4-32-ok too...). I've updated a production mga3 64 box today too, so will report back tomorrow after the cronjob runs.
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga3-64-ok
Yeah the production box continues to be fine. I used the wrong tag last time (meant mga4-64-ok but actually put mga3-64-ok), but now I really do want mga3-64-ok, so I will add mga4-64-ok... not confusing at all ;) As this is noarch, I'd be tempted to call this sufficient testing to push it out.
Whiteboard: MGA3TOO has_procedure mga3-64-ok => MGA3TOO has_procedure mga3-64-ok mga4-64-ok
Testing mga4 32 Not sure what to check for this but amavisd updates cleanly and the service can be started and stopped ok. Colin could you post suitable advisories please.
Whiteboard: MGA3TOO has_procedure mga3-64-ok mga4-64-ok => MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok
Testing complete on Mageia 3 i586. Advisory added to svn based on comment 11, and current srpms. Validating the update. Someone from the sysadmin team please push 11246.adv to updates.
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-64-ok mga4-32-ok mga4-64-ok MGA3-32-OK advisoryCC: (none) => davidwhodgins, sysadmin-bugs
Again, don't forget spamassassin.
(In reply to Thomas Spuhler from comment #40) > Again, don't forget spamassassin. There is nothing in Mageia 4 core updates testing for spamassassin. In the advisory, I've included the srpms ... src: 3: core: - amavisd-new-2.8.0-14.3.mga3 - spamassassin-3.3.2-13.3.mga3 4: core: - amavisd-new-2.8.2-0.rc1.4.1.mga4 Should this update have the validated tag removed until spamassassin is also updated on Mageia 4?
(In reply to Dave Hodgins from comment #41) > (In reply to Thomas Spuhler from comment #40) > > Again, don't forget spamassassin. > > There is nothing in Mageia 4 core updates testing for spamassassin. In the > advisory, I've included the srpms ... > src: > 3: > core: > - amavisd-new-2.8.0-14.3.mga3 > - spamassassin-3.3.2-13.3.mga3 > 4: > core: > - amavisd-new-2.8.2-0.rc1.4.1.mga4 > > Should this update have the validated tag removed until spamassassin is also > updated on Mageia 4? spamassassin in mga4 is fine. It was updated before the release
Thanks. The full advisory can be viewed at http://svnweb.mageia.org/advisories/11246.adv?revision=1192&view=markup As noted, spamassassin is included for Mageia 3. Someone from the sysadmin team please push 11246.adv to updates.
(In reply to claire robinson from comment #38) > Colin could you post suitable advisories please. Sorry, I'm currently on holiday so can't really do much from here. Dave seems to have it in hand tho' - sorry for any confusion.
Update pushed: http://advisories.mageia.org/MGAA-2014-0074.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED