(In reply to Thierry Vignaud from comment #0)
> The 2nd item below makes rpm-4.13 able to handle packages built with
> rpm-4.14, which will be important for our infra once it upgrades to mga6.

Has that part been tested Thierry, as it's unlikely we can check that in QA?

mga6  x86_64

All packages installed cleanly (omitted debuginfo package)

Tried out a few informational commands:

$ rpm -qa | grep debuginfo
urpmi-debuginfo-install-1-16.mga6

$ rpm -qilp python-mageiasync-0.1.1-1.mga5.noarch.rpm
Name        : python-mageiasync
Version     : 0.1.1
Release     : 1.mga5
Architecture: noarch
Install Date: (not installed)
Group       : Development/Python
Size        : 153756
License     : GPLv3
Signature   : RSA/SHA1, Mon 27 Oct 2014 21:24:55 GMT, Key ID b742fa8b80420f66
Source RPM  : python-mageiasync-0.1.1-1.mga5.src.rpm
Build Date  : Mon 27 Oct 2014 21:22:53 GMT
Build Host  : ecosse.mageia.org
Relocations : (not relocatable)
Packager    : ennael <ennael>
Vendor      : Mageia.Org
URL         : https://github.com/papoteur-mga/mageiaSync
Summary     : A frontend to rsync for Mageia usage
Description :
A frontend to rsync for Mageia usage.
/usr/bin/mageiasync
/usr/lib/python2.7/site-packages/mageiaSync
/usr/lib/python2.7/site-packages/mageiaSync/__init__.py
/usr/lib/python2.7/site-packages/mageiaSync/__init__.pyc
/usr/lib/python2.7/site-packages/mageiaSync/__init__.pyo
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBprefs.py
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBprefs.pyc
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBprefs.pyo
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBprefs0.py
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBprefs0.pyc
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBprefs0.pyo
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBrename.py
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBrename.pyc
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBrename.pyo
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBupdate.py
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBupdate.pyc
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncDBupdate.pyo
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncExt.py
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncExt.pyc
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncExt.pyo
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncUI.py
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncUI.pyc
/usr/lib/python2.7/site-packages/mageiaSync/mageiaSyncUI.pyo
/usr/lib/python2.7/site-packages/mageiaSync/mageiasync.py
/usr/lib/python2.7/site-packages/mageiaSync/mageiasync.pyc
/usr/lib/python2.7/site-packages/mageiaSync/mageiasync.pyo
/usr/lib/python2.7/site-packages/mageiasync-0.1-py2.7.egg-info
/usr/share/applications/mageiasync.desktop
/usr/share/doc/python-mageiasync
/usr/share/doc/python-mageiasync/CHANGELOG
/usr/share/doc/python-mageiasync/LICENSE
/usr/share/doc/python-mageiasync/README.md
/usr/share/icons/hicolor/scalable/apps/mageiasync.svg

rpm -q --whatprovides gqview
geeqie-1.3-2.mga6

$ urpmq --whatrequires rpm
basesystem-minimal
color-filesystem
lib64rpm-devel
locales
perl-RPM4
perl-URPM
pesign
python2-rpm
python3-rpm
rhn-client-tools
rpm
rpm-build
rpmorphan
rpmrebuild
supermin

$ sudo urpmi okular
That worked fine, pulling in various kde packages.

$ sudo rpm -i tvbrowser-3.3.3-1.noarch.rpm 
[lcl@belexeuli rpm]$ which tvbrowser
/bin/tvbrowser
$ sudo rpm -e tvbrowser
[lcl@belexeuli rpm]$ ls /bin/tvbrowser
ls: cannot access '/bin/tvbrowser': No such file or directory

This looks good for 64-bits.

CC: (none) => tarazed25

Addendum to comment 2.

Installed scheduled updates right after that test.  No problems.

Given the fundamental importance of rpm, this warrants a 32-bit test as well.
Len has given the script!

CC: (none) => lewyssmith

(In reply to claire robinson from comment #1)
> (In reply to Thierry Vignaud from comment #0)
> > The 2nd item below makes rpm-4.13 able to handle packages built with
> > rpm-4.14, which will be important for our infra once it upgrades to mga6.
> 
> Has that part been tested Thierry, as it's unlikely we can check that in QA?

tv can correct / give a test procedure for it, but basically:

It can probably be tested by doing cauldron builds with iurt on a mga6 host, or removing mga6 repos, adding cauldron repos and use "urpmi --root ..." to install a  cauldron chroot...

before the update that would fail as rpm would choke on new rpm header stuff...

after rpm update it should work...

CC: (none) => tmb

(In reply to Thomas Backlund from comment #5)
> > > The 2nd item below makes rpm-4.13 able to handle packages built with
> > > rpm-4.14, which will be important for our infra once it upgrades to mga6.
> > Has that part been tested Thierry, as it's unlikely we can check that in QA?
> 
> It can probably be tested by doing cauldron builds with iurt on a mga6 host,
> or removing mga6 repos, adding cauldron repos and use "urpmi --root ..." to
> install a  cauldron chroot...
> before the update that would fail as rpm would choke on new rpm header
> stuff...
> after rpm update it should work...
Can one do this on a 'normal' system without messing it up? Changing repos mga6 -> cauldron, then will
 # urpmi --root       [what, for example? Anything?]
offer the possibility to *not* do it, back out? Then revert repos cauldron -> mga6, leaving the system untouched part from the rpm update.

(In reply to Lewis Smith from comment #6)
> Can one do this on a 'normal' system without messing it up? Changing repos
> mga6 -> cauldron, then will
>  # urpmi --root       [what, for example? Anything?]
> offer the possibility to *not* do it, back out? Then revert repos cauldron
> -> mga6, leaving the system untouched part from the rpm update.

Yes, as it would install the stuff in a chroot, not on the running system...
(but if you later forget to change back it will upgrade you to cauldron...)

But I now realized we have a wiki :)

I'd say the "packagers chroot" test is safer as you wont alter the host media sources...

So:
https://wiki.mageia.org/en/Packagers_chroot

You'd better use --urpmi-root. eg:
D=./R
urpmi.addmedia --urpmi-root $D --distrib <your_favorite_mirror>
urpmi  --urpmi-root $D  basesystem-minimal

Note that this patch had already been tested in FC.
The goal is for mga6 system to be able to handle mga7's packages (only rpm-4.13 has issues with pkgs built by rpm-4.14)

This is needed for 2 reasons:
1) so that when upgrading to mga7 online, old urpmi using old rpm-4.13 can first update to new urpmi+rpm-4.14
(that would not be an issue for offline update such as done by drakx or with urpmi --(urpmi-)root )

2) so that infra won't shoke on mga7 pkgs once it got upgraded to mga6

I confirm that after running 'urpmi.update "Core Updates Testing" && urpmi --media "Core Updates Testing" rpm librpmbuild7 librpmsign7' on arm build nodes running Mageia6 on armv5tl, they are able again to create a chroot using packages from cauldron.

CC: (none) => pterjan

MGA6-32 on Asus A6000VM MATE
No installation issues.
After installation using MCC and restart of "Software installation", went on to install the latest bunch of normal updates. All looks well.
Tried some of Comment 2
rpm -q --whatprovides gqview
no package provides gqview
$ urpmq --whatrequires rpm
basesystem-minimal
color-filesystem
librpm-devel
locales
perl-RPM4
perl-URPM
pesign
python2-rpm
python3-rpm
rhn-client-tools
rpm
rpm-build
rpmorphan
rpmrebuild
supermin

# urpmi tvbrowser


    $MIRRORLIST: media/core/release/tvbrowser-3.4-5.mga6.noarch.rpm
installeren van tvbrowser-3.4-5.mga6.noarch.rpm vanaf /var/cache/urpmi/rpms                                             
Voorbereiden...                  ######################################################################################
      1/1: tvbrowser             ######################################################################################
#  rpm -e tvbrowser
# ls /bin/tvbrowser
ls: kan geen toegang krijgen tot '/bin/tvbrowser': Bestand of map bestaat niet
i.e. file or directory does ,ot exist.
OK for me.

Whiteboard: MGA6-64-OK => MGA6-64-OK MGA-6-32-OK
CC: (none) => herman.viaene

(In reply to Thierry Vignaud from comment #8)
> You'd better use --urpmi-root. eg:
> D=./R
> urpmi.addmedia --urpmi-root $D --distrib <your_favorite_mirror>
> urpmi  --urpmi-root $D  basesystem-minimal
> 
> Note that this patch had already been tested in FC.
> The goal is for mga6 system to be able to handle mga7's packages (only
> rpm-4.13 has issues with pkgs built by rpm-4.14)
> 
> This is needed for 2 reasons:
> 1) so that when upgrading to mga7 online, old urpmi using old rpm-4.13 can
> first update to new urpmi+rpm-4.14
> (that would not be an issue for offline update such as done by drakx or with
> urpmi --(urpmi-)root )
> 
> 2) so that infra won't shoke on mga7 pkgs once it got upgraded to mga6


pterjan confirmed it works on arm, and I've just confirmed being able to create i586 and x86_64 cauldron chroots from a mga6 x86_64 system (like the buildsystem is running)

Given the very expert tests above, I can see no reason not to validate this update.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

I've also verified that online urpmi--auto-update from mga6 -> cauldron works on both i586 and x86_64 with the fixed rpms

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGAA-2017-0081.html

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