Jani, what extra support is enabled in the tainted version please.
Thanks.

From .spec:

%if %{build_plf}
BuildRequires: liblame-devel
BuildRequires: libfaad2-devel
%endif

Testing on x86_64.

Updated audacious and audacious-plugins and tested against upstream bug fixes. All seem Ok. 

I couldn't test against unity launcher or check translations.

CC: (none) => fcs
Whiteboard: (none) => mga2-64-OK

Testing on i586.

CC: (none) => remi

Tested the update from core/updates_testing on i586.
All upstream bug fixes ([3] in #c0) are applied. Could not reproduce upstream bug #114 on the non-updated package though.
No regression found.

Tested the update from tainted/updates_testing on i586.
Seems OK too.

Whiteboard: mga2-64-OK => mga2-64-OK mga2-32-OK

According to the updates policy (https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29), the release number of the SRPMs should be 1.mga2 (since it's a new version) and not 0.1.mga2 (the subrel marker is used for updates of the same version of a software).

Jani, could you resubmit the SRPMs with the proper release marker?

I'd prefer not bumping rel just for that.

I understand your position, but there's no problem with bumping release for a package in updates_testing, it's not "released" yes, so please try to follow the policy.

We're explaining the policy to the team internally to our new members, having packagers follow it even for small things makes our life easier :)

CC: (none) => stormi

If you really want this, I guess I can do it. However, bumping rel just because it doesn't follow our policy exactly (current rel is result of an old habit from mdv times) wouldn't make QA team (or sysadm team or mine) life easier :P

First I'd have to checkout pkgs, bump rel, submit pkgs (some of them twice) and markrelease pkgs (some of them twice) to get correct %changelog in the future. Then QA team must test new pkgs and then sysadm team must first remove the old ones from core/updates_testing and finally push the new ones to update/release.

QA is ready to test the new packages, and I don't think sysadm will have to remove the old packages, the newer will have a higher release (1) so will replace the old ones, won't they? I don't remember anyone having to ask sysadmins to remove an update candidate after bumping the subrel or rel.

For changelog, it's up to you, I don't think seeing the rebuild in the changelog is a big problem. "set release to 1 to comply with policy" is an acceptable message in a changelog to me. But maybe I'm missing something here.

However, I'm ok if we let this one slip through the net, if you think it's too much work. Just try to lose that old mdv habit :)

(In reply to comment #10)
> QA is ready to test the new packages, and I don't think sysadm will have to
> remove the old packages, the newer will have a higher release (1) so will
> replace the old ones, won't they? I don't remember anyone having to ask
> sysadmins to remove an update candidate after bumping the subrel or rel.

IIRC, older pkgs doesn't get removed from update medias. We'll see for sure after I've bumped rel.

> 
> For changelog, it's up to you, I don't think seeing the rebuild in the
> changelog is a big problem. "set release to 1 to comply with policy" is an
> acceptable message in a changelog to me. But maybe I'm missing something here.
> 

My point was that I need to use 'mgarepo markrelease' to "tag" release correcty in our svn to get %changelog generated correctly in the future. Markreleasing updates isn't currently working. See bug 3666.

> However, I'm ok if we let this one slip through the net, if you think it's too
> much work. Just try to lose that old mdv habit :)

Luckily I'm on a vacation and have nothing but time.. I'll bump the rel. :)

Rel bumped pkgs are on their way to mirrors. Check also if pkgs with lower rel is removed.

Thanks Jani, enjoy your holiday. 

Removing whiteboard keywords for retesting.

Hardware: i586 => All
Whiteboard: mga2-64-OK mga2-32-OK => (none)

New srpms:

# urpmq --media Testing --sourcerpm audacious
audacious: audacious-3.2.3-1.mga2.src.rpm

# urpmq --media Testing --sourcerpm audacious-plugins
audacious-plugins: audacious-plugins-3.2.3-1.mga2.src.rpm

It has replaced the old ones on the mirrors btw.

audacious-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:20 	298K
audacious-adplug-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:26 	162K
audacious-fluidsynth-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:26 	16K
audacious-jack-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:26 	24K
audacious-plugins-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:26 	1.1M
audacious-pulse-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:26 	17K
audacious-sid-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:26 	46K
audacious-wavpack-3.2.3-1.mga2.i586.rpm	26-Jun-2012 16:26 	14K

Thanks for bumping release Jani :)

Tested on i586 Mageia 2, still OK.

Whiteboard: (none) => mga2-32-OK

Tested on x86_64 Mageia 2, OK.


Validating update.

Advisory and SRPMs: see comment 0.


Could a sysadmin push the updates from core/updates_testing to core/updates and from tainted/updates_testing to tainted/updates?
Thanks in advance.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: mga2-32-OK => mga2-32-OK mga2-64-OK

Thank Rémi, well done :)

The srpm's are different from comment 0 as they were rebuilt for the version bump.

audacious-3.2.3-1.mga2.src.rpm
audacious-plugins-3.2.3-1.mga2.src.rpm

Not forgetting the tainted versions

audacious-plugins-3.2.3-1.mga2.tainted.src.rpm

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGAA-2012-0091

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