So let me get this straight...

they asked you to ask Mageia users to enable a feature that nether they nor you as the maintainer checked/verified to be working when pushing 5.5.25-1 and posting the request on mls and forum ....


And now you ask QA to do the mariadb tests all over again for no real enduser gain ?

IMHO this is not worth the effort at this time, not to mention useless downloads/installs for endusers stable systems... imho it can wait until the next 
real fixes to mariadb needs to be pushed...

But I'll let QA decide

CC: (none) => tmb

AL13N, do you foresee other mariadb updates in the coming weeks?

CC: (none) => stormi

(In reply to comment #1)
> So let me get this straight...
> 
> they asked you to ask Mageia users to enable a feature that nether they nor you
> as the maintainer checked/verified to be working when pushing 5.5.25-1 and
> posting the request on mls and forum ....

ah no... it is my fault.

I saw the OS stats, and thought it'd be nice to have more Linux (mageia) stats. So i requested this, after i tested myself.

But alas, even though the post worked, one of the fields wasn't correctly filled (OS stat). I noticed this bug only yesterday, because the linux stat wasn't increasing. at first i thought only the stat wasn't regenerated.

(the post call did succeed, so the logs showed that all was ok)

the 5.5.26 is in the works, but it might be until end of august before it goes through. and afaik there is no major or security bug.

So, i'm not sure if i'll update if there isn't any such bug.

for testing, i thought it might be nice for the people who did have enabled feedback plugin before to test this.

see https://forums.mageia.org/en/viewtopic.php?f=4&t=3147

AL13N, what about asking to those who have enabled the plugin to install the update candidate (so that the feedback works for them already) and report here that everything goes well, so that QA doesn't have to test this update? You can tell them that you guarantee that, although this is an update candidate, you broke nothing :)

Then, depending on the news you get about future security fixes or bugfixes that are worth pushing, we'd decide together whether to push the update to all users or wait for the next.

Whiteboard: (none) => feedback

that was the plan :-). i've added a comment in the forum, linking to this validation bug, so that they can validate here.

hold off on testing or validating for a bit, i'm not sure, but there might be an important fix soon-ish... i'll let you guys know if i have more info

Thanks for letting us know AL13N, holding off until we hear from you again :)

assigning back to AL13N then until there is something real need to validate

Assignee: qa-bugs => alien

ok, i'll be submitting mariadb-5.5.25-2.1.mga2 soon... it seems that last time, i forgot to set subrel and thus i changed release instead /o\

i donno if i should be releasing 1.1 instead; since rel 2 it was only in updates_testing repos...

This patch will be fixing a replication issue if your master < 5.5.25 (and this is a slave)

Assignee: alien => qa-bugs

The count for Mageia 2 at http://mariadb.org/feedback_plugin/stats/distros/
was 13 before I enabled the feedback in two VB installs (one i586 and one
x86-64), including the kde config, about 5 hours ago.

I've tested both installs using phpmyadmin and glpi.

Do you want to wait until tomorrow to see if the count goes up, or should
I go ahead and validate this update?

CC: (none) => davidwhodgins
Whiteboard: feedback => feedback MGA2-32-OK MGA2-64-OK

What about regression testing, all done already?

the important part is the replication part; since Oracle hasn't released this one yet, there is no doc, no reproducer or anything, but if someone could confirm that replication is working, it would be nice. if not, we shouldn't wait for this.

for mariadb it'll be fixed in 5.5.27 and oracle mysql, could be still a while before it's fixed...

oh and the feedback part is only regenerated once a day.

normally, if the logs say that the feedback POST was successful, it should be working.

Created attachment 2682 [details]
Screenshot of phpmyadmin

I've setup a Mageia 1 x86-64 mysqld as the master, and both Mageia 2 i586
and x86-64 as slaves.

As shown by the attached screenshot, replication is working.

Regarding the feedback, there is nothing in /var/log/mysqld/mysqld.log
saying the feeback worked or didn't work.

is the feedback plugin loaded? check with "SHOW PLUGINS"

also, the feedback plugin doesn't post it's message right away, it takes a few minutes for it do start it.

sorry, another patch needs to be added, i'll rebuild a new version with a patch as soon as possible (BS will need to get fixed too)

Removing the ok tags, till the new version gets tested.

Whiteboard: feedback MGA2-32-OK MGA2-64-OK => feedback

120827 19:11:57 [Note] feedback plugin: server replied 'ok'
120827 23:06:10 [Note] feedback plugin: report to 'http://mariadb.org/feedback_plugin/post' was sent
120827 23:06:13 [Note] feedback plugin: server replied 'ok'

Took a while, but the count at http://mariadb.org/feedback_plugin/stats/distros/
finally increased from 13 to 17, two of which should be my vb installs.

mariadb-5.5.25-2.2.mga2 is submitted

Testing complete on Mageia 2 i586 and x86-64.

The feedback plugin now reports ok in /var/log/mysqld/mysqld.log and
in ~/.local/share/akonadi/db_data/mysql.err

Also tested using glpi and phpmyadmin.

Could someone from the sysadmin team push the srpm
mariadb-5.5.25-2.2.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates.

Advisory:  This security update for Mariadb corrects a problem that
is not yet being publicly disclosed.

In addition, a problem preventing the feedback plugin from working
has been corrected.

https://bugs.mageia.org/show_bug.cgi?id=6922

Keywords: (none) => Security, validated_update
CC: (none) => sysadmin-bugs
Whiteboard: feedback => MGA2-32-OK MGA2-64-OK
Severity: normal => critical

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0244

Status: NEW => RESOLVED
Resolution: (none) => FIXED

ah... i'd have preferred not to have mentioned security...

Then you as maintainer should have provided tha advisory as intended by the update request policy.

QA are not mindreaders... 

I really hope this didnt break an update embargo then...:/

i just checked, it seems we're still ok, it would've been better if it was differently formulated though.

i had informed david privately about the matter... but maybe i should've put the advisory myself... a thought for the future...

maybe we should have some kind of policy regarding such things...

i'm communicating with upstream regarding of future handlings, and the possibility of having a releasing embargodate as well... like a week before the disclosure date.

You mean the maintainer part:
https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29

Or embargo/disclosure part ?

the embargo/disclosure part is already "set in stone" 
cf old cross-distro/os vendor-sec list (it has a new name nowdays, but the same applies)


Regarding embargoed stuff _nothing_ can be submitted to public svn or public bugzilla or public buildsystem before embargo is lifted...

i was speaking about disclosure part (i know i should've provided advisory)


well, the embargo/disclosure part is not set in stone (not for this).


This one comes from a mariadb-specific mailing list which are by invitation only. and their nondisclosure policy isn't written at all... specifically i was asked to "use common sense". i did mention i didn't have a private bugzilla or whatever, and that i was allowed to commit submit & release upfront, but that i was to have messages which would be allowed to specify the bug, but not relating to security.

after we talked, they said they would look into the matter and maybe organize this a bit better and perhaps even ask for release dates (maybe have a release embargo a week before the full disclosure date)


for mageia, we don't have a private bugzilla, we don't have private git, or private buildsystem or whatever...

So, that part is something that we should have a policy of. The idea of discribing the bug, and not mentioning security appeals to me.

The CVE for this (CVE-2012-4414) finally hit LWN.  Our advisory was updated to reflect the CVE a while ago.  OpenSuSE just issued an advisory with the CVE.  Just in case anyone is looking for it.

http://lwn.net/Vulnerabilities/533755/

CC: (none) => luigiwalser