Bug 8916

Created attachment 3463 [details]
M2 -> M3B2 upgrade logs

(In reply to comment #0)

> Those files are contained in a TAR file attached to
> this bug.

Opps, had to be a ZIP file. The TAR file was way too big.

thanks

(I really don't know how to debbug that)

exemple

libktorrent.so.5 is needed by ktorrent-4.3.0-3.mga3.i586
$ grep libktorrent5 /media/data/iso/test/*/*.idx
/media/data/iso/test/Mageia-3-beta2-i586-DVD/Mageia-3-beta2-i586-DVD.idx:Mageia-3 beta2-i586 libktorrent5-1.3.0

libkipiplugins.so.3 is needed by kipi-plugins-facebook-1:3.0.0-0.rc.4.mga3.i586
:findfile libkipiplugins.so.3
20:36 <Sophie> find in (Mageia, cauldron, *) : lib64kipiplugins3, libkipiplugins3
$ grep libkipiplugins3 /media/data/iso/test/*/*.idx
/media/data/iso/test/Mageia-3-beta2-i586-DVD/Mageia-3-beta2-i586-DVD.idx:Mageia-3 beta2-i586 libkipiplugins3-3.0.0 (i586)

CC: (none) => ennael1
Blocks: (none) => 8016

FWIW I posted this bug as general info. Do feel free
to make suggestions as to my testing methodology.
I could have used my local repo for the sources
rather then the hard DVD. I think there's lots of
ways to upgrade, or not.

This could be bug 2317 again

(In reply to comment #5)
> This could be bug 2317 again

don't think so, as there is nothing in updates (ans only the dvd is used)

(cf install.log of ddebug.log not the *.1)

Today I used the 32-bit boot.iso and my local repo to upgrade.
Almost got there. Only a couple files reporting errors. I've
attached a ZIP file containing the /var/log/syslog and the
/root/drakx files.

Created attachment 3478 [details]
M2 -> M3B2 using boot.iso upgrade logs

Thierry, William's install.log shows this:
Installation failed:	file /etc/httpd/conf/vhosts.d from install of apache-2.4.3-8.mga3.i586 conflicts with file from package apache-2.2.23-1.mga2.i586
	file /etc/httpd/conf/webapps.d from install of apache-2.4.3-8.mga3.i586 conflicts with file from package apache-2.2.23-1.mga2.i586

But in apache-2.4.3-8.mga3 we have this:
%pretrans
if [ $1 = 2 ]; then
    # prevent symlink creation failure on update
    if [ ! -d /etc/httpd/conf/sites.d ]; then
        mkdir /etc/httpd/conf/sites.d
        mv -f /etc/httpd/conf/webapps.d/* /etc/httpd/conf/sites.d 2>/dev/null
        mv -f /etc/httpd/conf/vhosts.d/* /etc/httpd/conf/sites.d 2>/dev/null
        rmdir /etc/httpd/conf/webapps.d
        rmdir /etc/httpd/conf/vhosts.d
    fi
fi

I made the change from %pre to %pretrans in apache-2.4.3-7.mga3, which was supposed to fix that problem.  If that doesn't fix it, how do we fix this?

CC: (none) => thierry.vignaud

IIRC $1 has no meaning [1] in %pretrans and %posttrans, and shouldn't be tested ($1 equals 0 both for install and update for these 2 scriptlets).
Removing if [ $1 = 2 ]; then  ... fi around the action, should fix the problem and ease the update.
%pretrans works to fix such updates; we used it in kde ;-) , see
http://svnweb.mageia.org/packages?view=revision&revision=336209
http://svnweb.mageia.org/packages?view=revision&revision=339983



[1] for other scriptlets, the argument $1 is the number of packages of this name which will be left on the system when the action completes.

regards,
Luc

CC: (none) => lmenut

Thanks Luc!  I'll rework the %pretrans script.

Should be fixed in apache-2.4.3-9.mga3.

As for the upgrade issues with the DVD, maybe Thierry will have some insight, but I'm confused about that one.  Each of the errors looks like due to a missing package on the DVD, but for each one I came up with that looked like being missing would cause that, Manuel Hiebel said it looked like those packages were on the DVD.

We'll need to pay more attention to this when QA testing the DVD for beta 3.

Today I executed a Mageia 2 32-bit install from M2 boot.iso.
I then updated that install. Repo is my local repo mirrored
from mirrors.kernel.com. After the M2 32-bit install was
completed I then used the M3 boot.iso ( dated 8 Feb 13 ) to
execute an update M2 -> M3B2. That update was successful
in so far as after the update I was successful to do a
reboot of the system back to a M3B2 working desktop.
I'm gonna mark this Bug as RESOLVED for now but will
rerun this process probably about once a week until
M3 release.

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